1. 自定义驱动不是“配个JAR就行”：DBeaver里最常被低估的上下文污染源大多数人配置完 DBeaver 的自定义数据库驱动后，第一反应是点“Test Connection”——绿勾一亮，就以为万事大吉。我试过三个项目，两个在上线前一周才发现：同一个 SQL 脚本，在本地执行返回 12 行，在测试环境执行只返回 8 行，且无任何报错。查了两天日志、网络、权限，最后发现根源在驱动类路径里混进了旧版postgresql-42.2.5.jar，而团队统一要求用42.6.0。DBeaver 没报错，它只是默默加载了 classpath 里第一个匹配的org.postgresql.Driver——这个行为本身合法，但后果是 JDBC 协议版本不一致，导致ResultSetMetaData.getColumnCount()在某些字段类型下返回错误值。这不是驱动本身的问题，而是 DBeaver 扩展机制中一个隐性上下文边界：驱动加载过程完全脱离 AI 编程工具的感知范围。当你用 Cursor 或 Claude Code 写一段带LIMIT 100的查询时，AI 基于你当前连接的元数据（表结构、索引、统计信息）生成逻辑；但如果驱动底层悄悄用了老协议，它看到的“元数据”其实是降级兼容后的视图。这种上下文错位，比 token 丢失更危险——它不报错，只悄悄撒谎。所以本节讲的不是“怎么让 DBeaver 连上数据库”，而是：如何让 AI 编程工具真正信任你给它的那个连接上下文。这需要三步硬核操作：隔离驱动依赖、锁定协议
的正确用法)
