直接字符串拼接动态SQL在NestJS中极危险，必须通过参数化构造（如TypeORM的命名参数）和字段白名单校验来防范SQL注入，禁用${}插值、JSON.stringify包裹或raw string传参。
直接用字符串拼接动态条件的 SQL 在 NestJS 里是危险的，哪怕你用了 TypeORM 或 Prisma —— 真正的安全不靠框架“自动防护”，而靠你控制参数注入点和查询构造方式。
别在 Repository 中手写原始 query + 字符串插值
常见错误是看到 queryRunner.query() 或 connection.query() 就以为能“灵活写 SQL”，结果把用户输入直接拼进 SQL 字符串：
-
WHERE name LIKE '%${req.query.q}%'→ 典型 SQL 注入入口 - 用
JSON.stringify()包裹对象再塞进 SQL → 类型擦除，失去参数绑定能力 - 在
@Query()解构后直接传给createQueryBuilder().where()的 raw string 参数
TypeORM 的 where 方法支持对象、数组、带命名参数的字符串（如 name = :name），但一旦你写成 name = '${name}'，就绕过了所有参数化机制。
动态条件必须走参数化构造，不是“加个 escape”
正确做法是把条件逻辑拆解为可验证的键值对，再交由 QueryBuilder 安全组装：
- 用
Object.entries(filters)遍历条件，对每个 key 检查是否在白名单字段中（如['status', 'createdAt', 'email']） - 对值做类型断言：
if (typeof value === 'string') qb.andWhere(`${key} ILIKE :${key}`, { [key]: `%${value}%` }) - 数值范围用
between而非拼接>= ${min} AND - 多选枚举用
IN (:...statuses)+ 展开数组参数，而非IN (${statuses.join(',')})
Prisma 更简单：where 接收的对象天然参数化，但要注意：嵌套对象（如 { profile: { name: { contains: q } } }）仍需提前校验路径合法性，避免用户传 profile: { __proto__: ... } 触发原型污染。
复杂动态查询优先交给数据库视图或存储过程
当条件组合爆炸（比如 12 个可选字段 + 多级关联 + 权限过滤），硬编码 andWhere 链会失控且难测。这时应：
- 在数据库侧建视图（
CREATE VIEW user_search AS ...），把权限逻辑、软删除、租户隔离等固化进去 - 让 NestJS 只负责传参调用视图：
prisma.$queryRaw`SELECT * FROM user_search WHERE status = ${status}`—— 此时$queryRaw是安全的，因为参数仍走 PostgreSQL 的pg绑定 - 避免在应用层拼接表名、列名；如真需动态表（分表场景），必须从预定义映射表查，例如
const table = TABLE_MAP[tenantId]，而非tenantId + '_users'
真正容易被忽略的点：ORM 的“安全”只覆盖数据层参数，不覆盖元数据（表名、列名、排序字段）。只要涉及这些，就必须走白名单校验，不能依赖任何运行时反射或用户输入直译。
