ent框架本身不防sql注入，仅在使用ent.predicate或ent.query链式调用时安全；手动拼接sql、用where()传原始字符串即失效。
Ent 框架本身不防 SQL 注入——它只在你用 ent.Predicate（如 user.UsernameEQ、user.AgeGT）或 ent.Query 链式调用时才安全；一旦你手动拼接 SQL 字符串、调用 Where(...) 传入原始字符串，防线就立刻失效。
哪些 Ent Predicate 写法天然免疫 SQL 注入
Ent 的类型安全查询构建器（ent.Query + ent.Predicate）全程使用参数化逻辑，底层生成带 ? 占位符的预编译语句，用户输入只进绑定槽位，不参与字符串拼接：
-
client.User.Query().Where(user.UsernameEQ("admin")).All(ctx)：参数值走stmt.SetString()，安全 -
client.User.Query().Where(user.AgeGT(18)).And(user.StatusIn("active", "pending"))：集合自动展开为IN (?, ?, ?)，安全 -
client.User.Query().Where(user.EmailContains("@example.com"))：通配符%...%是硬编码在代码里，不是来自用户输入，安全 -
client.User.Query().Where(user.IDIn(ids...))：ids是[]int，Ent 自动转成等长占位符，安全
为什么 Where(sql.P("...")) 和 Where(sql.Expr(...)) 是高危操作
sql.P 和 sql.Expr 绕过 Ent 的类型检查，直接把字符串塞进 WHERE 子句。它们本身不执行拼接，但开发者极易误用：
- 错误写法：
client.User.Query().Where(sql.P("username = '" + input + "'"))—— 直接触发注入 - 更隐蔽的错误：
client.User.Query().Where(sql.P(fmt.Sprintf("status = '%s'", status)))——fmt.Sprintf就是拼接 - SpEL 式陷阱：
sql.P("username = '" + strings.ReplaceAll(input, "'", "''") + "'")—— 手动转义不可靠，且 Ent 不校验该字符串是否含子查询或注释
这类写法等于放弃 Ent 的安全层，退回到 JDBC Statement 级别。
动态字段/排序/条件该怎么写才安全
Ent 不支持运行时决定列名、表名或 ORDER BY 字段名——这些无法参数化，必须白名单校验：
- 字段名（如
ORDER BY username）必须从预定义枚举中取：sortField := map[string]string{"name": "username", "age": "age"}[input]，否则拒绝 - 排序方向（
ASC/DESC）不能由用户直接传入：if inputDir != "ASC" && inputDir != "DESC" { return errors.New("invalid sort direction") } - 动态条件不要用
StringBuilder拼 SQL，改用ent.And()/ent.Or()组合多个Predicate：preds := []predicate.User{}，根据参数追加user.StatusEQ(status)或user.CreatedAtGT(since)
IN 子句若长度不确定（如前端传任意数量 ID），别硬写 WHERE id IN (?, ?, ?)；用 user.IDIn(ids...)，Ent 会自动适配参数个数。
什么时候该换方案，而不是硬刚 Ent
遇到以下场景，说明 Ent 的抽象已不够用，强行用 sql.P 或原生查询只会引入风险：
- 需要动态表名（如分表查询
logs_202609） - 要执行复杂聚合 + 窗口函数，且 Ent 的
GroupBy不够用 - 需调用数据库特有函数（如 PostgreSQL 的
to_tsvector全文检索）
此时应切换到 sql.Scanner + sql.Named 占位符的 sql.Query，或封装 database/sql 的 Prepare 流程——至少保证所有用户输入都走 sql.Named("name", value) 或位置参数，绝不拼字符串。
最易被忽略的一点：Ent 的 sql.P 和 sql.Expr 看似“只是个表达式”，但它出现在 Where() 里时，Ent 不做任何 SQL 解析或过滤。你传进去的是什么，最终就执行什么——哪怕里面藏着 UNION SELECT password FROM users。
