node.js中仅调用query方法不防注入，必须用参数化占位符（如mysql2用?、pg用$1）将用户输入作为独立参数绑定，而非字符串拼接；orm如sequelize/prisma默认安全，但raw查询或动态列名仍需白名单校验。
Node.js里用query传参为什么还会被注入？
直接拼接SQL字符串，哪怕用了query对象，照样中招。比如db.query(`SELECT * FROM users WHERE id = ${req.query.id}`)——req.query.id是用户可控的，攻击者传id=1 OR 1=1就完事了。关键不是“用了query”，而是“有没有把参数当数据而非代码处理”。
MySQL和PostgreSQL各自怎么安全传参？
不同驱动语法不同，硬背错一个符号就执行失败或绕过防护。
- MySQL（
mysql2）：用?占位符，参数数组顺序必须严格对应，db.query('SELECT * FROM users WHERE name = ? AND age > ?', ['Alice', 18]) - PostgreSQL（
pg）：用$1、$2编号占位符，支持命名参数$name，但需配合pg的values字段，client.query('SELECT * FROM users WHERE id = $1', [req.query.id]) - 别用
escape()或mysql.escape()手动转义——它只对字符串生效，数字、布尔等类型不处理，且容易漏掉嵌套结构里的字段
ORM如Sequelize或Prisma能自动防注入吗？
能，但前提是别自己拼SQL。Sequelize的where对象、Prisma的findUnique等方法默认走参数化查询；一旦你写raw()或unsafe模式，防护就失效。
- Sequelize里避免
sequelize.query('SELECT * FROM users WHERE ' + req.query.condition)，改用Model.findAll({ where: { status: req.query.status } }) - Prisma中
prisma.user.findMany({ where: { email: { contains: req.query.q } } })是安全的；但prisma.$queryRaw`SELECT * FROM users WHERE ${req.query.raw}`就是裸奔 - 注意
LIKE场景：%${keyword}%不能直接插进占位符，得在JS里先做keyword = `%${req.query.q}%`，再传入参数数组
从URL参数到数据库，中间哪几环容易漏防？
很多人只盯着DB层，却忘了路由解析、中间件校验、类型转换这些环节本身就是注入入口。
-
req.query.id可能是字符串"1; DROP TABLE users;"，即使后面用了参数化，如果没做类型校验，可能被误传给其他系统（如日志、缓存key） - 路径参数
/user/:id里的req.params.id同样需要校验，parseInt(req.params.id, 10)后判NaN比靠DB层拦截更早止损 - 批量操作如
IN (?)不能直接传数组，mysql2要展开成IN (?, ?, ?)并动态生成占位符；pg支持ANY($1)配合数组参数
最危险的不是不会用占位符，而是以为用了query对象就万事大吉，结果在日志记录、缓存键构造、甚至前端返回字段里又把原始参数原样拼进去。
