Go 怎么逐段解析带注释的配置文本

配置文本一旦混入空行、缩进和注释，直接对每行调用 strings.Split(line, "=") 很快就会出现边界问题：没有等号的注释被当成配置，值里再出现等号时又被拆碎。一个稳妥的做法是把规则收窄为“每行一个 key = value，# 和 ; 只表示整行注释”，先清理行，再拆分第一个等号。这样既保留有效配置，也不会误删值里的内容。

先把配置文本的规则说清楚

下面的示例只支持简单键值配置：一行一个项目，等号左边是键，右边是值；允许空行；去掉空白后以 # 或 ; 开头的行是注释。这里故意不把值中的井号当作行内注释，因为密码、URL 片段或标识符都可能合法包含它。若业务确实需要行内注释，应先定义引号和转义规则，再单独写词法解析器。

# 服务基础配置
host = 127.0.0.1
port=8080

; 值中的井号暂时保留
welcome = hello # world
token = a=b=c

目标结果是一个 map[string]string：host、port、welcome 和 token 被保留，空行与两种整行注释被忽略。

逐行清理时不要先误删值

换行来源可能不同，先把 CRLF 统一成 LF，再用 strings.Split 保留行号。行号是后面返回错误的关键；如果先把所有内容压成一个字符串，调用方很难定位是哪一行写错。

package main

import (
	"fmt"
	"strings"
)

func parseConfig(text string) (map[string]string, error) {
	// 统一换行符，保留切分后的行号，便于返回可定位的错误。
	text = strings.ReplaceAll(text, "\r\n", "\n")
	text = strings.ReplaceAll(text, "\r", "\n")

	values := make(map[string]string)
	for lineNo, raw := range strings.Split(text, "\n") {
		line := strings.TrimSpace(raw)
		// 空行和整行注释不参与键值解析。
		if line == "" || strings.HasPrefix(line, "#") || strings.HasPrefix(line, ";") {
			continue
		}
		key, value, found := strings.Cut(line, "=")
		if !found {
			return nil, fmt.Errorf("第 %d 行缺少等号", lineNo+1)
		}
		key = strings.TrimSpace(key)
		value = strings.TrimSpace(value)
		if key == "" {
			return nil, fmt.Errorf("第 %d 行键为空", lineNo+1)
		}
		if _, exists := values[key]; exists {
			return nil, fmt.Errorf("第 %d 行重复定义键 %q", lineNo+1, key)
		}
		values[key] = value
	}
	return values, nil
}

func main() {
	// 演示值里的井号和后续等号都被保留下来。
	text := "# demo\r\nhost = 127.0.0.1\r\nwelcome = hello # world\r\ntoken = a=b=c"
	values, err := parseConfig(text)
	if err != nil {
		fmt.Println("配置错误:", err)
		return
	}
	fmt.Println(values["welcome"])
	fmt.Println(values["token"])
}

这里的顺序很重要：先 TrimSpace，再判断注释；先用 Cut 找第一个等号，再分别清理键和值。strings.Cut 找不到分隔符时会通过 found 告诉调用方，而值里的后续等号会原样留在 value 中。

第一个等号决定拆分边界

如果使用 strings.Split(line, "=")，token = a=b=c 会得到多个片段，后续代码还要猜哪个片段属于值。strings.Cut 明确只围绕第一次出现的分隔符切开，正好适合这种简单格式。

重复键建议直接返回错误，而不是依赖 map 的“后写覆盖前写”。配置文件通常由多人维护，显式失败能避免最后一行悄悄改变连接地址、超时时间等关键行为。如果你的产品明确规定“后者覆盖前者”，也应把这个策略写进文档并单独测试。

何时该停止扩展这套解析器

这套方法适合启动参数、测试夹具和内部小型配置。它不处理引号、转义、多行值、数组、嵌套对象、变量替换或行内注释；一旦加入这些语义，单纯增加 strings.Index 和条件分支会让错误边界越来越模糊。此时应选择已有格式和对应解析库，并保留当前函数作为最小格式的兼容入口。

正式接入时至少准备三组测试：空行与两种注释、值中含等号或井号、缺少等号和重复键。检查结果时同时断言映射内容与错误行号，这比只测试“能否返回 map”更能防止配置变更后悄悄读错。

常见问题

Go 解析配置时能不能直接删除所有井号后的内容？

不建议。除非格式明确规定井号永远开启行内注释，否则它可能是值的一部分。当前规则只跳过整行注释，行为更可预测。

为什么不让重复键覆盖旧值？

覆盖可以实现，但会隐藏配置冲突。示例选择报错；如果业务需要覆盖，应在函数名或文档中明确“后者优先”，并为顺序写测试。

配置文本包含引号和多行内容怎么办？

这已经超出简单键值格式。应采用有明确语法的配置格式和成熟解析器，不要继续用字符串切分堆叠特殊情况。

参考：Go strings 标准库文档。本文只使用其中的字符串清理、替换和首次分隔符切分能力，解析规则本身由示例场景定义。