真正可维护的方案是写轻量词法分析器，将格式契约显式编码进类型和状态；正则硬切在嵌套、转义、注释等场景易失控，而participle等工具支持结构化声明语法，生成强类型解析结果。
直接用 strings.Split 或正则硬切，短期能跑，但遇到嵌套、转义、空格敏感、注释或跨行值时会迅速失控。真正可维护的方案是写一个轻量词法分析器——不是为了造轮子，而是把「格式契约」显式编码进类型和状态里。
为什么不用 regexp.MustCompile(`(\w+)\s*=\s*(.+)`)？
这种正则看似简洁，但实际踩坑极多：
- 无法区分
key = "value with space"和key = value with space（后者应整体为值还是截断？） - 遇到
path = /usr/local/bin:$PATH里的冒号、美元符、斜杠，不加转义规则就会错切 - 注释
# this is comment出现在行尾或中间时，正则要么漏匹配，要么吞掉整行 - 值含换行（如多行文本块）时，
.默认不匹配\n，开启s模式又容易过度贪婪
词法分析器的价值，就在于把「哪里算 key」「哪里算分隔符」「哪里算值起始」「何时结束」这些隐含规则，变成可读、可测、可调试的状态流转。
用 participle 定义 token 规则比手写 lexer 更快
如果你的格式有稳定结构（比如带 section 的类 INI、带前缀的环境变量风格、或自定义 DSL），participle 是更优起点。它让你用结构体标签声明语法，而不是手动管理 pos、width、状态函数链。
例如解析 host = example.com\nport = 8080\nssl = true：
type KVPair struct {
Key string `participle:"@Ident"`
Equal string `participle:"@'='"`
Value string `participle:"@String | @Ident | @Number | @Bool"`
}
<p>type Config struct {
Pairs []KVPair <code>participle:"@@+"</code> // @@ 表示重复匹配 KVPair
}
</p>
关键点：
-
@Ident匹配字母/数字/下划线组合（自动跳过空白） -
@String内置双引号/单引号包裹、支持转义（"a\"b"）、不贪婪 -
@Bool直接转成bool类型，无需后续strconv.ParseBool - 整个解析结果是强类型
Config，字段名即语义，不是 map[string]string
手写 lexer 的三个必守边界
若格式过于自由（如 shell 风格变量展开、混合注释与内联表达式），或想完全控制性能/错误位置，就得手写 lexer。此时必须明确三件事：
-
Token 边界由什么决定？ 比如等号
=是 operator 还是 literal？空格是否分隔 key 和 value？制表符是否合法？这些得在lexLine或nextToken里硬编码判断，不能靠 guess -
状态如何推进？ 推荐用「当前期望」模式：进入一行后，先 expect key → 遇到
=后 expect value → 遇到#或行尾则结束。避免用布尔 flag 堆叠状态（如inKey,afterEqual,inQuote） -
错误位置要精确到 byte offset。别只返回
"parse error"，而应像line 3, col 12: unexpected '=' in value。这依赖 lexer 维护start和pos，并在每个分支做l.pos - l.start计算
复杂点不在「能不能写出来」，而在「当需求加一条『支持 ${VAR} 展开』时，你改的是 parser 还是 lexer？改完会不会影响已有注释逻辑？」——真正考验设计的地方，永远是第二版需求到来的那一刻。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
