Beego ORM 默认通过预编译语句（Prepare+Execute）防止SQL注入，Filter等操作参数绑定安全；但Raw查询若字符串拼接而非用?占位符，则完全失效。
Beego 的 ORM 默认不拼接 SQL 字符串，只要你不手动绕过它，SQL 注入风险极低。但一旦用 Raw 或 QueryRow 等原始查询接口并直接拼接参数，框架的防护就完全失效了。
beego ORM 的查询默认走 Prepare Statement
Beego 的 orm.QuerySeter（如 Filter、OrderBy、Limit）生成的 SQL 全部通过 MySQL 驱动的 Prepare + Execute 流程执行，参数以绑定方式传入，不会参与 SQL 解析。这意味着即使你写：
o.QueryTable(&User{}).Filter("name", "admin' OR '1'='1").All(&users)
实际发送到 MySQL 的是类似：
SELECT * FROM user WHERE name = ?
然后把 "admin' OR '1'='1" 作为独立参数值传给 ? 占位符 —— 数据库根本不会把它当 SQL 解析。
这种机制天然隔绝了注入，不需要你额外做转义或过滤。
Raw 查询必须用问号占位符，不能字符串拼接
Raw 是 Beego 提供的“可控但危险”的接口：它允许手写 SQL，但安全与否全看你是否遵守绑定规则。
- ✅ 正确：参数用
?占位，调用Exec或QueryRows时传参 - ❌ 错误：用
fmt.Sprintf或+拼接变量进 SQL 字符串
例如：
// 危险！拼接导致注入
sql := "SELECT * FROM user WHERE id = " + r.FormValue("id")
o.Raw(sql).Exec()
<p>// 安全！占位符 + 绑定
o.Raw("SELECT * FROM user WHERE id = ?", r.FormValue("id")).Exec()
注意：Raw 不解析 SQL 语法，只负责把问号替换成驱动支持的预编译参数绑定。拼错占位符数量、类型不匹配会报错，但不会引入注入。
为什么 ORM 不防住所有场景？关键在开发者的使用路径
Beego 的防护能力只覆盖它“能控制的路径”。以下情况会绕过防护：
- 直接调用
sql.DB原生连接（跳过 Beego ORM 层） - 用
Raw但写成Raw("SELECT * FROM user WHERE name = '" + name + "'") - 在
Raw中混用占位符和拼接，比如"WHERE status = 'active' AND id = " + id - 从 URL、表单、Header 中取值后，未经校验就用于表名或字段名（占位符对这些无效）
表名/字段名这类动态标识符无法用参数绑定，必须白名单校验或映射转换，例如：
validFields := map[string]bool{"name": true, "email": true, "created_at": true}
if !validFields[fieldName] {
http.Error(w, "invalid field", http.StatusBadRequest)
return
}
o.Raw("SELECT " + fieldName + " FROM user").QueryRows(&result)
MySQL 的 stmt_cache 问题暴露的是用法错误，不是 ORM 缺陷
线上出现 MySQL has gone away 或 Too many statements，往往是因为开发者在循环里反复调用 Raw 且每次都拼接不同 SQL（如把用户输入拼进 WHERE 条件），导致 MySQL 缓存了成百上千个 unique prepare statement。
这不是 Beego ORM 的 bug，而是误用了 Raw 接口。正确做法是：
- 固定 SQL 结构，仅变化参数值 → 用
?占位 - 真需要动态表名/字段 → 提前校验，不要依赖用户输入
- 避免在高频请求中无节制创建新
Raw查询
ORM 的安全边界很清晰：它只保你“按它设计的方式用”，不兜底野路子。最易被忽略的一点是——Raw 看似自由，实则比 ORM 更需要开发者对 SQL 执行原理有基本判断。
