Test Connection仅验证JDBC初始握手，不保证查询、权限或SSL可用；常见报错对应网络不通、认证方式不匹配、驱动缺失或SSL/DNS超时，成功后仍需执行SELECT 1验证真实可用性。
“Test Connection”不是走个过场，它只验证 JDBC 层能否建立初始握手，不保证后续查询、权限或 SSL 配置可用。
点击 Test Connection 后弹出红框报错，但参数看起来都对
常见错误信息如 Connection refused、Authentication failed、No suitable driver 或空提示框，本质是三层中某一层断了：
-
Connection refused：网络不通（端口没开、防火墙拦截、PostgreSQL 的postgresql.conf没设listen_addresses = '*'）或服务根本没起来 -
Authentication failed：不是密码输错了，更可能是 PostgreSQL 的pg_hba.conf里没允许你用的认证方式（比如填了密码却配了trust，或用了 md5 却连的是 scram-sha-256 认证的库） -
No suitable driver：DBeaver 没加载到对应数据库的 JDBC 驱动——比如连 MySQL 8.0 却用了旧版mysql-connector-java-5.1.x.jar，驱动不兼容 - 什么都没报、直接卡住几秒后失败：大概率是 DNS 解析慢或 SSL 握手超时，可尝试在连接设置里关掉
sslmode=require或勾选 “Use SSL” 再试
Test Connection 成功但连不上数据库（双击连接无响应或报权限错）
测试成功只说明 TCP 连通 + 用户名密码能通过认证，不代表你能访问具体库或执行语句：
- MySQL 中如果填了
Database字段但该库不存在，Test Connection仍可能成功（JDBC 允许空库连接），但双击连接后会报Unknown database 'xxx' - PostgreSQL 中若未指定
Database，默认连postgres库；如果该库被删或用户没权限，双击连接就会失败，而Test Connection不校验这个 - 达梦、OceanBase 等国产库常默认关闭 public schema 访问，
Test Connection过了，但一查表就报schema not found，得手动在连接设置里填上schema=USER_NAME
不同数据库对 Test Connection 的行为差异
别把 MySQL 的逻辑套到 PostgreSQL 上，驱动实现细节会影响测试结果：
- MySQL 驱动（8.0+）：默认启用
allowPublicKeyRetrieval=true和useSSL=false才能过测试，否则容易卡在 RSA 密钥交换 - PostgreSQL 驱动：若服务器启用了
password_encryption = scram-sha-256，必须用 42.2.0+ 版本驱动，旧驱动会静默失败 - SQLite：不需要填 host/port/user/password，
Test Connection实际是打开本地文件并检查是否为合法 SQLite DB 文件头 - MariaDB：虽然驱动通用，但若启用了
unix_socket认证，Test Connection会失败——它不支持 socket 路径，必须切回 TCP 模式
真正容易被忽略的是：Test Connection 不读取你写的 SQL，不校验字符集，不触发任何实际查询。它只是“敲门”，门开了不等于屋里能待着。连上之后第一件事，永远是手动执行 SELECT 1; 或 SHOW TABLES;，这才是真实可用性的最小验证。
