1. DBeaver双加密连接不是“配完就跑”，而是研发安全流水线的第一道闸口大多数人把 DBeaver 当成一个“能连上数据库就行”的图形客户端——点开连接、输个密码、查几条数据，完事。直到某天安全扫描报告标红：「生产数据库直连暴露在跳板机白名单之外」「SSL证书未强制校验」「SSH隧道未绑定用户级密钥」。三处高危，全部指向同一个根源：连接配置被当作一次性操作，而非工程化交付物。我经历过两个真实场景：一次是金融客户审计前一周，团队紧急回溯所有数据库连接方式，发现 7 台测试库的 DBeaver 配置里 SSH 密码明文写在 connection.json 里；另一次是 SaaS 产品上线灰度期，因 SSL 配置漏掉requireSSL=true参数，导致部分请求降级走非加密通道，触发了内部 SOC 告警。这两件事让我彻底放弃“连得通就行”的思路——DBeaver 的连接管理，本质是研发安全左移的最小可行单元。它和 AI 编程工具的关系比表面看起来更紧密。当你用 Cursor 或 Claude Code 写一段 JDBC 连接池初始化代码时，AI 模型不会告诉你sslMode=verify-full和sslMode=require的语义差异；当你让 Kimi 生成一个数据库健康检查脚本时，它默认假设连接已通过 SSH 隧道建立，而不会提醒你隧道端口转发是否启用了GatewayPorts no限制。AI 编程工具放大了配置错误的传播半径：它帮你写得更快，但不会替你记住那个必须加在 JDBC URL 末尾的ssl=truesslmode=requi
