beego默认不自动防sql注入，但orm和raw方法通过参数化查询（?占位符）实现防护；风险源于手动字符串拼接，如o.raw("select * from user where id = " + userid)或filterraw("name = '" + name + "'")，必须全程使用预编译语句并校验输入。
Beego 默认不自动防 SQL 注入，但只要你不手动拼接 SQL 字符串，它底层的 orm 和 Raw 方法基本能拦住绝大多数注入场景。 真正的风险来自开发者绕过框架约束、直接字符串拼接——这种写法哪怕在 beego 里也照崩不误。
beego 的 Raw 方法为什么能防注入？
因为 Raw 底层调用的是数据库驱动的 Prepare + Exec 流程，参数通过绑定（? 占位符）传入，不是字符串插值。数据库驱动会把参数当纯数据处理，不会解析成 SQL 指令。
- 正确用法：
o.Raw("SELECT * FROM user WHERE id = ?", userID).QueryRows(&users) - 错误用法：
o.Raw("SELECT * FROM user WHERE id = " + strconv.Itoa(userID)).QueryRows(&users)—— 这就等于裸奔 - 注意：
Raw的占位符只支持?，不支持命名参数（如:id），用错格式会导致参数不绑定 - MySQL 驱动对
?绑定做了类型推断，但若传入nil或空字符串，可能触发意外的隐式转换，建议提前校验非空
beego ORM 查询是否安全？
是安全的，前提是全程使用 QueryTable 链式方法，比如 Filter、Exclude、OrderBy，这些最终都会转为预编译语句。
- 安全示例：
o.QueryTable(&User{}).Filter("name", name).One(&u)→ 底层生成WHERE name = ? - 危险操作：
o.QueryTable(&User{}).Filter("name__icontains", "' OR '1'='1")—— 虽然 ORM 会转义，但模糊匹配本身可能被用于布尔盲注，需配合输入长度/内容限制 - 慎用
FilterRaw：这个方法允许传入原始条件字符串，例如FilterRaw("status = ? AND created > ?", 1, time.Now())是安全的；但如果写成FilterRaw("name = '" + name + "'")就彻底失效 - 所有
Insert/Update/Delete操作也都走 Prepare，无需额外防护
哪些地方最容易踩坑？
问题几乎全出在「人绕过框架」：手写 SQL、拼接字符串、用 fmt.Sprintf 构造查询、从 URL 或表单取值后不校验就塞进 SQL。
- 常见错误模式：
sql := fmt.Sprintf("SELECT * FROM log WHERE level = '%s'", level)—— 单引号+变量拼接，level填error' --就直接注释掉后续条件 - 日志或调试时临时加的
fmt.Println("SQL:", sql)容易让人误以为“只是打印”，结果上线忘了删，还可能把敏感 SQL 打到日志里 - 用
context或中间件传递未清洗的参数，然后在 DAO 层直接拼接，这类逻辑分散，review 时极难发现 - MySQL 服务端配置影响：如果 MySQL 开启了
sql_mode=STRICT_TRANS_TABLES，某些非法参数绑定会报错而非静默失败，反而暴露问题；但默认关闭时可能掩盖隐患
真正要盯紧的不是 beego 有没有漏洞，而是你写的每一行 SQL 构造逻辑——只要出现 +、fmt.Sprintf、strings.Replace 处理用户输入再进 SQL，就该立刻停下来重写。框架只负责提供安全的路，但路旁有没有人挖坑，得靠自己看。
