因为strings.Split无法处理嵌套、转义、引号等上下文敏感结构，需用4状态机：stateStart、stateInField、stateInQuote、stateAfterQuote；转义通过i++跳过下一字符实现，不设单独escape状态。
为什么不用 strings.Split 而要手写状态机？
因为 strings.Split 只能按固定分隔符切，无法处理嵌套、转义、引号包围等上下文敏感结构。比如解析 "a,b,"c,d",e" 时，你不能简单按逗号切——双引号内的逗号不该分割。状态机才是这类需求的自然解法：它靠当前状态 + 输入字符决定下一步动作，天然支持上下文感知。
核心状态怎么定义才够用？
一个真正能跑起来的极简状态机，只需要 4 个状态：stateStart（初始）、stateInField（普通字段中）、stateInQuote（双引号内）、stateAfterQuote（刚退出引号，等待结束或逗号）。不需要 stateEscape 单独状态——遇到 直接跳过下一个字符即可，避免状态爆炸。
实操建议：
- 用
int常量定义状态，别用字符串或枚举类型，减少运行时开销 - 状态转移逻辑全部写在
switch state { ... }里，别拆成多个函数，否则调试时跳来跳去 - 每个状态分支里，先处理当前字符，再决定下一个状态，顺序不能反
如何安全地处理引号和转义？
关键不是“识别转义序列”，而是“跳过下一个字符”。当处于 stateInQuote 且遇到 时，直接 i++（跳过后续字符），然后继续循环——不管后面是 " 还是 n 或 \，都照单全收。这样既兼容常见转义，又不引入额外状态。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
容易踩的坑：
- 忘记检查
i+1 就执行 <code>i++，导致 panic - 在
stateAfterQuote状态下，把,当作分隔符，但把"当作非法字符——其实应该允许连续引号（如""表示空字符串） - 字段结尾没触发
append，导致最后一个字段丢失（必须在循环结束后补一次）
完整可跑的极简实现长什么样？
下面这段代码去掉注释只有 42 行，能正确解析带引号、转义、空字段的 CSV 片段：
func parseCSV(s string) []string {
fields := make([]string, 0)
var cur strings.Builder
state := stateStart
for i := 0; i < len(s); i++ {
c := s[i]
switch state {
case stateStart:
if c == '"' { state = stateInQuote } else if c == ',' { cur.Reset() } else { state = stateInField; cur.WriteByte(c) }
case stateInField:
if c == ',' { fields = append(fields, cur.String()); cur.Reset(); state = stateStart }
else if c == '"' { state = stateInQuote }
else { cur.WriteByte(c) }
case stateInQuote:
if c == '"' && i+1 < len(s) && s[i+1] == '"' { i++; cur.WriteByte('"') }
else if c == '"' { state = stateAfterQuote }
else if c == '\' && i+1 < len(s) { i++; cur.WriteByte(s[i]) }
else { cur.WriteByte(c) }
case stateAfterQuote:
if c == ',' { fields = append(fields, cur.String()); cur.Reset(); state = stateStart }
else { state = stateInField; cur.WriteByte(c) }
}
}
if cur.Len() > 0 || state == stateAfterQuote {
fields = append(fields, cur.String())
}
return fields
}
注意 stateAfterQuote 的处理：它只持续一个字符，之后立刻回落到 stateInField。这个细节决定了能否正确处理 "a","b",c 这种混合格式。
真正的难点不在状态设计，而在于边界条件——比如空输入、连续逗号、结尾逗号、未闭合引号。这些情况要么提前 return，要么让状态机自然走到末尾再统一收尾，别在中间硬塞一堆 if 判断。
