预处理语句未能彻底消除sql注入，因其落地偏差（如仅覆盖登录搜索而忽略order by、动态表名）、orm误用（raw()/text()）、错误过滤（htmlspecialchars防xss无效），以及非标准上下文（load data、copy from program、json路径）和新型绕过技术（嵌套注释、关键词拆解、十六进制编码）导致防护失效。
因为开发者仍在拼接SQL语句，而攻击者总能找到没被覆盖的过滤盲区。
预处理语句为什么没拦住所有注入
预处理（PDO::prepare、PreparedStatement、sqlite3.execute()带参数调用）本身没问题，但落地时经常只覆盖了“显眼”位置：
- 登录、搜索用了参数化，但导出报表的
ORDER BY字段仍用"ORDER BY " + user_input - Django里写了
raw()，Flask-SQLAlchemy用了text()，等于退回字符串拼接 - 把
htmlspecialchars()或strip_tags()当SQL防护——它们防XSS，对SQL注入完全无效
哪些地方预处理根本不起作用
数据库语法决定了某些位置无法参数化，硬上?会直接报错，必须换思路：
-
ORDER BY ?、GROUP BY ?：MySQL/PostgreSQL不支持参数化排序字段 -
IN (?, ?, ?)：问号数量必须提前确定，动态列表得靠构建占位符串 - 表名、列名、数据库名：
SELECT * FROM ?非法，必须白名单校验或正则匹配 -
LOAD DATA INFILE中的文件路径、COPY FROM PROGRAM中的命令参数：这些不是查询数据，而是执行动作
新型绕过技术专打“合法语法”边界
传统WAF拦截'、--、#后，攻击者转向解析器本身的歧义点：
- MySQL嵌套注释：
admin' /* foo */ OR /* bar */ '1'='1，旧版WAF识别不了 - 关键词拆解：
UNI/**/ON SEL/**/ECT绕过关键词检测 - 十六进制编码：
0x554e494f4e（UNION）躲过正则匹配 - JSON字段注入：
data->>'name' || '1'='1，->>操作符若未参数化，拼接即中招
最麻烦的是非标准上下文注入点
SQL注入早已不止于WHERE条件。这些场景难统一防护，且常被安全扫描忽略：
- PostgreSQL的
COPY FROM PROGRAM('id')，program参数可控 = 直接执行系统命令 - Oracle的
UTL_HTTP.REQUEST()，拼接URL参数 = SSRF + 二次注入 - 动态视图创建：
CREATE VIEW v AS SELECT * FROM+user_input，表名没白名单 = 跨库引用 - MyBatis的
${}语法用于动态表名——它不走预编译，等同于String.format
每个数据库方言、ORM的“例外通道”、为兼容老代码做的临时妥协，都在悄悄扩大攻击面。防御必须跟着上下文走，而不是只盯着SELECT ... WHERE这一行。
