驱动升级不会让防护失效，而是将sql注入防护前移至预解析阶段：mysql 8.0+驱动在sql字符串发往数据库前即校验引号嵌套、or/union等可疑结构并抛sqlsyntaxerrorexception，暴露原有拼接漏洞。
驱动升级本身不会让防护“失效”，但会改变防护的触发边界和行为表现——你看到的“失效”，其实是旧代码在新驱动下暴露了原本被掩盖的问题。
MySQL Connector/J 8.0+ 的 SQLSyntaxErrorException 不再只是语法错
老版本驱动（如 5.1.x）对 executeQuery("SELECT * FROM user WHERE name = '" + input + "'") 这类拼接，往往直接发给数据库，等 DB 返回错误才抛异常；而 8.0+ 默认开启预解析校验，在 SQL 字符串还没进数据库前就检查引号嵌套、OR/UNION 关键字位置、注释符异常等，一发现可疑结构就提前抛 SQLSyntaxErrorException。
这不是防护坏了，是它终于开始拦了——但你的代码里还留着拼接逻辑，所以原来“侥幸跑通”的注入点，现在直接报错中断。
- 现象：升级后大量
SQLSyntaxErrorException突然出现，日志里没明显 SQL 错误 - 本质：驱动把“本该由业务层堵住的拼接漏洞”，变成了运行时可见的拦截事件
- 验证方法：抓包看是否请求根本没发到 MySQL（用 tcpdump 或 MySQL general_log），若没发出去，就是驱动层拦截
PostgreSQL JDBC 42.3+ 对参数类型校验更严格
新版驱动对 PreparedStatement 的参数绑定做了更强类型推断。比如你写 setString(1, "1' OR true --")，老驱动可能照单全收；新驱动发现字段是 INT 类型却传入含单引号的字符串，会主动拒绝并抛 PSQLException（不是 SQLSyntaxError，但效果类似）。
这容易被误判为“参数化查询失灵”，实则是驱动在帮你守住最后一道防线——前提是你的字段定义和绑定类型一致。
- 常见坑：数据库列是
INT，但代码仍用setString()传数字字符串 - 修复动作：改用
setInt()、setLong()等强类型方法，或确保列定义与 Java 类型对齐 - 注意：MyBatis 的
#{}默认走 setObject()，也可能触发此校验，需检查 typeHandler 配置
ojdbc8 在 Oracle 19c 下对动态 SQL 的审计敏感度提升
Oracle 19c + ojdbc8 组合会增强对 Statement.execute() 调用中含用户输入的 SQL 字符串的日志记录和审计标记。CI/CD 流水线里的安全扫描工具（如 SonarQube 9+）会据此报“高危动态 SQL”，哪怕你没真执行恶意语句。
这不是运行时防护失效，而是静态/准实时审计规则变严了——它盯的不是“有没有被攻击”，而是“有没有暴露风险面”。
- 典型误报点：
Statement拼接了ORDER BY ${field}，哪怕${field}来自白名单枚举 - 真实风险点：没做白名单校验的
${table}或${ids}拼接 - 应对方式：把所有
Statement替换为PreparedStatement，动态部分改用硬编码分支或映射表
真正难处理的从来不是报错本身，而是那些没报错却依然危险的调用：比如 WHERE status IN (${statusList}) 用 MyBatis 手动拼成 (1,2,3)，或者存储过程调用里把用户输入塞进 CALL proc(? || ?) ——这些在新旧驱动下都安静地执行，直到某天被真实利用。
