Beego不提供分布式ID生成器，因其定位是Web层MVC框架而非基础设施中间件；它仅通过ORM映射主键字段，不负责ID生成逻辑，需自行集成xid、sonic-gid等成熟方案。
Beego 本身不提供分布式唯一 ID 生成器，也**不内置 Snowflake、UUIDv7 或号段发号器等实现**。你不能靠 beego.BConfig 或 bee run 自动生成一个跨节点、高并发、时间有序的 ID——必须自己集成或封装。
为什么 Beego 没有原生分布式 ID 支持
Beego 是 MVC 框架，定位是 Web 层快速路由 + 控制器 + ORM 封装，不是基础设施中间件框架。它的 orm 包只负责把 int64 或 string 映射到数据库字段，不关心这个值怎么来。
- 数据库自增 ID（
AUTO_INCREMENT）在分库分表或主从切换时不可靠，且无法保证全局有序 -
uuid.NewV4()虽然全局唯一，但无序、长度长（36 字符）、索引效率低，不适合做主键 - Beego 的
orm.Insert()接收任意类型主键，只要你提前生成好并赋值给 struct 字段即可
推荐用 go-zero 的 xid 或 sonic-gid 替代自研
别手写 Snowflake：时钟回拨、worker ID 分配、节点发现等问题极易出错。直接用成熟小包更稳。
-
xid（github.com/rs/xid）：12 字节，MongoDB 风格，无中心、无依赖、时间前缀+随机后缀，string类型可直接存 MySQLVARCHAR(20) -
sonic-gid（github.com/sonicguo/sonic-gid）：兼容 Snowflake 协议，支持 etcd 注册 worker ID，适合多机部署 - 若已用 Redis，可用
INCR+ 时间戳拼接，但要注意单点瓶颈和故障转移
示例（xid）：
import "github.com/rs/xid"
type TestData struct {
ID string `orm:"pk;size(20)"`
Device string `orm:"size(32)"`
}
func (t *TestData) TableName() string {
return "test_data"
}
func NewTestData() *TestData {
return &TestData{
ID: xid.New().String(), // 生成如 "9m3r4q1f3a2b4c5d6e7f8g9h"
}
}
在 Beego Controller 中安全注入 ID 生成逻辑
不要在 model struct 初始化里直接调 xid.New()，因为 Beego 的 orm.ReadOrCreate() 等方法会反复实例化 struct；应在业务逻辑层显式生成并赋值。
- 避免在
Prepare()或Init()里生成 ID：这些方法可能被多次调用，导致重复 ID - 推荐放在 POST handler 入口处，生成后立即塞进 model 实例：
data.ID = xid.New().String() - 如果用 Beego ORM 的
Insert()，确保 struct 的 ID 字段已非空，否则 ORM 会尝试用数据库默认值（可能触发自增或报错） - 注意事务场景：ID 必须在
StartTransaction()之后、实际Insert()之前生成，防止事务回滚后 ID 泄漏
MySQL 表结构适配要点
别再用 BIGINT UNSIGNED AUTO_INCREMENT 当分布式主键。改用：
-
id VARCHAR(20) NOT NULL PRIMARY KEY—— 适配 xid、sonic-gid 等字符串 ID - 加
INDEX idx_created_at (created_at)：字符串 ID 失去时间序优势，查询最新数据必须靠显式时间字段 - 如果仍想保留整数 ID 做关联，可额外加一列
shard_id BIGINT用于分片路由，但主键仍用字符串
真正难的不是“怎么生成”，而是“怎么让所有服务节点拿到不冲突的 ID”——xid 这类无状态方案省掉协调成本，比强依赖 etcd/ZooKeeper 的方案更容易落地。别在 Beego 里造轮子，它只管把请求转给你的生成器，剩下的交给专精这件事的库。
