参数化查询是唯一可靠的SQL注入防御手段，因转义规则不统一、宽字节绕过、数字型注入等缺陷使其无法根本防护；动态标识符须白名单校验，旧系统拼接仅限临时兼容。
纯手工 SQL 防注入器不能靠“字符类型配合转义规则”来实现安全防护，这种思路本身存在根本性风险——转义不是防御，而是补救；手工转义极易遗漏、错位或被绕过。真正可靠的防注入手段是参数化查询（即预编译语句），而非字符串拼接+转义。
为什么字符类型和转义无法构成可靠防注入器
SQL 注入的本质是语义混淆：攻击者让数据库把用户输入当作代码执行。而转义仅试图“掩盖”特殊字符（如 ' → \'、; → \;），但：
- 不同数据库（MySQL、PostgreSQL、SQL Server）转义规则不一致，比如 MySQL 的
SET sql_mode='NO_BACKSLASH_ESCAPES'会让反斜杠失效 - 多字节编码（如 GBK）存在宽字节注入，
%df%27可绕过单引号转义 - 数字型参数若未强转类型，
id=1 OR 1=1这类无需引号的注入完全不受字符转义影响 - JSON 字段、ORDER BY 子句、表名/列名等动态位置无法用引号包裹，转义无从下手
如果必须处理动态标识符（如表名、字段名），该怎么做
这类内容无法参数化，需白名单校验 + 严格格式限制：
- 只允许字母、数字、下划线，且长度限制在 1–64 字符内
- 预先加载合法表名列表（如从
information_schema.tables查询并缓存），运行时做精确匹配 - 使用正则
/^[a-zA-Z_][a-zA-Z0-9_]*$/校验，拒绝任何含连字符、点号、空格或 Unicode 控制符的输入
若受限于旧系统必须拼接 SQL，最小化风险的操作
仅作为临时兼容方案，绝不可用于新项目：
- 对字符串值统一使用数据库原生转义函数：
mysqli_real_escape_string()（PHP）、pg_escape_string()（PostgreSQL），且必须指定连接资源，避免默认字符集不匹配 - 所有数字参数强制
(int)或intval()转换，小数用floatval()+number_format()格式化后拼入 - 关闭错误回显，防止
mysql_error()泄露结构信息 - 为每个查询设置最大执行时间与结果行数上限，增加盲注成本
真正该投入精力的地方
放弃“手工防注入器”的执念，转向工程化防护：
- 全面迁移到 PDO 或 mysqli 的
prepare()/bind_param()流程 - 使用 ORM（如 Doctrine、SQLAlchemy）时启用原生参数绑定，禁用
raw()、literal()类危险接口 - 部署 WAF 规则（如 ModSecurity 的 CRS 规则集）作为纵深防御补充，而非替代
- 定期用
sqlmap -u "url" --batch --level=3扫描验证防护效果
