Revel框架不内置ORM或自动防注入机制，SQL注入防护完全依赖开发者正确使用database/sql参数化查询，动态表名/字段须白名单校验，禁用字符串拼接。
Revel 框架本身不内置 ORM 或数据库驱动，SQL 注入防护完全取决于你选用的数据库库（如 database/sql + mysql、postgres、sqlite3）以及你如何使用它。Revel 不会自动帮你参数化查询，也不会拦截拼接行为——写错就是漏洞。
为什么 Revel 没有“自动防注入”机制
Revel 是一个轻量级、无侵入的 Go Web 框架，它的设计哲学是“不封装底层细节”，所有数据库操作交由标准库 database/sql 处理。这意味着：
- 它不提供类似 Laravel Eloquent 或 Django ORM 那样的查询构建器抽象，也就没有默认的安全包装
-
revel.DB只是*sql.DB的简单封装，调用Query/Exec时仍需手动传参 - 如果你用
fmt.Sprintf或字符串拼接构造 SQL，Revel 完全不会阻止或警告
必须用 db.Query / db.Exec 配合占位符
Go 标准库只支持位置占位符（? for SQLite, $1, $2 for PostgreSQL, %s or ? depending on driver for MySQL），不支持命名参数（如 :name）。实际写法取决于你用的驱动：
- SQLite：用
?，参数按顺序传入切片：db.Query("SELECT * FROM users WHERE id = ? AND status = ?", id, status) - PostgreSQL（
lib/pq）：用$1,$2：db.Query("SELECT * FROM users WHERE name = $1 AND age > $2", name, age) - MySQL（
go-sql-driver/mysql）：支持?（推荐）或:name（需启用parseTime=true等配置，但不通用）
⚠️ 错误示例（绝对禁止）：db.Query(fmt.Sprintf("SELECT * FROM users WHERE name = '%s'", input)) —— 单引号、反斜杠、Unicode 编码都可能绕过简单过滤。
动态表名/列名无法参数化，必须白名单校验
当你需要根据请求参数决定查哪张表（如多租户分表）或按哪个字段排序（ORDER BY ?）时，database/sql 明确拒绝参数化这些部分。此时只能靠严格校验：
- 定义允许的表名列表：
validTables := map[string]bool{"users": true, "orders": true}，检查inputTable是否在其中 - 排序字段限制为固定几个：
validSortFields := []string{"created_at", "name", "id"}，用slice.Contains判断 - 绝不接受用户输入直接进 SQL 字符串拼接，哪怕加了
strings.ReplaceAll(input, "'", "''")—— 这类“转义”在 Go 中既无效也不必要
这类逻辑建议统一收口到一个 safeTableName(input string) (string, error) 函数里，避免散落在各处。
ORM 或查询构建器不是必须，但能减少出错概率
如果你项目中大量手写 SQL，且团队对 database/sql 熟悉度不一，引入一个轻量 ORM（如 sqlc、squirrel）或代码生成工具更稳妥：
-
sqlc：从 SQL 文件生成类型安全的 Go 代码，所有查询在编译期就确定参数结构，不可能漏掉绑定 -
squirrel：链式构建 SQL，PlaceholderFormat强制使用占位符，比如squirrel.Select("*").From("users").Where(squirrel.Eq{"id": id}) - 避免用
gorm这类全自动 ORM——它虽默认参数化，但Where("status = ?", input)和Where("status = " + input)表面相似，后者却直接拼接，极易踩坑
真正容易被忽略的是：Revel 的 App.Init() 里初始化 revel.DB 时，如果用了连接池或自定义 sql.Open 参数，别忘了设置 SetMaxOpenConns 和 SetConnMaxLifetime——这不是防注入，但连接泄漏会导致错误日志暴露 SQL 结构，间接增加风险。
