不用new创建单位对象是为了避免内存和gc压力：unittype（内在状态）全局共享，unitinstance（外在状态）单独存储，通过预加载map[string]*unittype管理享元池，unitinstance设计为纯数据结构以优化cpu缓存。
为什么不用 new 每次创建单位对象？
百万级单位（比如 RTS 游戏里的士兵、塔、资源点）如果每个都 new Unit{}，内存和 GC 压力会直接崩掉——Go 的堆分配 + 逃逸分析会让对象进堆，GC 频繁扫描百万指针，STW 时间飙升。
享元模式在这里的核心不是“复用逻辑”，而是“分离内在状态（共享）和外在状态（独有）”：
-
UnitType（攻击动画、血量上限、移动速度）是内在状态，全局只存一份 -
Position、HP、OwnerID是外在状态，存在单独的UnitInstance结构里 - 实际运行时，你持有的是
*UnitType+UnitInstance的组合，不是完整对象
怎么组织享元池？用 sync.Pool 还是 map[string]*UnitType？
sync.Pool 适合临时、短生命周期对象（比如 buffer），但 UnitType 是长期存活、全局只读的配置，用 sync.Pool 反而增加误回收风险，也浪费初始化开销。
更稳妥的做法是启动时预加载，用常量 key 索引：
立即学习“go语言免费学习笔记（深入）”；
var unitTypePool = map[string]*UnitType{
"archer": {Attack: 12, Range: 80, Sprite: "archer.png"},
"knight": {Attack: 28, Range: 1, Sprite: "knight.png"},
}
- key 必须是稳定字符串（比如数据库里的 type_id），不能是运行时拼接或用户输入
- 避免用
map[interface{}]*UnitType—— 接口比较慢，且容易因底层类型不一致导致查不到 - 如果类型数量超千级，考虑用
map[uint32]*UnitType+ ID 映射，减少哈希冲突和内存占用
UnitInstance 怎么设计才不拖慢 tick 循环？
游戏后端每帧要遍历所有活动单位做位置更新、碰撞检测、AI 决策。这时候 UnitInstance 必须是纯数据结构，零方法、零接口、无指针间接跳转。
- 字段顺序按访问频率排：比如
Position和HP每 tick 都读写，放前面；LastAttackTime只在攻击逻辑用，放后面 - 避免嵌套结构体（如
type Position struct{ X, Y int32 }），直接展开为X, Y int32—— 减少内存跳转，利于 CPU 缓存局部性 - 不要给
UnitInstance加方法，所有逻辑走独立函数：MoveUnit(inst *UnitInstance, dx, dy int32)，而非inst.Move() - 如果单位有大量稀疏状态（比如只有 5% 有 buff），别全塞进结构体，用
map[uint64]BuffEffect外挂，但 key 必须是 uint64（int64 不安全，负数可能误触发）
如何避免“共享状态被意外修改”这个坑？
UnitType 被多个 UnitInstance 共享，一旦某处代码写了 unit.Type.Attack++，所有同类型单位立刻变强——这通常不是 bug，是灾难。
- 定义
UnitType时所有字段用大写首字母，但**不暴露 setter**；构造后立即冻结（可加freeze()方法设标志位，后续写操作 panic） - 禁止导出字段，全部通过只读 getter 访问：
func (u *UnitType) MaxHP() int32 { return u.maxHP } - 测试阶段加反射检查：遍历所有
UnitType实例，用reflect.ValueOf(u).CanAddr()确保没被取地址修改 - CI 中跑一次内存快照比对：启动后 dump 一次
UnitType字段值，tick 1000 次后再 dump，diff 应为空
真正难的不是实现享元，而是让团队所有人理解“这个指针你只能读，连取地址都要想三秒”。线上改错一个字段，可能让整场对战的平衡性失效。
