$queryRawUnsafe 绝对不可用于用户输入，因其不解析、不转义、不参数化；唯一安全路径是 $queryRaw 配合 Prisma.sql 模板字面量实现参数化，且须严格区分数据（用 ${...}）与结构（需白名单校验）。
$queryRaw 和 $queryRawUnsafe 是 Prisma 中唯一直接执行原生 SQL 的入口，也是注入风险的唯一出口。只要用了 $queryRawUnsafe，就等于主动放弃所有防护——它不解析、不转义、不参数化，传进去的字符串原样交给数据库执行。
为什么 $queryRawUnsafe 一定不能碰用户输入
它设计初衷是执行完全可控的静态 SQL（比如建表语句、迁移脚本），而非动态查询。$queryRawUnsafe 不做任何参数绑定，连 -- 或 # 注释符都照常生效。一旦拼接用户输入，攻击者就能用 1 OR 1=1 -- 或 1'; DROP TABLE users; -- 直接击穿。
- 错误示例：
prisma.$queryRawUnsafe(`SELECT * FROM users WHERE id = ${req.query.id}`) - 哪怕加了
parseInt()，只要没严格校验范围或类型，仍可能被绕过（如id=1.0在某些驱动里仍被接受） -
$queryRawUnsafe的返回值也不做类型检查，错误 SQL 可能静默失败或返回意外结构
$queryRaw + Prisma.sql 是唯一安全路径
$queryRaw 本身不危险，真正起作用的是 Prisma.sql 模板字面量——它把 SQL 字符串和参数分离，交由底层驱动做预编译处理，等效于 PreparedStatement。
- 正确写法：
prisma.$queryRaw`SELECT * FROM users WHERE id = ${parseInt(req.query.id) || 1}` - 参数必须用
${...}插入，且仅支持标量（number/string/boolean/Date）或 Prisma 类型（如Prisma.Decimal） - 不能在模板字符串里拼接变量名或表名，例如
`SELECT * FROM ${tableName}`是非法且不安全的 - 聚合排序等复杂场景（如按嵌套评论总数排序）必须走这条路，否则无法绕过 Prisma 原生限制
哪些地方容易误用字符串拼接
开发者常在“以为安全”的地方翻车：动态字段名、ORDER BY 子句、LIMIT 值、UNION 查询分支。这些都不能靠 ${...} 参数化，因为 SQL 解析器需要它们是语法结构的一部分，而非数据。
- 字段名/表名：必须白名单校验后硬编码，或用 Prisma 的
select/include替代 - ORDER BY：用
if分支预定义合法排序项，如req.query.sort === 'name' ? `ORDER BY name` : `ORDER BY id` - LIMIT/OFFSET：只接受数字，且需
Math.min()限流（如最大 100 条），再传入${limit} - UNION：每个子查询独立用
Prisma.sql构造，禁止拼接整个 UNION 字符串
ORM 安全边界在哪
Prisma 的 findMany、update 等方法默认安全，但一旦调用 $queryRawUnsafe 或在 Prisma.sql 中混用字符串拼接（如 `SELECT * FROM ${table} WHERE ...`），就等于亲手拆掉护栏。
-
Prisma.sql内部不做 SQL 语法分析，它只负责把${...}替换为参数占位符并交由驱动处理 - 所以
Prisma.sql`... ${userInput} ...`是安全的，但Prisma.sql`...` + userInput就彻底失效 - 别依赖框架自动过滤——Prisma 不会帮你清理
--或#，那是你用错 API 的结果
真正的难点不在语法，而在于区分「数据」和「结构」：所有用户能控制的内容，必须作为参数进 ${...}；所有影响 SQL 语法骨架的部分，必须提前锁定、白名单校验、拒绝运行时构造。
