ORDER BY后不能用?占位符，因SQL标准规定其后必须为标识符而非值，预编译仅支持参数化值；白名单校验是唯一安全防御方式，须在SQL拼接前严格比对字段名与排序方向。
ORDER BY 后不能用 ? 占位符，不是 bug，是 SQL 语法本质限制
预编译（PreparedStatement）对 ORDER BY 无效，根本原因不是驱动或数据库“没做好”，而是 SQL 标准和执行语义决定的：ORDER BY column_name 中的 column_name 是标识符（identifier），不是值（value）。而预编译只允许参数化“值”——即那些会被自动加引号、以二进制形式传入的纯数据。
当你写 ORDER BY ?，数据库收到的是类似 ORDER BY 'user_id' 的语句，单引号让 user_id 变成字符串字面量，不再是列名，直接报错或排序失效。
同理失效的位置还包括：
-
SELECT ? FROM users（列名不能参数化） -
FROM ?（表名不能参数化） -
LIMIT ?（MySQL 允许，但 PostgreSQL/SQL Server 要求整数字面量，且 JDBC 驱动可能拒绝非 int 类型绑定） -
GROUP BY ?（列名位置，同ORDER BY）
白名单校验是唯一靠谱的防御方式
对 ORDER BY 后的字段名，不能拼接、不能转义、不能依赖客户端过滤——唯一安全路径是显式限定可接受的取值范围，并严格比对。
实际操作建议：
- 把允许排序的字段提前定义为常量或配置项，例如
['created_at', 'updated_at', 'score', 'name'] - 接收用户传入的
sort参数后，先检查是否在白名单中，不在就直接拒绝（HTTP 400 或抛异常） - 不要用
in_array($input, $whitelist, true)这类宽松匹配；注意大小写、下划线、空格等干扰 - 如果支持升序/降序，
order参数也需白名单约束（仅允许'asc'或'desc'），不可拼接为ORDER BY $col $order - 避免“黑名单过滤”（如删掉
;、--），攻击者总有绕过方式
别信“转义列名”或“双写引号”这类伪方案
有人尝试用 addslashes()、mysql_real_escape_string() 或正则替换来“清理”列名，这完全无效。因为这些函数针对的是字符串值的引号闭合问题，而列名根本不需要引号——你给它加引号，它就废了；你不加，它又不防注入。
还有人用反引号包裹：ORDER BY `$col`，并幻想只要过滤掉反引号就能安全。但这是错觉：$col 若为 id`, user_id -- ，拼出来就是 ORDER BY `id`, user_id -- `，注释符仍会截断后续逻辑。
真正起作用的只有两点：
- 输入必须来自有限、可控、可枚举的集合（白名单）
- 校验必须发生在 SQL 拼接之前，且失败时绝不继续执行
子查询里写 ORDER BY 也一样危险，还容易被忽略
比如写 SELECT * FROM (SELECT * FROM users ORDER BY ?) t，看似套了一层，其实问题没变：内层 ORDER BY 的字段仍是标识符，不能参数化。而且多数数据库（PostgreSQL、SQL Server、MySQL 8.0+）会直接报错：ORDER BY in subquery is not allowed unless it is accompanied by LIMIT or OFFSET。
更隐蔽的风险是：有人误以为“加了 LIMIT 就安全了”，于是写 ORDER BY ? LIMIT 10。但只要 ? 是用户可控的字段名，依然能注入。LIMIT 只解决语法合法性，不解决标识符注入。
所以结论很直接：所有出现在标识符位置的用户输入——无论在主查询、子查询、CTE 还是视图定义中——都必须走白名单，没有例外。
