动态列名无法参数化，是sql注入高危区；数据库只对值参数化，表名列名等语法结构必须编译前确定，quotename或format仅保语法安全，白名单校验才是唯一可靠方案。
动态列名无法被参数化，这是 SQL 注入高危区——任何把用户输入直接拼进 SELECT、ORDER BY、GROUP BY 或 AS 后面的操作，都等同于给攻击者开了数据库的后门。
为什么不能对列名用 ? 占位符或绑定参数
数据库引擎（MySQL/PostgreSQL/SQL Server）只对「值」做参数化处理，比如 WHERE name = ? 中的 ?；但列名、表名、排序方向（ASC/DESC）、函数名属于语法结构，必须在 SQL 编译前就确定。你传一个 @col = 'id; DROP TABLE users--' 进 sp_executesql，它照样会当成标识符去解析，不会转义。
常见错误现象：
- 用
DB::raw("order by {$request->input('sort')}")在 Laravel 里构造排序 —— 用户传sort=name; WAITFOR DELAY '0:0:5'--就能盲注 - SQL Server 存储过程中写
ORDER BY @sortcol而没用QUOTENAME(@sortcol)—— 攻击者可注入name ASC, (SELECT @@version) - PostgreSQL 里用
format('SELECT %I FROM table', user_input)却忘了%I只防单引号，不防 Unicode 同形字或嵌套注释
白名单校验是最简最稳的方案
别试图“过滤掉危险字符”，正则很难覆盖 /*/**/union、全角引号、十六进制编码等绕过手法。直接限定合法值范围，才是唯一靠谱路径。
实操建议：
- Laravel 控制器中用
validate()强制字段值落在预设集合内：'sort_field' => 'required|in:name,price,created_at' - PHP 原生场景下，用
in_array($input, ['status', 'type', 'updated_at'], true)判定，严格开启strict模式 - Node.js + Knex 场景，先映射用户输入到内部字段：
const colMap = { sort: 'products.name', dir: 'ASC' }; const sql = `ORDER BY ${colMap.sort} ${colMap.dir}` - Java MyBatis 中避免
${column}，改用<if test="sort == 'price'">ORDER BY price</if>分支硬编码
运行时防护：QUOTENAME 和 format() 不是万能解药
SQL Server 的 QUOTENAME(@col) 和 PostgreSQL 的 format('%I', col) 确实能闭合引号、转义特殊字符，但它们只解决「语法安全」，不解决「语义安全」。
容易踩的坑：
-
QUOTENAME对空字符串返回[]，若用户传空值，可能生成ORDER BY []导致语法错误暴露结构 -
format('%I', 'user_input')在 PostgreSQL 中不校验该标识符是否真实存在于表结构中 —— 攻击者仍可传一个不存在的列名触发报错，进而探测 schema - MySQL 没有原生
QUOTE_IDENT()函数，靠CONCAT('`', REPLACE(col, '`', '``'), '`')手动转义，极易漏掉换行或控制字符 - 所有这类函数都假设输入是 ASCII 字符 —— 遇到带 emoji 或 CJK 字符的列名时，部分驱动会截断或乱码
真正难处理的是那些需要支持「任意自定义字段」的后台系统，比如低代码平台或报表工具。这时候白名单得做成配置项或数据库元数据查询，且每次变更都要走审批；临时绕过白名单的行为，几乎必然引入漏洞。别信“加个日志就能兜底”——日志记录不了已执行的恶意查询，也拦不住权限提升后的横向移动。
