beego的Raw()方法不默认防注入，是否安全取决于是否使用占位符参数化；动态表名/字段名须白名单校验；标准ORM方法（如Filter）默认参数化，天然防注入。
beego 的 Raw() 方法默认不防注入，必须手动用参数绑定
很多人误以为 beego.Raw() 自带防护，其实它只是封装了 database/sql 的预处理能力，**是否安全完全取决于你怎么传参**。如果你写成 orm.Raw("SELECT * FROM user WHERE id = " + userID)，那就和字符串拼接无异，直接中招。
正确做法是：所有用户输入必须走占位符，且由 beego 内部驱动完成参数绑定：
-
orm.Raw("SELECT * FROM user WHERE id = ?", userID)✅ 安全，参数被隔离为纯数据 -
orm.Raw("SELECT * FROM user WHERE name LIKE ?", "%"+keyword+"%")✅ 可接受，但注意通配符应在 Go 层拼，不在 SQL 字符串里 -
orm.Raw(fmt.Sprintf("SELECT * FROM user WHERE id = %s", userID))❌ 危险，绕过所有防护机制
动态表名/字段名无法用占位符，必须白名单校验
SQL 语句中的表名、列名、ORDER BY 字段等，数据库驱动**不支持参数化**，? 占位符只适用于值（value），不能用于标识符（identifier）。这意味着你没法写 SELECT * FROM ? 或 ORDER BY ?。
此时唯一可靠的方式是硬性白名单校验：
立即学习“go语言免费学习笔记（深入）”；
- 定义允许的字段列表：
validFields := map[string]bool{"id": true, "name": true, "created_at": true} - 校验输入是否在其中：
if !validFields[fieldName] { return errors.New("invalid field") } - 绝对不要用
strconv.Atoi或正则“过滤数字”来放行表名——攻击者可构造user; DROP TABLE user--这类 payload 绕过
beego ORM 查询方法（如 QueryTable().Filter()）默认安全
beego 的高层 ORM 接口（非 Raw()）基本都基于参数化查询构建，比如：
-
o.QueryTable(&User{}).Filter("id", 123).One(&u)✅ 内部生成预处理语句，自动绑定 -
o.QueryTable(&User{}).Filter("name__contains", "admin").All(&users)✅ 同样走参数绑定，__contains是 beego 封装的语法糖 - 但注意：
Filter("name", "admin' OR 1=1 --")仍安全，因为整个值被当作文本参数处理，不会改变 SQL 结构
这类方法的安全性依赖于 beego 对 database/sql 的正确封装，只要你不主动调用 Raw() 或 Exec() 拼接字符串，风险极低。
MySQL 报错 Error 1461: Can't create more than max_prepared_stmt_count statements 是安全机制反噬
这个错误表面看是性能问题，实则暴露了潜在的注入隐患：它说明你的应用在高频创建未复用的预处理语句——常见于每次请求都调用 Raw("SELECT ... WHERE id = " + id) 并让 beego 自动 prepare，导致 MySQL 的 max_prepared_stmt_count 耗尽。
这背后往往藏着两类问题：
- 误把用户输入拼进 SQL 字符串，迫使 beego 为每个不同字符串新建一个 prepare statement（如
id=1、id=2被视为两条不同语句） - 没关闭或复用
Raw()返回的语句对象，连接池不断累积 prepared handle - 真正该盯住的不是调高
max_prepared_stmt_count，而是检查所有Raw()调用点是否用了占位符
复杂点在于：安全和性能在这里绑定了——用对占位符，语句可复用；拼错字符串，既不安全又压垮 MySQL。
