优先选SQLTools扩展，因其生态成熟、支持多数据库协议且本地运行稳定；Database Client适合图形化操作但驱动安装复杂；企业级Oracle/DB2应退专用客户端。
VSCode 本身不内置数据库管理功能，但通过扩展可实现接近轻量级客户端的体验；关键不是“集成工具”，而是选对扩展并配置好连接参数——否则连不上、查不出、中文乱码、超时断开都是常态。
用哪个扩展最稳妥？SQLTools 还是 Database Client
SQLTools 插件生态成熟、支持 MySQL/PostgreSQL/SQLite/SQL Server 等主流协议，且能配合驱动（如 mysql2、pg）本地运行，避免 Web 代理层带来的权限或网络限制；Database Client 界面更接近 DBeaver，但部分驱动需手动安装二进制依赖，Windows 上容易卡在 libpq.dll 找不到或版本冲突。
- 开发本地 SQLite 或 PostgreSQL 项目 → 优先装
SQLTools+ 对应驱动包 - 需要图形化表结构浏览、右键导出 CSV →
Database Client更顺手，但务必检查插件页标注的“Required Drivers”是否已按说明部署 - 连接企业内网 Oracle/DB2 → 别硬扛，这类场景建议退回专用客户端，VSCode 扩展普遍缺乏 Kerberos 或 Wallet 支持
连接配置写错一个字段就报 Connection refused 或 authentication failed
错误信息模糊，实际原因往往藏在连接配置的细节里。比如 PostgreSQL 的 host 写成 localhost 而非 127.0.0.1，可能触发 IPv6 回环解析失败；MySQL 的 user 字段若含 @localhost 后缀（如 'admin'@'localhost'），在配置里必须只填 admin，否则认证被拒。
- MySQL 连接：确认
port是3306（非33060，后者是 X Protocol） - PostgreSQL：若用 md5 认证，
password字段不能为空字符串，哪怕密码是空也得填"" - 所有连接都建议勾选
SSL mode: require（尤其云数据库），否则可能被服务端静默拒绝
查询结果中文显示为 ??? 或乱码
根本原因不是 VSCode 编码设置，而是数据库连接时未声明字符集。MySQL 默认用 latin1 握手，即使库和表是 utf8mb4，连接层没指定也会丢字。
- MySQL 连接配置中必须显式加
"charset": "utf8mb4" - PostgreSQL 不需要额外设 charset，但要确认服务器
client_encoding是utf8（执行SHOW client_encoding;验证） - VSCode 自身编码保持
UTF-8即可，不用改files.encoding，乱码根源在连接参数而非编辑器
真正麻烦的是跨环境连接——比如用 WSL2 连宿主机 MySQL，host 不能填 localhost，得用 host.docker.internal 或查 WSL2 的 Windows 主机 IP；这种细节不会报错，只会查不到数据，得自己抓包或看扩展输出通道里的真实连接日志。
