text/scanner 不适合解析复杂格式字符串，因其专为 go 源码设计，不支持自定义 token、无法回溯、遇非法符号即报错；应优先使用 bytes.indexbyte + 状态机或 bufio.reader。
Scanner 为什么不适合直接解析复杂格式字符串
Go 标准库的 text/scanner 是为 Go 源码词法分析设计的，它默认识别 Go 关键字、标识符、数字、字符串字面量等，并会跳过注释和空白。如果你拿它去解析 JSON-like 结构、自定义 DSL 或带嵌套括号的表达式，会立刻踩坑：它不支持配置 token 类型、无法扩展分隔符规则、遇到未定义符号（比如 @、$）直接报 token.ILLEGAL，且无法回退或重置扫描位置。
常见错误现象：scanner.Scan() returns token.ILLEGAL，但你根本没写错字符——只是 scanner 不认识它。
- 不要用
text/scanner替代手写 lexer，除非你的输入就是合法 Go 片段 - 它不提供
Peek()或Unscan()等基本回溯能力，而复杂格式解析几乎必需要回溯 - 它的
Mode配置项（如ScanComments）只控制预处理行为，不能改变 token 分类逻辑
真正可控的替代方案：用 bytes.IndexByte + 自定义状态机
对非标准格式（比如 "key=value; list=[1,2,3]; flag=true"），直接操作字节切片 + 状态机比套用 scanner 更轻量、更明确。Go 的 bytes.IndexByte 和 bytes.TrimSpace 足够支撑大多数场景，且完全规避了 token 匹配失败的黑盒问题。
典型使用场景：解析配置片段、HTTP 头参数（Content-Type: text/html; charset=utf-8）、简单模板变量（{{ .Name }} {{ if .Active }}）。
- 用
bytes.IndexByte(s, ';')定位语句边界，比依赖 scanner 的Scan()循环更可控 - 遇到左括号
'['时，用计数器匹配右括号']'，而不是指望 scanner 自动识别“复合 token” - 字符串字面量需手动处理引号配对（
"..."或'...'），scanner 默认只认双引号且不支持转义解析
需要回溯时，别硬改 scanner —— 改用 bufio.Reader
当解析逻辑要求“读一个字符，判断后决定是否消费”，bufio.Reader 的 ReadByte() 和 UnreadByte() 是更自然的选择。它不预定义 token 含义，所有语义由你定义，且支持任意长度的单字节回退。
性能影响：相比 scanner，bufio.Reader 内存开销略低（无 token 缓存），但需自行管理行号/列号；兼容性无差异，所有 Go 版本都支持。
-
reader.Peek(1)可安全预览下一个字节，避免破坏流状态 - 遇到
'{'后想进入嵌套解析？直接递归调用解析函数，无需切换 scanner mode - 错误定位难？自己维护
line, col变量，每次ReadByte()后更新，比依赖 scanner 的Pos()更可靠
第三方 lexer 库不是银弹，选前先看这三点
像 goccy/go-json 或 mna/polyglot 这类专用 lexer，只在特定领域省事。盲目引入反而增加构建依赖和调试路径。
容易被忽略的点：
- 检查它是否暴露底层 reader 接口——否则你无法注入自定义错误上下文（比如当前解析的文件名）
- 确认它是否支持零拷贝解析（即 token 返回的是源字节切片子视图，而非新分配字符串）；否则大文本下 GC 压力陡增
- 运行
go test -bench=.对比手写状态机，很多 lexer 库在简单 case 下慢 2–3 倍，因为多了抽象层调度
复杂格式的解析难点从来不在“怎么分 token”，而在“如何定义 token 边界”和“怎样恢复错误状态”。把 scanner 当万能锤，往往最先砸到自己的脚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
