Beego ORM 不支持复合主键，仅识别单字段主键（如 Id 或带 pk tag 的字段）；多 pk tag 会被忽略，Raw SQL 是唯一可靠查询方式。
Beego ORM 不支持复合主键
Beego ORM 从设计上就**不支持复合主键（composite primary key）**。它的 orm.RegisterModel 和底层 ID 处理逻辑默认只认单字段、名为 Id（或带 pk tag）的整型/字符串主键。如果你的表有类似 (user_id, role_id) 这样的联合主键，ORM 无法自动生成合法的 Read、Update、Delete 行为，调用会直接 panic 或静默失败。
- 尝试在 struct 中用多个
pktag（如UserId int `orm:"pk"`+RoleId int `orm:"pk"`）——RegisterModel会忽略第二个，仅以第一个为准，后续操作全错 - 用
orm:"pk;auto"标在非整型字段（如 string 组合）上——Insert可能成功，但Read(&obj)一定查不到，因为 ORM 内部仍按单值 ID 构造 WHERE - 即使你手动绕过 ORM 用
Raw()插入数据，后续想用QueryTable("xxx").Filter("user_id", 1).Filter("role_id", 2).One(&obj)查单条，也不会触发主键语义，只是普通条件查询
替代方案：用 Raw SQL 精确查联合主键行
当必须按多字段唯一组合查记录（比如权限表 user_role 的 (user_id, role_id)），最稳的方式是放弃 ORM 的 One/Read，改用 Raw 手写 SQL：
o := orm.NewOrm()
var result struct {
UserID int
RoleID int
Status string
}
err := o.Raw("SELECT user_id, role_id, status FROM user_role WHERE user_id = ? AND role_id = ?", 123, 456).QueryRow(&result)
if err != nil {
// 注意：QueryRow 不会返回 ErrNoRows，要自己判断 result 是否为空
}
-
Raw()是唯一能 100% 控制 WHERE 条件字段和顺序的方式，避免 ORM 解析 expr 时对多字段主键的误判 - 不要用
Values(&[]map[string]interface{})接多行结果再取第一项——性能差且易出错；QueryRow更轻量、语义更准 - 如果字段名含下划线（如
created_at），struct 字段名需匹配（CreatedAt string），或用orm:"column(created_at)"显式绑定
QueryTable.Filter 能否模拟联合主键查询？
可以查，但不是主键语义，也不等价于 Read。它只是普通多条件过滤：
o := orm.NewOrm()
var ur models.UserRole
err := o.QueryTable("user_role").
Filter("user_id", 123).
Filter("role_id", 456).
One(&ur)
- 这行得通，但底层生成的是
WHERE user_id = ? AND role_id = ?，而非主键专用逻辑 - 如果表没有索引覆盖这两个字段，性能可能很差；务必确保
(user_id, role_id)有联合索引 -
One在没匹配到时返回ErrNoRows，这点和Read一致，但不能用于后续Update/Delete操作——因为 ORM 不知道该用哪几个字段做 WHERE
真正需要联合主键时，建议换方案
Beego ORM 对复合主键的支持是硬性缺失，不是配置问题。如果业务强依赖联合主键（比如历史遗留表无法改结构），要么：
- 用
Raw封装所有 CRUD，彻底绕过 ORM 的模型层 - 加一个自增
id字段作为代理主键，把原联合字段降级为unique约束（推荐） - 换用支持复合主键的 ORM，如
gorm（type UserRole struct { UserID uint `gorm:\"primaryKey\"`; RoleID uint `gorm:\"primaryKey\"` }）
别在 Filter 链里拼凑“伪主键”然后幻想 ORM 能自动识别更新逻辑——它不会。
