动态表名不能参数化是数据库语法硬限制，因编译期需确定对象结构，变量仅运行时存在；必须通过白名单校验+quotename()封装双重防护，缺一不可。
动态表名为什么不能参数化
数据库引擎根本不允许在FROM、JOIN或INSERT INTO后面用@tablename这类占位符——这不是写法问题，是语法层级的硬限制。你一试就会收到类似Incorrect syntax near '@'或ORA-00903: invalid table name的报错。参数化只保护“值”，不保护“结构”。把表名塞进sp_executesql的参数列表里，SQL Server会直接拒绝执行。
白名单必须硬编码在代码里，不能从配置读
很多人以为“配置表由管理员维护，所以可信”，但低权限攻击者只要拿到一个后台 XSS 或弱口令，就能篡改log_table_name字段，让应用拼出logs; DROP TABLE users --。白名单校验动作必须落在 SQL 构造之前，且不可被运行时绕过：
-
allowed_tables = ["user_events", "order_logs", "pay_records"]——必须是字面量列表，不是从 DB/Redis/配置中心加载 - 校验失败立即抛
IllegalArgumentException或ValueError，绝不进入 DAO 层 - 正则兜底要严格：
^[a-z][a-z0-9_]{2,31}$（小写字母开头、3–32 字符、仅字母数字下划线）
MyBatis 里 ${} 不是“用了再说”，是高危信号
${} 是纯字符串替换，MyBatis 完全不介入预编译，#{} 对它毫无约束力。典型危险写法：
SELECT * FROM ${config.tableName} WHERE id = #{id}
这里#{id}安全，但${config.tableName}已失守。修复路径只有一条：
- Java 层先查白名单字典：
safeTable = tableMap.get(userInput) - 查不到就拒掉，不往下传
- 最后用
String.format("SELECT * FROM %s WHERE id = ?", safeTable)拼接——拼的只是已确认合法的字符串
SQL Server 存储过程中拼表名，QUOTENAME() 不够用
QUOTENAME(@table_name)能防users]; DROP TABLE admins--这类闭合攻击，但它不校验语义合法性。攻击者传sys.tables或##temp，QUOTENAME照单全收。真正安全的做法是三段式：
- 先用白名单映射：
CASE @input WHEN 'orders_2024' THEN 'orders_q1' ELSE THROW 50000, 'Invalid table', 1 END - 再用
QUOTENAME()封装映射后的结果 - 最后进
sp_executesql模板：SELECT * FROM ' + @safe_quoted_name + ' WHERE ...
漏掉任何一段，都等于把门虚掩着。白名单校验必须在QUOTENAME之前，否则后者只是给恶意输入套了个安全壳。
