sequelize 中天然防注入的方法包括 findall、update、destroy 等所有基于模型调用且不使用原生 sql 的方法；它们默认启用预编译参数绑定，而 sequelize.query()、literal() 和 fn() 若误用用户输入则易导致注入。
Sequelize 在 Node.js 20 下默认仍是安全的，但风险只集中在三个地方：手动拼接 sequelize.query() 字符串、把用户输入塞进 literal() 或 fn()、以及未经校验就当列名/表名用。其他所有模型方法（findAll、update、destroy）都自动走参数化，不用额外操作。
哪些 Sequelize 方法天然防注入？
所有基于模型实例或模型类调用的方法，只要不碰原生 SQL，就默认启用预编译参数绑定：
-
Model.findAll({ where: { email: req.query.email } })——req.query.email被当作独立参数传入，不是字符串拼接 -
Model.update({ status: 'done' }, { where: { id: req.params.id } })—— 数字型id自动按 INT 类型绑定，避免引号逃逸 -
Model.findOne({ 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 } }) - ❌ 危险：模板字符串插值，哪怕加了别名也无效
`SELECT username AS name FROM users WHERE id = ${req.params.id}` - ⚠️ 混用占位符会报错：
:status（命名绑定）和?（位置绑定）不能共存于同一查询
常见错误是以为“加了 AS 就安全”，其实别名对拼接无任何防护作用。
为什么 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'].includes(req.query.sortBy)
函数包装字段 → 用已知字段：fn('LOWER', sequelize.col('username'))
复杂计算 → 改用sequelize.cast()或应用层处理
真正容易被忽略的是 fn() 的第二个参数：如果它是 literal() 包裹的用户输入，整个函数调用就失效。
最危险的组合不是“用了 literal”，而是“以为 fn + literal = 安全封装”。只要值来自 req.*，就必须确保它停留在参数层，而不是滑进 SQL 字符串上下文。
