状态模式通过将“当前解析阶段”显式建模为独立类型，使每个状态仅关注自身对输入的响应与转移，避免if-else硬编码导致的嵌套失控、多阶段校验耦合和状态依赖混乱。
为什么直接用 if-else 解析协议字符串会失控
当协议字符串包含嵌套结构（比如 START{header:123;body:{key=val}}END）、多阶段校验（长度检查→校验和→字段解析）或状态依赖行为（“当前在括号内”会影响对分号的处理），硬编码分支很快变成意大利面条。状态模式不是炫技，是把「当前处在什么解析阶段」显式建模为独立类型，让每个状态只关心自己该响应什么输入、转移到哪里。
State 接口设计要窄，别暴露内部字段
常见错误是把 State 设计成带 Parse、Validate、Commit 等一堆方法的大接口，或者让每个状态持有整个解析器上下文指针。这会让状态间耦合变高、测试困难。正确做法是只定义最小契约：
type State interface {
Handle(ctx *ParseContext, ch byte) (State, error)
}
所有状态转移和副作用（如追加字符、记录字段）都通过 ctx 完成，而 ctx 本身应是可测试的值类型（含 buffer []byte、depth int、inQuote bool 等必要字段）。这样每个状态实现类只专注「看到这个字节，我该做什么、去哪」。
如何避免状态爆炸：用组合代替继承
协议有 8 种状态？别写 8 个 struct。多数状态共享基础逻辑（比如跳过空白、识别转义）。推荐用匿名字段组合：
type BaseState struct{}
func (b *BaseState) SkipWhitespace(ctx *ParseContext, ch byte) bool {
return ch == ' ' || ch == '\t' || ch == '\n'
}
type InValueState struct {
BaseState // 复用跳空格逻辑
}
func (s *InValueState) Handle(ctx *ParseContext, ch byte) (State, error) {
if s.SkipWhitespace(ctx, ch) {
return s, nil // 保持当前状态
}
if ch == ';' {
return &InFieldState{}, nil
}
ctx.buffer = append(ctx.buffer, ch)
return s, nil
}
这样新增状态时只需关注差异点，不用重复粘贴通用逻辑。另外，状态构造函数应校验前置条件（比如 NewInBraceState() 可检查 ctx.depth > 0），避免非法状态被创建。
panic 不是状态切换失败的合理返回方式
很多教程在 Handle 方法里遇到非法字符直接 panic，这会让整个解析器崩溃，无法提供精确错误位置。必须返回 error，且错误信息要含上下文：
- 用
fmt.Errorf("unexpected %q at pos %d in state %s", ch, ctx.pos, reflect.TypeOf(s).Name()) -
ctx.pos要在每次Handle前递增，不能只在读取后更新 - 不要在状态内缓存原始字符串切片——不同状态可能需要不同偏移量，统一用
ctx.pos计算更可靠
状态模式真正的难点不在结构搭建，而在边界条件：嵌套深度溢出怎么回退、不匹配的括号如何报告具体层级、流式解析时 EOF 出现在中间状态该如何判定是否可接受。这些细节没覆盖好，状态机就只是把 bug 换了个地方藏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
