真正有效的防御是杜绝SQL结构可塑性：必须用参数化查询（如MySQLi prepare+bind_param、PDO禁用模拟预处理），禁用字符串拼接；动态字段/排序需严格白名单校验；关闭错误回显，禁用关键词过滤等事后补救。
防御 UNION SELECT 注入，关键不在于“检查列数是否固定”，而在于让攻击者根本无法探出列数——因为列数探测（如 ORDER BY 1、UNION SELECT NULL）本身已是注入成功的信号。真正有效的防线，是提前切断输入参与 SQL 结构构建的路径。
用参数化查询彻底消除结构可塑性
只要用户输入进了 SQL 字符串拼接，列数探测就必然可行。比如 PHP 中写成 $sql = "SELECT name FROM users WHERE id = " . $_GET['id']，攻击者输 1' ORDER BY 2-- 就能触发报错，暴露列数。换成预处理语句后，$_GET['id'] 只作为值绑定，不会影响 SELECT 的字段个数或执行计划。
- MySQLi 中必须用
prepare()+bind_param()，不能只用mysqli_real_escape_string() - PDO 中必须用
prepare()+bindValue()或bindParam()，且禁用PDO::ATTR_EMULATE_PREPARES => true（否则可能退化为字符串拼接） - ORM 如 Laravel Eloquent、Django ORM 默认走参数化，但手动写 raw query 时仍需显式绑定，例如
DB::select("SELECT * FROM users WHERE id = ?", [$id])
别信“检测列数变动”这类运行时补救
有些方案建议在应用层拦截 ORDER BY 或统计 UNION SELECT 后的逗号数量，这属于事后识别，既不可靠也易绕过。WAF 规则对 order%20by、un/**/ion、sel/*abc*/ect 等变体基本失效；数据库报错信息（如 SQLSTATE[HY000]: General error: 1222 The used SELECT statements have a different number of columns）一旦返回给前端，列数就已泄露。
- 报错页面不应直接输出数据库错误，而应统一返回 500 并记录日志
- 开发环境可开详细错误，生产环境必须关闭
display_errors，并配置log_errors - 任何基于关键词（
UNION、SELECT、NULL）的请求层过滤，都挡不住大小写混写、注释分隔、URL 编码等绕过手法
动态列场景下必须用白名单控制结构
极少数情况确实需要动态列数，比如报表导出接口支持按用户选择字段查询。这时不能靠“检查是否固定”，而要限制字段来源——只允许从预定义的字段名列表中选取，且每个字段对应明确类型和别名。
- 字段名必须校验是否在白名单内，例如
in_array($field, ['id', 'name', 'email', 'created_at']) - 排序字段（
ORDER BY）同样需白名单，禁止直接拼接用户传入的字符串 - 表名、列名等无法参数化的部分，绝不能来自 GET/POST，必须硬编码或查配置中心
- 即便用了白名单，也要配合参数化查询主体，例如
SELECT :fields FROM users WHERE status = ?是非法的，应拆成白名单生成字段列表 + 绑定其余参数
最常被忽略的一点：开发者以为“我用了 PDO，所以安全”，却忘了开启 PDO::ATTR_EMULATE_PREPARES => false，或在构造动态字段时又回到字符串拼接。防御 UNION 注入不是加一道检测，而是确保每一条 SQL 的结构在编译期就完全确定，不因用户输入产生分支。
