Pop不支持复合主键，强制要求单字段id主键；需用原生SQL处理迁移与CRUD，外键关联须手动维护；替代方案为换GORM或添加代理主键并加UNIQUE约束。
Pop 不支持复合主键，这是设计限制不是配置问题
Buffalo 默认集成的 pop ORM（v2/v3）**完全不支持复合主键**。它强制要求每个模型必须有且仅有一个名为 id 的单字段主键（类型为 int、uuid 或 string），底层依赖 github.com/gobuffalo/pop/v6（或更早 v5）的 schema 推导逻辑，所有迁移、CRUD、关联加载都基于此假设。试图在 struct tag 里加多个 primary 或手动改 database.yml 都不会生效，运行时会报错或静默忽略。
遇到复合主键需求时的实际应对路径
如果你的业务表天然需要复合主键（比如 (user_id, post_id) 作为唯一约束），别硬套 Pop，直接绕过它的模型层：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 用原生 SQL 写迁移：在
models/migrations/xxx_create_table.up.fizz里用create_table显式声明primary_key: ["user_id", "post_id"] - 查数据时跳过
Find/First：改用q.Where("user_id = ? AND post_id = ?", uid, pid).First(&m)或q.Raw("SELECT * FROM user_posts WHERE ...").All(&results) - 写数据避免
Create：用q.Raw("INSERT INTO ... VALUES (...) ON CONFLICT DO NOTHING").Exec()处理重复键冲突（PostgreSQL）或REPLACE INTO（MySQL） - 外键和关联必须手动维护：Pop 的
HasMany/BelongsTo会失效，关联查询得自己拼JOIN或分步查
替代方案：换 ORM 或接受代理主键
真要强依赖复合主键语义，两个务实选择：
-
换 GORM：它支持
@primaryKeytag 标记多个字段，且 Buffalo 允许你卸载 Pop、接入 GORM（需重写数据库初始化逻辑，但可行） -
加代理
id字段：在原表上新增自增id，保留原有字段加UNIQUE约束。Pop 能正常工作，业务逻辑仍可校验复合唯一性——这是绝大多数 Buffalo 项目实际采用的方式
容易被忽略的陷阱：迁移回滚和测试数据
即使你用原生 SQL 建了复合主键表，buffalo pop migrate -d 回滚时可能失败，因为 Pop 不理解多字段主键的 DROP CONSTRAINT 语法；同样，buffalo pop seed 也无法自动填充这类表。所有数据初始化脚本必须手写 Raw 查询，且不能依赖 pop.NewConnection 的默认行为——这点在 CI 环境里特别容易暴露。
