Sequelize的findAll等模型方法默认采用预编译参数化查询，安全性不受attributes字段别名影响；危险操作仅出现在sequelize.query()字符串拼接、动态列名未白名单校验、或fn/literal包裹用户输入等场景。
Sequelize 的 findAll 默认就是参数化查询，别名不会破坏安全性
只要不用 sequelize.query() 拼接字符串，findAll、findOne、update 等模型方法内部自动走预编译流程。即使你用 attributes 给字段起别名，比如 { attributes: [['username', 'name']] }，Sequelize 也只把别名当元数据处理，不参与 SQL 拼接逻辑。
容易踩的坑：
- 误以为“用了别名就得手动转义”——其实完全不需要，别名本身不接收用户输入
- 在
attributes里混入动态表名或列名（如[[inputField, 'alias']]）——这是危险操作，列名不能来自用户输入 - 把别名和用户值写在同一层对象里，导致混淆作用域，例如错误地写成
where: { [inputKey]: inputValue }—— 这里inputKey是列名，必须白名单校验
sequelize.query() 是唯一可能翻车的地方，别 alias 掩盖拼接风险
当你必须用原生 SQL（比如复杂窗口函数、跨库 JOIN），sequelize.query() 就成了高危接口。此时加别名没用，关键看你怎么传参：
- ✅ 安全写法：用
replacements或bind，例如sequelize.query("SELECT u.username AS <code>nameFROM users u WHERE u.id = :id", { replacements: { id: req.params.id } }) - ❌ 危险写法：字符串模板里直接插变量，哪怕加了别名，例如
`SELECT username AS name FROM users WHERE id = ${req.params.id}`—— 别名救不了拼接 - ⚠️ 注意占位符语法差异：
:id（命名绑定）和?（位置绑定）不能混用；replacements只支持命名，bind支持数组位置绑定
预编译不是“开关”，而是 Sequelize 的默认行为机制
Sequelize 在底层调用 mysql2 或 pg 时，对所有模型方法都走的是 execute + 参数绑定路径，不是简单字符串替换。这意味着：
- 即使你写
where: { status: { [Op.or]: ['active', req.body.status] } }，req.body.status也会被当作独立参数送入预编译语句 - 类型自动推导会影响绑定方式：数字会被传为
INT类型参数，字符串为VARCHAR，避免引号逃逸问题 - 但如果你在
where中用了$raw或fn包裹用户输入（如fn('LOWER', literal(req.body.q))），就绕过了参数化——这种写法极少必要，应避免
真正需要人工干预的只有三类地方
别名本身不引入风险，但以下场景必须主动防御：
- 动态列名/表名：只能从白名单中取，例如
const allowedFields = ['username', 'email']; if (!allowedFields.includes(inputField)) throw new Error('Invalid field'); - 动态排序字段：
order: [[inputSortField, 'ASC']]→ 同样需白名单校验，不能依赖parseInt或类型转换 - 原始 SQL 中的非参数部分：比如
UNION SELECT ...后面的子查询结构，这部分无法参数化，必须靠输入过滤+权限隔离兜底
最常被忽略的一点：ORM 安全性只覆盖“查询构造”环节，不覆盖“连接权限”。哪怕代码 100% 参数化，数据库账号仍有 DROP TABLE 权限，一次注入失败的尝试也可能触发权限滥用。生产环境务必用专用低权账号。
