动态字段名不能用参数化查询，因为占位符仅适用于值而非标识符（如表名、列名），数据库驱动无法安全转义标识符；必须通过白名单校验+显式映射表（如FIELD_MAP）限定合法字段，并对映射值正则校验及反引号包裹后拼接。
动态字段名为什么不能用参数化查询
因为 cursor.execute() 的占位符（如 %s）只适用于**值（value）**，不适用于**标识符（identifier）**——也就是表名、列名、排序字段、GROUP BY 字段等。数据库驱动在预处理阶段不会、也不能对这些位置做安全转义；强行塞进去只会报错或被当作字符串字面量处理。
常见错误现象：Unknown column 'user_name' in 'field list'（实际传入的是字符串 'user_name' 而非字段名 user_name），或者直接抛出 ProgrammingError。
所以，当字段名来自用户输入（比如前端传来的 sort_by=created_at 或 API 的 fields=name,email），必须走另一条路：白名单校验 + 显式映射。
用字段映射表替代“自由拼接”
核心思路是：把用户能操作的字段名，限定为服务端硬编码的一组合法键（key），再通过映射表转成真实数据库字段（value）。这样既保留灵活性，又杜绝任意字符串进入 SQL。
示例场景：API 支持按不同字段排序，但只允许 name、email、created_at 三类：
FIELD_MAP = {
"name": "user_name",
"email": "user_email",
"created_at": "created_time"
}使用时：
- 先检查请求参数
sort_by是否在FIELD_MAP的 key 中 - 若存在，取对应 value（如
FIELD_MAP["name"] → "user_name"）用于拼接 SQL - 若不存在，直接拒绝请求（HTTP 400），不进数据库层
注意：映射表必须是字面量定义，不能从配置文件或数据库读取——否则攻击者可能污染映射源。
字段名拼接前必须做双层校验
仅靠映射表还不够。如果映射逻辑写得松散（比如用 getattr() 或 eval() 动态取值），或映射值本身含非法字符，仍可能触发注入。务必加两道保险：
- 映射 value 必须是纯字母数字下划线组合，可用正则
^[a-zA-Z_][a-zA-Z0-9_]*$强制校验 - 拼接到 SQL 前，用数据库驱动提供的标识符转义函数（如 MySQL 的
mysql.escape_string()不适用；应改用backticks包裹 + 手动过滤） - 更稳妥做法：拼接时统一用反引号包裹，且只接受映射表中已验证过的 value ——例如
ORDER BY `user_name`
错误示范："ORDER BY " + FIELD_MAP.get(user_input, "id") —— 没校验 value 内容，万一映射值被篡改为 "id`; DROP TABLE users; -- " 就完蛋。
为什么不用 real_escape_string() 处理字段名
mysqli_real_escape_string() 和 mysql.escape_string() 等函数，设计目标是转义**字符串值中的特殊字符**（如单引号、反斜杠），它们对字段名无效，也不起作用。
尝试对字段名调用这类函数，结果可能是：`user\_name`（带反斜杠），导致 MySQL 报错 Unknown column 'user\_name' in 'order clause'；或者更糟——它没拦住恶意内容，反而让 SQL 语法变得奇怪但可执行。
真正该做的，是把字段名控制在极小、确定、静态的集合内，并用代码逻辑确保每次拼接都只从中取值。动态性必须由映射表承载，而不是由字符串处理函数兜底。
