Buffalo框架默认用int64自增主键，改用UUID需手动覆盖生成逻辑、修改迁移SQL、调整ORM映射及钩子，并统一使用UUIDv7/ULID保证时间有序性，否则易报错或性能退化。
Buffalo 框架默认使用自增整数（int64）作为模型主键，直接用 UUID 需要手动覆盖生成逻辑、调整数据库迁移和 ORM 映射 —— 否则会报 sql: Scan error on column index 0 或插入失败。
定义模型时禁用自动 ID 生成
Buffalo 使用 pop 作为 ORM，默认对 ID 字段做自增处理。若要用 UUID，必须显式声明字段并关闭自增：
- 在模型 struct 中将
ID字段类型改为uuid.UUID（需引入github.com/google/uuid） - 添加
db:"id;type:uuid;primary_key"标签，明确告诉pop这是主键且类型为 UUID - 移除
pop的默认 ID 生成钩子（否则会在BeforeCreate自动塞入int64）
示例：
type User struct {
ID uuid.UUID `json:"id" db:"id;type:uuid;primary_key"`
Name string `json:"name" db:"name"`
CreatedAt time.Time `json:"created_at" db:"created_at"`
UpdatedAt time.Time `json:"updated_at" db:"updated_at"`
}
迁移文件中声明 UUID 主键类型
Buffalo 的 buffalo pop generate 命令默认生成 serial 或 bigserial 主键。你必须手动修改迁移 SQL，否则 PostgreSQL 会拒绝插入（MySQL 则可能静默转成 0）：
- PostgreSQL：用
UUID类型 +gen_random_uuid()默认值（需启用pgcrypto扩展） - MySQL：用
BINARY(16)存储（比VARCHAR(36)更省空间、更快），不能用CHAR(36)默认值 - SQLite：不原生支持 UUID，只能用
TEXT，但需自行保证唯一性
PostgreSQL 迁移示例：
CREATE EXTENSION IF NOT EXISTS "pgcrypto";
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name TEXT,
created_at TIMESTAMP WITH TIME ZONE,
updated_at TIMESTAMP WITH TIME ZONE
);
在创建前注入 UUIDv7（而非 v4）
直接用 uuid.NewRandom()（v4）仍会带来 B+Tree 写入碎片问题。Buffalo 项目中推荐用 UUIDv7 实现时间有序性 —— 但标准库不支持，需引入第三方包：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- Go 生态目前较稳定的 UUIDv7 实现是
github.com/oklog/ulid（严格说 ULID 不是 UUIDv7，但语义等效）或github.com/segmentio/ksuid - 若坚持用标准 UUIDv7，可用
github.com/ThreeDotsLabs/watermill-uuid/v7（轻量、无依赖） - 在模型的
BeforeCreate钩子中赋值，确保每次Create都走同一逻辑
示例（使用 ksuid）：
func (u *User) BeforeCreate(tx *pop.Connection) error {
u.ID = ksuid.New().Bytes() // 注意：ksuid.Bytes() 返回 []byte，需转 uuid.UUID
// 或更稳妥地：u.ID = uuid.MustParse(ksuid.New().String())
return nil
}
查询与关联时注意二进制 vs 字符串比较
Buffalo 的 pop.Find 默认把字符串参数当文本处理。如果数据库用 BINARY(16) 存 UUID，而你传入 "a1b2c3..." 字符串，MySQL 会隐式转换失败，返回空结果：
- 始终用
uuid.Parse()将请求参数转为uuid.UUID再传给Find - 关联查询（如
HasMany）时，确保外键字段也定义为uuid.UUID类型，并加db:"type:uuid" - 调试时可打印
tx.Dialect.Name()确认当前 DB 类型，不同方言对 UUID 处理差异很大
错误写法：
user := &User{}
err := tx.Find(user, "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8") // 字符串直传，MySQL 可能不匹配
正确写法：
id, _ := uuid.Parse("a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8")
user := &User{}
err := tx.Find(user, id)
真正麻烦的不是生成 UUID，而是让 Buffalo 的整个生命周期（迁移 → 创建 → 查询 → 关联）都对齐 UUIDv7 的二进制结构和时间有序语义；漏掉任意一环，就可能退化成 v4 的性能陷阱。
