参数化查询无法防护动态表名SQL注入，因数据库驱动不支持表名参数化；必须用白名单校验+预定义映射，禁止正则过滤或动态加载，分表场景需服务端生成表名并严格校验租户ID。
为什么不能拼接动态表名
SQL注入防护里，参数化查询能拦住 WHERE 条件里的用户输入，但对表名、字段名、排序字段这类“SQL结构部分”完全无效——数据库驱动根本不允许把 table_name 当参数占位符处理。一旦你写 SELECT * FROM ' + user_input + ' WHERE id = ?，攻击者输个 users; DROP TABLE users; --，语句就变成两条执行，参数化也救不了。
替代方案：白名单校验 + 预定义映射
动态表名必须来自受控集合，不能靠正则“过滤非法字符”糊弄——比如用 /^[a-zA-Z_][a-zA-Z0-9_]*$/ 仍可能绕过（某些数据库支持双下划线前缀扩展或大小写敏感别名）。真实可行的做法是：
- 维护一个明确的表名白名单，例如
const VALID_TABLES = ['orders', 'products', 'users'] - 用户传入标识符（如 API 路径中的
/api/v1/:resource），查表映射到实际表名：const table = TABLE_MAP[resource] || null - 映射表必须硬编码或从只读配置加载，禁止从数据库、环境变量、外部文件动态读取
ORM 或 Query Builder 怎么处理
主流 ORM（如 Sequelize、TypeORM）和 Query Builder（如 Knex）默认也不支持参数化表名。它们的“安全”只是错觉：
-
knex('users').where('id', userInput)安全，但knex(userInput).select()直接崩 - Sequelize 的
model.findAll({ where: { ... } })拦不住model = sequelize.define(userInput, ...) - 所有框架都要求你在调用前自己做白名单判断，框架不代劳
万一真要支持多租户分表或归档表
业务上真有按时间/租户分表需求（如 logs_202401、tenant_123_orders），不能靠字符串拼接加“严格过滤”，而要：
- 用固定格式生成表名：比如
logs_${year}${month.padStart(2, '0')}，其中year和month来自服务端计算，不接受用户输入 - 租户 ID 必须走认证上下文提取（如 JWT payload 中的
tenant_id），且该字段需在白名单中预注册，不能直接拼进 SQL - 分表逻辑收口到 DAO 层，对外暴露统一接口，避免业务代码接触表名构造
最麻烦的地方在于：白名单得随业务演进同步更新，漏加一个表，线上就报错；加错一个拼写，就等于开了后门。这事没法自动化，只能人盯人。
