状态机应通过返回函数值的方式解耦协议解析逻辑，每个状态函数接收字节和上下文，返回下一状态函数及错误，并在迁移路径上精准触发绑定回调，所有状态数据存于*ParseContext中，支持粘包、截断与重入安全。
状态机如何用回调函数解耦协议解析逻辑
协议解析器的核心难点不是读字节，而是把“收到某字节后该做什么”这件事从主循环里摘出来。Go 里直接用 switch 套嵌套 if 写状态跳转，很快就会变成难以维护的面条代码。真正有效的做法是：每个状态封装成一个函数，接收当前字节和上下文，返回下一个状态函数（或 nil 表示结束），同时允许在状态内触发用户注册的回调。
关键不是“用不用闭包”，而是回调必须绑定到具体状态迁移路径上——比如只有从 HeaderState 成功跳到 PayloadState 时才调用 onHeaderParsed，而不是在所有状态里都无差别触发。
- 回调函数签名建议统一为
func(ctx *ParseContext) error，便于组合和错误传递 - 状态函数本身不持有状态数据，所有中间结果存放在传入的
*ParseContext结构体中 - 避免在回调里做阻塞操作（如网络 I/O、文件写入），否则会卡住整个状态机推进
为什么不能把回调直接塞进 struct 字段里
常见错误是定义一个 ProtocolParser struct，把 onMessage、onError 等字段全设成函数类型，然后在每个状态里手动调用。问题在于：这种设计无法表达“仅当满足特定解析条件时才触发”的语义。比如 TCP 应用层协议中，“完整帧校验通过”和“帧头识别成功”是两个不同粒度的事件，它们对应的回调时机和参数完全不同。
正确做法是让状态函数自己决定是否、何时、以什么参数调用回调——本质上，回调是状态迁移的副产品，不是解析器的配置项。
立即学习“go语言免费学习笔记（深入）”；
- 把回调当配置字段，会导致状态逻辑和业务逻辑混杂，测试困难
- 不同协议版本可能需要不同回调组合，硬编码字段无法动态启用/禁用
- 一旦要支持并发解析多个流（如 WebSocket 多连接），共享字段会引发竞态
用 func 类型变量实现可替换的状态流转链
Go 没有类继承，但可以用函数值构建状态链。典型结构是定义 type StateFunc func(b byte, ctx *ParseContext) (StateFunc, error)，初始状态赋给一个变量，每次解析一个字节就调用它，用返回的新函数更新变量：
state := headerStartState
for _, b := range data {
var err error
state, err = state(b, ctx)
if err != nil {
return err
}
if state == nil {
break // 解析完成
}
}
每个状态函数内部可自由调用预注册的回调，比如 ctx.onHeaderReady(ctx)，前提是该回调非 nil 且当前状态已确认头部合法。
- 状态函数之间不要互相调用，全部通过返回值切换，保证单向控制流
- 如果某个状态需等待多个字节（如变长长度字段），应在
*ParseContext中记录已收字节数，而非在函数内局部累积 - 注意
StateFunc返回nil的语义必须明确：是解析结束，还是临时挂起（如等待更多数据）？建议额外加一个isPaused字段区分
容易被忽略的边界：粘包、截断、重入安全
真实网络场景下，data 不一定是一整帧。状态机必须能处理半帧数据，并在下次调用时从中断处继续。这意味着：状态函数不能假设输入完整，*ParseContext 必须包含缓冲区（如 buf []byte）和解析位置（pos int）；回调也不能假定“这次调用一定对应一个完整业务消息”。
- 不要在回调里直接序列化
ctx.payload，它可能只是片段——应由回调自行判断ctx.isComplete标志 - 如果解析器要支持重入（如被多个 goroutine 调用），
*ParseContext必须每次新建，不能复用 - 调试时遇到 “unexpected byte at state X” 错误，大概率是前一次解析未清空
ctx中的临时字段（如长度字段缓存），导致后续解析误判
