node.js 22 不提供 sql 注入防护，防护依赖数据库驱动、orm 和正确写法：必须用参数化查询（如 mysql2/pg 的数组传参）、避免 literal() 拼接、表名列名等结构部分需白名单校验，joi 仅作输入校验不能替代参数化。
Node.js 22 本身不提供 SQL 注入防护能力，防护完全取决于你用的数据库驱动、ORM 和代码写法——只要还在拼字符串，哪怕升级到 Node.js 30 也一样被注入。
mysql2/pg 的参数化查询必须用对
Node.js 22 对 Promise 和模块加载有优化，但 mysql2 和 pg 的参数绑定机制没变。错用占位符或传参方式，等于白防。
-
db.query('SELECT * FROM users WHERE id = ?', [req.query.id])✅ 正确：数组传参触发预编译 -
db.query('SELECT * FROM users WHERE id = ?', req.query.id)❌ 错误：没包成数组，req.query.id被当 SQL 字符串拼接 -
db.query('SELECT * FROM users WHERE name = :name', { name: req.body.name })✅ 仅pg支持命名绑定；mysql2不认:name，会原样传过去 - 使用
db.execute()比db.query()更严格——它强制走预编译，拒绝非参数化调用
Sequelize 中 literal() 是高危红区
Node.js 22 下 Sequelize.literal() 行为没变：它把字符串原样塞进 SQL，不做任何转义。只要里面含 req.*，就是注入入口。
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
-
order: [[literal(`${req.query.sortBy} ${req.query.order}`)]]→ 直接执行ORDER BY id; DROP TABLE users-- -
where: { status: { [Op.eq]: literal(`'${req.query.status}'`) } }→ 单引号是拼进去的，不是字面量 - 安全写法只有：字符串完全静态，不含任何运行时变量，例如
literal('updated_at DESC')或literal('NOW()') - 动态字段排序应走白名单：
const allowed = ['id', 'email', 'created_at']; if (!allowed.includes(req.query.sortBy)) throw 400;
Joi 校验只是筛子，不是防火墙
Joi 再严也拦不住拼接 SQL 的代码。它只负责“输入看起来像人写的”，不负责“执行时不炸库”。
-
joi.string().pattern(/^[\w-]+$/)可挡' OR 1=1，但挡不住admin\0（某些旧驱动存在空字节绕过） -
joi.number().integer()对id类参数有效，但若后续仍用`WHERE id = ${validated.id}`，校验就毫无意义 - 真正起作用的链路只有一条：
req → Joi 校验 → 参数化 query → 数据库执行，缺一不可 - 别用
joi.string().max(50)去“防注入”——长度限制对1; DROP TABLE--这种短 payload 完全无效
最易被忽略的是表名、列名、GROUP BY 字段这些 SQL 结构部分——它们不能用 ? 占位，必须靠白名单硬控；而开发者常以为“Joi 校验了字符串，就万事大吉”。
