sequelize所有模型方法（findall、findone、update、destroy、create）天然防注入，因其自动参数绑定；高危点仅在sequelize.query()字符串拼接、literal()/fn()误用用户输入及动态列名/表名未白名单校验。
Sequelize 默认就是安全的，只要你别主动把用户输入塞进 SQL 结构位置——比如列名、表名、sequelize.query() 字符串里，或用 literal()/fn() 包用户数据。
哪些 Sequelize 方法天然防注入？
所有模型方法（findAll、findOne、update、destroy、create）只要传 plain object，就自动走参数绑定，不拼字符串：
-
Model.findAll({ where: { email: req.query.email } })→email是绑定参数，不是字符串插值 -
Model.update({ status: 'done' }, { where: { id: req.params.id } })→ 数字型id按 INT 类型送入，不会被当 SQL 片段解析 -
attributes: [['username', 'name']]安全，别名只是元数据，不参与 SQL 构建
但注意：attributes 里写 [[req.query.sortBy, 'alias']] 就危险了——列名无法参数化，必须白名单校验。
为什么 sequelize.query() 是唯一高危入口？
它绕过整个模型层，直接对接 SQL 字符串，安全完全取决于你传参方式：
- ✅ 安全：用
replacements或bind，例如sequelize.query("SELECT * FROM users WHERE status = :status", { replacements: { status: req.body.status } }) - ❌ 危险：模板字符串插值，哪怕加了
AS name也无效：`SELECT * FROM users WHERE id = ${req.params.id}` - ⚠️ 混用占位符会报错：
:status（命名绑定）和?（位置绑定）不能共存于同一查询
别信“加了别名就安全”——别名对拼接零防护作用。
literal() 和 fn() 为什么常被误用？
literal() 的设计目标就是“原样输出”，一旦传入用户输入，等于主动关闭参数化：
- ❌ 错误：
where: { [Op.or]: [fn('LOWER', literal(req.query.q))] }——literal()把req.query.q直接塞进 SQL，不转义、不加引号 - ❌ 错误：
order: [[literal(`${req.query.sortBy} ${req.query.order}`)]]—— 可注入id; DROP TABLE users-- - ✅ 安全替代：动态列名 → 白名单校验：
['id', 'name', 'created_at'].includes(req.query.sortBy)；函数包装字段 → 用已知字段：fn('LOWER', sequelize.col('username'))
真正要盯住的不是“有没有调用 validate”，而是“这个变量是否出现在 SQL 结构位置（列名、表名、ORDER BY）还是值的位置”。
白名单校验该在哪做？
必须硬编码在 Controller 层，不能从数据库读、不能靠正则过滤单引号——攻击者早就能绕过：
- 定义允许的排序字段：
const allowedSortFields = ['id', 'name', 'email'] - 取值前校验：
const sortField = allowedSortFields.includes(req.query.sortBy) ? req.query.sortBy : 'id' - 再传给查询：
order: [[sortField, 'ASC']] - 同理适用于表名、
GROUP BY字段、多租户WHERE tenant_id = ?中的租户标识（若来自 header，需映射到白名单）
最容易被忽略的是：所有用户输入入口（req.query、req.params、req.headers、甚至 req.ip）只要进了 SQL，就必须走参数化或白名单——Controller 层的 parseInt() 只是 fail-fast，不是安全动作。
