Cursor生成的Go网络状态机代码和测试不可直接信任，需手动补全状态守卫、钩子回调、并发安全、上下文传递及多源状态字段，并添加覆盖非法事件、错误分支与并发场景的表驱动测试。
Cursor 自动生成 Go 网络状态机代码和单元测试，不能直接信任其输出的完整性与正确性——它常忽略状态守卫（guard）、回调执行顺序、并发安全边界，且生成的测试几乎不覆盖错误路径和异步转换场景。
Cursor 生成的 FSM 结构通常缺少关键字段
Cursor 倾向于用最简结构生成状态机，比如只写 Events 列表，但漏掉：
-
Callbacks中的before<em>*</em>/after*钩子注册 -
Initial字段未显式设为当前状态（导致fsm.Current()返回空字符串） - 未设置
Context参数传递机制，使异步事件无法 cancel 或 timeout -
Src字段写成单个字符串（如"connected"），而非切片（[]string{"connected", "connecting"}），导致多源状态转换失败
你必须手动补全这些字段，否则运行时会静默失败或 panic。
生成的单元测试基本只测“happy path”，漏掉三类关键 case
Cursor 输出的测试往往只有类似这样的片段：
立即学习“go语言免费学习笔记（深入）”；
fsm := NewFSM("idle", Events{{Name: "connect", Src: []string{"idle"}, Dst: "connected"}}, Callbacks{})
_ = fsm.Event(context.Background(), "connect")
if fsm.Current() != "connected" {
t.Fatal("expected connected")
}这远远不够。真实网络状态机必须验证：
-
InvalidEventError是否在非法状态触发（例如从"connected"再发"connect"） -
TransitionError是否在回调返回 error 时被透出（比如before_connect返回非 nil error） - 并发调用
fsm.Event是否 panic（默认github.com/looplab/fsm不是 goroutine-safe，需额外加锁或用sync.Once初始化） - 空上下文或已 cancel 的 context 是否被正确响应（应快速返回，不阻塞）
建议在生成后立即补上表驱动测试，覆盖所有 Src → Name → Dst 组合 + 对应 error 分支。
go test -cover 显示高覆盖率，但实际有严重盲区
Cursor 生成的测试常让 go test -cover 报出 85%+ 行覆盖率，但以下代码几乎从不被执行：
-
callbacks["leave_connected"]（离开状态的钩子，仅在状态真正变更时触发） -
callbacks["error"]（全局错误回调，需主动抛出未捕获 error 才进） -
if len(fsm.Events) == 0这类防御逻辑（生成代码一般不空 events）
更危险的是：插桩统计的是“语句执行”，不是“状态路径覆盖”。一次 fsm.Event("connect") 可能跑过 10 行代码，但只覆盖了 1 条状态迁移路径；而一个真实网络 FSM 往往有 5+ 状态、10+ 事件、3+ 并发分支，需要至少 30+ 测试用例才能逼近合理路径覆盖。
别被数字骗了。打开 go tool cover -html=coverage.out，逐行点开未覆盖的 if 和 else 分支，手动补 case。
复杂点不在语法，而在状态语义。比如 "connecting" 超时后该回退到 "idle" 还是保持并重试？Cursor 不知道业务规则，它只拼凑结构。你得自己把协议文档里的状态图，一行行翻译成 Events 和 Callbacks，再用测试反向锁定行为。
