ORDER BY后字段名不能参数化是SQL语法硬限制，因数据库仅允许占位符绑定“值”而非“标识符”，预编译会为#{field}加引号导致语义错误，${field}需严格白名单校验。
ORDER BY 后的字段名不能被参数化是 SQL 语法层硬限制
不是 MyBatis、JDBC 或数据库驱动“没做好”，而是所有主流数据库（MySQL、PostgreSQL、SQL Server）明确禁止在 ORDER BY 后使用占位符（如 ? 或 #{field}）来代表列名。你写 SELECT * FROM user ORDER BY ?，数据库会把 ? 当作一个字符串字面值排序，比如按常量 'username' 排——所有行都排在同一位置，毫无意义。
根本原因是：预编译只支持绑定“值”（value），而 ORDER BY 后需要的是“标识符”（identifier），包括列名、表名、函数名、排序方向等。这类结构成分在 SQL 解析阶段就必须确定，无法延迟到执行时由参数注入。
-
#{sortField}会被自动加单引号，变成ORDER BY 'username'→ 语法合法但语义错误 -
${sortField}是纯字符串替换，不加引号 → 语法正确，但完全裸奔，必须白名单兜底 - 同理失效的还有：
GROUP BY ${col}、FROM ${table}、SELECT ${func}()
MyBatis 中 ${} 不等于“能用”，而是“必须额外校验”
很多人看到日志里 ORDER BY username ASC 跑通了，就以为 ${sortField} 安全。其实这只是侥幸——只要前端传入 id; DROP TABLE user-- 或 IF(1=1, id, email)，就会原样拼进 SQL，直接触发注入。
MyBatis 的 ${} 不做任何转义、过滤或拦截，它和 Java 里的 String.format("ORDER BY %s", field) 效果完全一致。
- 危险组合：
ORDER BY ${sortField} ${sortOrder}—— 两个变量都需独立白名单 - XML 中写
<if test="sortField == 'name' || sortField == 'email'">ORDER BY ${sortField}</if>是可行的，因为 OGNL 表达式在 SQL 组装前执行 - 千万别写
<otherwise>ORDER BY ${sortField}</otherwise>—— 这等于留后门 - Java 层校验（如 Controller 里
if (!ALLOWED.contains(sort)) throw）可能被反射、中间件、自动绑定绕过
子查询里写 ORDER BY 也不生效，别指望它“兜底”
有人试图用子查询“先排序再分组”，比如：SELECT * FROM (SELECT * FROM orders ORDER BY created_at DESC) t GROUP BY user_id。这在 MySQL 5.7+ 中大概率失效——优化器会直接丢掉子查询里的 ORDER BY，因为派生表（derived table）在 SQL 标准中被视为无序集合。
即使加上 LIMIT 让语法通过（如 LIMIT 999999999），也只是干扰优化器，不是可靠方案。真正可控的做法是用窗口函数：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，再过滤 rn = 1。
- PostgreSQL / SQL Server 会直接报错：
ORDER BY in subquery is not allowed unless accompanied by LIMIT - MySQL 8.0+ 默认也拒绝，除非显式加
LIMIT或OFFSET ... FETCH - 视图、CTE、UNION 分支中的
ORDER BY同样不可信，最终顺序必须由最外层查询的ORDER BY决定
白名单必须精确到“字段+方向+格式”，不能只过滤字符
正则 ^[a-zA-Z0-9_]+$ 看似安全，但挡不住 id ASC, (SELECT password FROM user) 这种攻击。白名单必须是穷举合法组合，而非字符规则。
推荐做法是定义一个映射表，比如：Map.of("created_at_asc", "created_at ASC", "amount_desc", "amount DESC")，前端只传键（如 sort=amount_desc），后端查表取值。这样连大小写、空格、多余逗号都被天然隔离。
- 字段名本身也要最小化校验：长度 ≤ 64、不能以数字开头、只含字母/下划线/数字
- 若用 MyBatis-Plus，禁用
QueryWrapper.orderBy(true, true, "user_name")，改用具名方法如orderByAsc("user_name") - 导出类功能尤其高危——用户可构造任意请求，且往往不走常规接口鉴权，白名单必须落在 DAO 层最前端
关键点在于：ORDER BY 注入不报错、不中断、不抛异常，它静默地返回错误数据或执行恶意逻辑。你以为只是排序不对，实际可能是密码已泄露。
