不能用字符串字面量直接赋值，因为硬赋值会绕过状态校验：跳过合法性检查、漏记日志、并发覆盖变更、无法触发onExit钩子，导致重复启动或资源泄漏；TransitionTo必须仅校验转移、原子更新、触发钩子，不执行耗时操作；并发下应使用细粒度RWMutex保护状态字段，避免锁整个结构体；多状态宜用接口抽象替代switch膨胀。
为什么不能用字符串字面量直接赋值 service.State = "running"
硬赋值会绕过所有状态校验：跳过转移合法性检查、漏记结构化日志、并发下覆盖他人变更、无法触发 onExit 钩子（比如 “starting” 状态退出时要清理临时资源）。真实场景中，健康检查探针和人工重启命令同时到达，State 可能从 "starting" → "failed" → "running"，导致服务重复启动两次或资源泄漏。
TransitionTo 方法里该做哪些事，不该做哪些事
这个方法是状态流转唯一合法出口，职责必须严格收口：
- 只查预设转移表：
validTransitions[service.State][newState]，不存在就返回ErrInvalidTransition - 成功后原子更新
service.State字段（需用stateMu.Lock()保护） - 立即调用
onEnter()和onExit()，但钩子里不放业务逻辑（避免阻塞） - 不调 DB、不发 HTTP、不
time.Sleep——耗时动作移出，改为状态变更后异步启动 goroutine - 不拼接错误信息：
return fmt.Errorf("can't go from %s to %s", from, to)是反模式，应返回明确错误变量
并发下怎么锁才不卡死整个服务结构体
健康检查、配置热加载、人工运维命令可能同时触发 TransitionTo。如果用 sync.Mutex 锁整个 *Service，读取 ID、Version 这类只读字段也会排队，压测时 QPS 直接腰斩。
- 单独声明锁字段：
stateMu sync.RWMutex，粒度只包状态本身 - 读状态用
stateMu.RLock()，写状态用stateMu.Lock() -
TransitionTo内部只持写锁，且全程纯内存操作（无 I/O、无 channel 等阻塞点） - 若状态需维护临时数据（如重试次数），确保该字段也受同一把锁保护
状态多了以后，switch service.State 膨胀怎么办
当状态超过 5–6 个（如 "idle"、"starting"、"running"、"stopping"、"stopped"、"failed"），硬写 switch 会越来越难维护。
立即学习“go语言免费学习笔记（深入）”；
- 定义
type State interface{ CanTransitionTo(to State) bool; OnEnter(s *Service); OnExit(s *Service) } - 每个具体状态（
StartingState、RunningState）实现该接口 -
Service持有state State接口值，流转时调用s.state.CanTransitionTo(newRunningState) - 注意：接口方法必须用指针接收器，否则状态内字段（如计时器、计数器）无法累积
真正容易被忽略的是状态与事件的对齐：数据库存的是字符串字段（如 "running"），但内存中是接口实例，两者必须严格映射，反序列化时得走工厂函数重建对应状态对象，漏掉一个就会 panic。
