动态字段名拼接必须白名单校验，且参数绑定须用计算属性语法；jsonb模糊查询需确保字段为jsonb类型并建gin索引；复杂场景应改用原生sql+占位符参数化。
动态字段名拼接必须白名单校验
TypeORM 的 andWhere 不支持对字段名（如 JSONB 路径 row_data->>'Location' 中的 Location）做参数化，直接用 ${key} 拼接会触发 SQL 注入。攻击者可传入 Location'; DROP TABLE users; -- 类似 payload。
正确做法是预先定义允许过滤的字段列表，并严格校验：
const allowedKeys = ['Location', 'Status', 'Department', 'CreatedAt'];- 循环中先判断：
if (!allowedKeys.includes(key)) continue; - 绝不依赖客户端传来的任意字符串作为字段名或表名
命名参数绑定必须用计算属性语法
动态生成参数名时，若写成 { paramName: value }，TypeORM 会查找字面量键 "paramName"，而非你期望的 "searchVal1"，导致参数未绑定、查询失败甚至暴露原始错误。
必须使用方括号语法确保键名动态解析：
- ✅ 正确：
query.andWhere(`myTable.row_data->>'${key}' ILIKE :${paramName}`, { [paramName]: `%${value}%` }); - ❌ 错误：
{ paramName: `%${value}%` }—— 这等价于{ "paramName": "xxx" }，TypeORM 找不到:searchVal1 - 参数名建议带前缀（如
searchVal1），避免和固定参数（如:id）冲突
JSONB 模糊查询需确认数据库配置
row_data->>'Location' 是 PostgreSQL 特有语法，提取 JSONB 字段值为 text 后做 ILIKE。这要求：
- 目标列类型确实是
JSONB（不是JSON或TEXT） - 已创建 GIN 索引：
CREATE INDEX idx_row_data_gin ON myTable USING GIN (row_data); - 若字段可能为
NULL或路径不存在，->>返回NULL，ILIKE会跳过该行 —— 这是预期行为，无需额外IS NOT NULL
更安全的替代方案：改用原生查询 + 参数化
当过滤逻辑复杂、字段多变且无法预设白名单时，硬编码白名单会失去灵活性。此时应放弃 QueryBuilder，改用 queryRunner.query() 配合完全参数化的原生 SQL：
- 字段名仍需白名单校验（不可绕过）
- 值部分全部用
$1,$2占位符，由驱动层绑定，彻底隔离数据与结构 - 示例：
await queryRunner.query(`SELECT * FROM myTable WHERE row_data->>$1 ILIKE $2`, [key, `%${value}%`]); - 注意：
queryRunner需手动获取，且事务上下文需自行管理
白名单校验和计算属性参数绑定这两步漏掉任何一项，都可能让防护形同虚设。字段名不校验，参数再安全也挡不住注入；参数名写错，查询直接报错，还可能把内部结构暴露给攻击者。
