PDO 预处理语句的参数仅支持标量值（如字符串、数字），不支持表名、列名等 SQL 标识符，因为参数是在 SQL 解析之后才代入的，而标识符必须在解析阶段就确定其语法和语义合法性。
php 中 pdo 预处理语句的参数仅支持标量值（如字符串、数字），不支持表名、列名等 sql 标识符，因为参数是在 sql 解析之后才代入的，而标识符必须在解析阶段就确定其语法和语义合法性。
在使用 PDO 的 prepare() 和 execute() 时，很多人误以为 :param 占位符是“字符串模板替换”，但实际上它代表的是运行时绑定的参数值（parameter binding），其设计核心在于安全与性能的平衡。
✅ 参数的本质：解析后注入，而非字符串拼接
当调用 $pdo->prepare('SELECT * FROM users WHERE id = ?') 时，数据库会立即对这条 SQL 进行词法分析 → 语法解析 → 语义校验（例如检查 users 表是否存在、id 列是否有效）。此时占位符 ? 被识别为一个待填入的标量常量位置（scalar placeholder），类似 C 语言中的 int x —— 类型已知、用途明确，但值暂未确定。
因此，后续 execute([123]) 只是将 123 作为字面量值（literal value） 注入到已编译的执行计划中，不会触发重新解析，也不会改变 SQL 结构。
❌ 为什么表名不能参数化？
试看以下非法写法：
$stmt = $pdo->prepare('SELECT * FROM :table');
$stmt->execute(['table' => 'users']); // ⚠️ 报错：SQL syntax error原因在于：SQL 解析器在 prepare() 阶段看到 FROM :table，会尝试将其解析为 FROM <identifier>，但 :table 并非合法标识符——它既不是关键字，也不是引号包裹的名称（如 "users"），更不是可推导为对象名的常量。数据库无法在解析时确认该位置应是一个表名，故直接报语法错误。
更重要的是，即使数据库允许 FROM 'users'（带引号的字符串字面量），它也不等于表名：
SELECT * FROM 'users'; -- ❌ 语法错误：不能从字符串字面量查询 SELECT * FROM "users"; -- ✅ 正确：双引号表示标识符（标准 SQL）
而参数绑定永远生成的是值（value），不是标识符（identifier）。你无法通过参数让数据库把 'users' 当作表名来理解 —— 它只会被当作字符串值，用于 WHERE name = ? 这类上下文，而非 FROM ?。
✅ 安全替代方案：白名单校验 + 字符串拼接
若需动态表名，唯一安全做法是严格白名单校验后拼接：
$allowedTables = ['users', 'posts', 'comments'];
if (!in_array($tableName, $allowedTables, true)) {
throw new InvalidArgumentException('Invalid table name');
}
$sql = "SELECT COUNT(1) FROM {$tableName}";
$stmt = $pdo->prepare($sql);
$stmt->execute();切勿依赖 addslashes() 或 htmlspecialchars() —— 它们无法阻止标识符注入（如 users; DROP TABLE posts 在某些场景下仍可能被利用）。
? 补充说明：模拟预处理的陷阱
当启用 PDO::ATTR_EMULATE_PREPARES => true（默认开启）时，PDO 会在客户端模拟参数绑定，即内部做字符串替换。这看似“允许”任意内容，但完全丧失预处理的安全性与性能优势，且仍无法解决标识符参数化问题（因为模拟逻辑同样无法绕过 SQL 解析规则）。
✅ 总结：PDO 参数 ≠ 模板变量；它是数据库引擎层面的类型化值绑定机制。表名、列名、排序方向（ORDER BY ?）、LIMIT ? 等涉及语法结构的位置，均不可参数化——必须通过业务层校验 + 显式拼接实现，且务必限制为可信枚举值。
