VSCode本身不存储数据库密码，密码由数据库插件（如SQLTools）决定是否明文保存；绝大多数插件默认将密码写入JSON配置文件，存在误提交、共享或被读取风险，应改用环境变量、密钥管理或SSH隧道等安全方案。
VSCode 本身不存储数据库密码，所有密码都由你使用的数据库插件（如 SQLTools、MySQL 等）决定是否明文保存——而绝大多数插件默认会把密码写进 JSON 配置文件，这是最危险的常见操作。
SQLTools 连接配置里为什么不能直接填 password
SQLTools 的连接配置支持两种形式：图形界面填写后自动写入 .vscode/settings.json 或 ~/.sqltools/config.json；或者手动编辑 JSON。无论哪种，只要字段是 "password": "mypass123"，就等于把凭证硬编码进可读文件中。
这类配置容易被误提交到 Git、被同事共享、或被其他插件/脚本读取。更糟的是，SQLTools 早期版本甚至会把密码以明文形式缓存在 VSCode 的全局状态中（globalState），虽然后续版本已改用加密 API，但旧配置残留仍可能泄露。
- 检查你当前的连接配置路径：
~/.sqltools/config.json或项目级.vscode/settings.json中是否存在password字段 - 若存在，立即删除该字段，改用环境变量或密钥管理方式
- 确认 SQLTools 版本 ≥ v0.29.0（2025 年底起默认启用 VS Code Secrets API 存储敏感项）
用 process.env 替代明文密码的实操限制
SQLTools 支持在连接配置中写 "password": "${env:DB_PASS}"，但这个机制依赖 VSCode 启动时的环境变量注入——而 VSCode 桌面版默认不继承系统 shell 的环境变量（尤其是 macOS/Linux 的 ~/.zshrc 或 ~/.bash_profile）。
结果就是：你在终端里 export DB_PASS=xxx 后启动 code . 才生效；直接双击图标打开 VSCode，${env:DB_PASS} 会为空，连接失败。
- macOS 用户必须从终端启动：
open -n -b "com.microsoft.VSCode" --args .（确保 shell 环境已加载） - Windows 用户需在 PowerShell 中设置
$env:DB_PASS="xxx"，再运行code . - Linux 用户建议在桌面启动器（.desktop 文件）中显式指定
Exec=env DB_PASS=xxx code --no-sandbox %F
真正安全的方案：SSH 隧道 + 无密码数据库用户
与其保护密码，不如让数据库根本不需要密码。典型做法是：数据库只监听本地回环（127.0.0.1），通过 SSH 隧道转发端口，再让 VSCode 连本地端口。这样，数据库用户可设为无密码，或仅限 localhost 认证，攻击面大幅缩小。
例如 MySQL 场景：
- 远程服务器上创建无密码用户：
CREATE USER 'vscode'@'localhost' IDENTIFIED WITH mysql_native_password BY ''; - 本地建立隧道：
ssh -L 3307:127.0.0.1:3306 user@remote-host - SQLTools 连接填
host: 127.0.0.1,port: 3307,password: ""（留空） - 隧道进程由 VSCode 的 Remote-SSH 插件或自定义任务自动管理，无需暴露数据库真实地址
别忽略 known_hosts 和 ~/.ssh/config 的权限问题
SSH 隧道看似安全，但如果 ~/.ssh/config 权限是 644、或 ~/.ssh/id_rsa 私钥被设成 644，OpenSSH 会直接拒绝使用——导致隧道失败，你可能又退回去填明文密码。
每次配完 SSH，务必运行：
chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/config chmod 644 ~/.ssh/known_hosts
另外，~/.ssh/config 中应禁用密码回退：PubkeyAuthentication yes 和 PasswordAuthentication no，否则隧道仍可能降级到密码认证。
真正的难点不在“怎么连上”，而在“连上之后，还有谁能看到那个密码”。环境变量易漏、插件配置易误传、SSH 权限易被重置——这些细节一旦松动，前面所有加密措施都会失效。
