参数化查询是唯一可靠的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 扫描验证防护效果