TypeScript本身不防SQL注入，因其类型检查仅验证结构合法性而非运行时安全性；string类型无法阻止攻击者通过ORDER BY列名拼接恶意语句，因类型校验发生在编译期，而SQL注入在运行时执行，且参数化查询必须真正隔离用户输入与SQL结构，动态字段需白名单校验。
TypeScript本身不防SQL注入，靠的是你写的代码是否隔离了用户输入和SQL结构——类型系统只管“像不像”，不管“安不安全”。
为什么string类型拦不住SQL injection
TypeScript编译器看到sortColumn: string就放行，但数据库执行的是ORDER BY name; DROP TABLE users; --。类型检查发生在编译期，而SQL注入在运行时触发，两者完全不在同一层。
- 任何用
+或模板字符串拼接用户输入进SQL的地方，都是高危点 -
any、unknown或未校验的req.query/req.body字段，会绕过类型约束直接进查询 - ORM的“链式调用”（如
where({ [sortColumn]: value })）如果sortColumn来自请求，仍可能被解析为操作符（尤其在MongoDB等NoSQL中）
必须用参数化查询，且要真正参数化
不是“用了占位符”就算安全，而是占位符必须由驱动或ORM原生支持，并且不经过字符串拼接中间层。
- ✅ 正确：
db.query('SELECT * FROM users WHERE id = $1', [userId])（PostgreSQL原生参数） - ✅ 正确：
userRepository.find({ where: { id: userId } })（TypeORM自动转义） - ❌ 危险：
db.query(`SELECT * FROM users WHERE ${filter}`)—— 即使filter是string类型 - ❌ 危险：
db.query('SELECT * FROM users WHERE ' + unsafeWhereClause)
注意：PgTyped这类工具强制$minAge语法，本质是把参数名映射到驱动级占位符，比手写更难出错，但前提是别绕过它去拼字符串。
动态字段（如ORDER BY列名）必须白名单校验
参数化查询无法处理列名、表名、排序方向这类“结构部分”，它们不属于数据，不能当参数传。
- 用
z.string().refine(value => ['name', 'email', 'created_at'].includes(value))（Zod） - 或
@IsIn(['name', 'email'])装饰器（class-validator） - 避免用
Object.keys(entitySchema)动态生成白名单——schema可能被污染 - 排序方向同理：
order: 'ASC' | 'DESC'比string安全得多
别信“ORM自动防护”，查清你用的query builder是否真转义
TypeORM的createQueryBuilder()默认安全，但.where()里如果传入{ [userInput]: value }，就可能触发MongoDB风格的键名注入（如$ne）。
- PostgreSQL/MySQL场景下，优先用
.where('id = :id', { id: userId })语法，明确区分参数名与结构 - 使用
escape类辅助函数（如pg-format）前，确认它只用于白名单内的字段，且不拼接用户值 - 对NoSQL（如MongoDB），Zod的
.regex(/^[a-zA-Z0-9_]+$/)比单纯string()更能防$gt类操作符注入
最易被忽略的一点：环境变量加载的SQL片段、i18n文案里的查询模板、甚至migration文件里的raw语句——这些地方一旦混入运行时输入，参数化机制就彻底失效。
