sql注入漏洞本质是代码写法问题，而非驱动缺陷；只要存在字符串拼接sql（如cursor.execute("select * from user where name = '" + name + "'")），无论驱动版本多新，漏洞均存在，参数化查询才是根本解决方案。
SQL注入漏洞不是驱动的问题，而是代码写法的问题。升级驱动根本不能修复它——哪怕你用的是 mysql-connector-python 8.0.33 或 psycopg2 2.9.7，只要代码里还存在 cursor.execute("SELECT * FROM user WHERE name = '" + name + "'") 这种拼接，漏洞就还在。
驱动升级只修底层漏洞，不拦应用层拼接
驱动补丁针对的是特定版本下预编译语句解析异常、参数类型绕过等极少数场景（比如 mysql-connector-java 8.0.32 修复了多语句模式下对注释内参数的误判）。但它对 String.format("DELETE FROM %s", table_name) 这类硬编码拼接完全无感——因为SQL字符串在到达驱动前，就已经被应用代码“焊死”了。
新版驱动有时反而放大风险
某些更新默认开启危险特性：
-
node-mysql2≥ 3.9.0 之前默认开启allowLocalInfile，可能被用于LOAD DATA LOCAL INFILE侧信道读取文件 -
PostgreSQL驱动新版本默认allowEncodingChanges=true，可能绕过部分字符过滤逻辑 -
MySQL8.0+ 驱动默认useSSL=false，常被误当作“安全升级”，实则和注入无关
真正该查的，是代码里这些调用点
上线前必须全局搜索并人工确认：
- 所有
.execute(、.executeUpdate(、.query(、.raw(的调用，参数是否含字符串拼接 -
@Query(nativeQuery = true)是否带用户输入 -
ORDER BY、LIMIT、表名、字段名等动态部分是否走白名单映射，而非直接拼接 - 存储过程调用是否用了
CALL proc_name(?)，而不是CALL proc_name("' + userInput + '")
真正难堵的从来不是语法层面的单引号闭合，而是业务逻辑里那些“看起来无害”的动态字段、排序方向、JSON路径表达式——它们不会触发 SQLSyntaxErrorException，却让 PreparedStatement 形同虚设。
