因为SQL标准和驱动层仅支持对“值”参数化，不支持对表名、字段名等语法结构参数化；?和:name占位符在服务端解析时被识别为数据而非标识符，直接用于表名会导致语法错误。
为什么 ? 不能用在表名和字段名上
MySQL 的 PDO::prepare() 和 mysqli::prepare() 中的 ? 或命名参数（如 :name）只被设计为“值占位符”，底层由服务端 SQL 解析器识别并做类型绑定。表名、字段名、ORDER BY 子句、GROUP BY 字段等属于 SQL 语法结构的一部分，不是“数据值”，服务端不会也不允许对它们做参数化处理。
常见错误现象包括：
PDOException: SQLSTATE[HY000]: General error: 1064 You have an error in your SQL syntax...mysqli_sql_exception: Unknown column '?' in 'field list'- 拼出的 SQL 看似正确，但执行时报错，尤其在动态字段或分表场景下
这跟字符集、连接状态无关，是 MySQL 协议层的硬性限制。
表名/字段名动态拼接前必须白名单校验 你无法用参数化绕过这个限制，但可以安全地拼——前提是来源可控、校验严格。
使用场景包括：多租户按客户分表、日志按月分表、用户可选排序字段（如 sort=created_at）、API 支持动态 select 字段。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 白名单优先：把允许的表名/字段名列成数组，用
in_array($input, $whitelist, true)判断 - 正则兜底（仅当白名单不现实时）：用
preg<em>match('/^[a-zA-Z</em>][a-zA-Z0-9_]*$/', $input)校验标识符格式，注意不能以数字开头 - 绝对不要用
mysqli_real_escape_string()处理表名——它只转义字符串值中的引号，对语法结构无效，且可能因连接未初始化返回false - 若来自 URL 参数（如
?table=users），校验必须在解析后立即执行，不能延迟到拼 SQL 前一刻才做
MySQL 服务端 PREPARE 动态 SQL 的正确写法
当白名单+拼接不可避免时，MySQL 内部的 PREPARE + EXECUTE 是唯一可行路径，但它仍需手动拼字符串，所以校验环节不可跳过。
关键点：
-
@sql必须是完整字符串，用CONCAT()拼接，所有标识符（表名、字段名）都直接嵌入 - 值位置仍用
?，执行时用USING传变量，例如USING @status_value -
USING后只能跟用户变量（@xxx），不能是字面量（USING 'active'报错） - 多个
?时，USING的变量顺序和数量必须严格对应，否则报SQLSTATE HY000 - 拼接前检查空值：比如
WHERE条件可能为空，得用IF(@where != '', CONCAT(' WHERE ', @where), '')避免生成SELECT * FROM t WHERE这种非法语句
最容易被忽略的坑：PDO 模拟预处理开关
即使你写了 $pdo->prepare("SELECT * FROM {$table} WHERE id = ?")，如果没关掉模拟预处理，PDO 会在客户端“假装”做了服务端预处理，实际仍是字符串拼接，等于白做防护。
必须显式设置：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)- 同时确保连接 DSN 中指定了字符集，如
charset=utf8mb4，否则某些特殊字符可能触发服务端解析异常
白名单校验和 ATTR_EMULATE_PREPARES = false 是两道独立防线：前者防动态标识符注入，后者防值层面的绕过。少一个，整个防护就塌一半。
