database client支持多数据源因其采用统一协议抽象层+独立driver模块架构，主进程专注ui与编辑，通信由各driver（如mysql2、pg）处理，部分driver自动bundled，部分需手动启用。
Database Client 为什么能支持 MySQL/PostgreSQL/MongoDB/Redis 等十几种数据源
因为它不是为单一数据库定制的客户端，而是基于统一协议抽象层构建的插件架构。核心逻辑是：每个数据源对应一个独立的 driver 模块（如 mysql2、pg、mongodb），插件主进程只负责 UI 渲染、连接管理、SQL 编辑器和结果展示，具体通信由对应 driver 处理。
这意味着你安装 Database Client 后，实际还依赖多个底层驱动——有些自动 bundled，有些需手动安装（比如 Kafka 驱动需要额外启用 kafkajs）。这也是它体积比单库插件大、首次启动略慢的原因。
- 不手动指定 driver 时，插件会按数据库类型自动 fallback 到默认 driver，但 SSL、SSH、自定义认证等高级参数可能被忽略
- 连接 MongoDB 时若用
mongodb+srv://协议，必须确保驱动版本 ≥ 4.0，否则报错MongoServerSelectionError: Server selection timed out - Redis 连接若启用了 ACL（如
auth字段带用户名），旧版 driver 不识别，得手动升级插件或改用redis-cli方式绕过
SQLTools + 对应 Driver 的配置为什么比单库插件更难上手
SQLTools 是“插件套件”模式：主插件 SQLTools 提供 UI 和协议框架，每个数据库需单独安装对应 Driver（如 SQLTools SQLite Driver、SQLTools PostgreSQL Driver）。配置项分散在两个地方：一个是全局 sqltools.json，另一个是各 driver 自己的 settings（比如 PostgreSQL driver 会读取 postgresql.defaultConnection）。
常见卡点在于路径和权限：SQLite driver 默认尝试用系统 sqlite3 CLI，但 Windows 上若没加进 PATH，就会静默失败，只显示空结果集；而 macOS/Linux 上若用 Homebrew 安装了新版 sqlite3，但插件调用的是 Xcode 自带的老版本，又可能不支持 json_each() 这类新函数。
- 连接 PostgreSQL 时，如果
host填localhost但本地 pg 实际监听127.0.0.1，插件可能因 IPv6 fallback 失败，建议显式填127.0.0.1 - MySQL driver 若启用了
ssl.mode=REQUIRED，但服务端证书未正确挂载到容器或本地路径，连接会直接中断，错误信息仅显示Handshake inactivity timeout，无具体原因提示 - 所有 driver 的日志默认关闭，需在 VSCode 设置里手动开启
"sqltools.logLevel": "debug"才能看到真实握手过程
微软出品的 PostgreSQL 插件（ms-ossdata.vscode-postgresql）为何对 Azure 用户更友好
它内置了 Azure 订阅级发现能力，不需要手动拼接连接字符串。点击“Browse Azure”后，插件会调用 Azure CLI 或登录态 token，拉取你有权限访问的所有 PostgreSQL Flexible Server、Azure Cosmos DB for PostgreSQL 实例，并自动填充 host、port、database，甚至处理好 azure-ad 认证流程。
但这也带来副作用：如果你本地开发环境没装 Azure CLI（az），或者账号没登录（az login），插件不会报错，只是“Browse Azure”按钮灰掉，容易误以为功能不可用。另外，它默认禁用普通密码登录，强制走 Microsoft Entra ID，对私有云或测试环境反而更麻烦。
- 想绕过 Azure 集成？必须用“Connection String”模式，且字符串中不能含
Authentication=ActiveDirectoryPassword类字段，否则仍会触发跳转 - 本地连接 PostgreSQL 时，插件会自动检测是否启用了
pg_stat_statements扩展，若启用则在执行查询后自动展示耗时 Top 5 查询——这个行为无法关闭，可能干扰性能敏感场景 - 它生成的查询计划（EXPLAIN ANALYZE）结果是树形结构渲染，但不支持折叠子节点，超长嵌套时滚动困难，不如
pgAdmin的可视化面板直观
SQLite 插件选型时最容易忽略的文件锁与并发问题
VSCode 插件操作 SQLite 本质是通过 Node.js 调用原生 sqlite3 binding 或 CLI 工具，而 SQLite 的 WAL 模式在多进程写入时极易冲突。比如你用 SQLite (alexcvzz) 插件打开 app.db 并执行 INSERT，同时后台 Node.js 服务也在写同一文件，插件大概率卡住或报错 SQLITE_BUSY: database is locked，但界面只显示“Query executed”，无任何提示。
真正安全的做法是：开发阶段用 WAL 模式 + busy_timeout 参数（需 driver 支持），生产排查时改用 SQLTools 配合 .dump 导出快照分析——因为它的 driver 会显式设置 PRAGMA busy_timeout = 5000，而轻量插件几乎都不设。
-
SQLite Viewer插件会自动在打开 db 文件时加共享锁，导致其他进程无法写入，适合只读场景，但不适合边开发边调试 - 所有 SQLite 插件都不支持 ATTACH 多数据库，也无法执行
.backup命令，这些必须切到终端用 CLI - 如果 db 文件在 WSL2 中（路径类似
/mnt/c/Users/xxx/app.db），插件可能因跨文件系统延迟读取失败，建议把文件移到 WSL2 原生路径（如/home/user/app.db）再操作
