strings.trimspace不能安全清理带注释的配置字符串，因为它仅去除首尾空白，无法识别注释行（如# port = 8080）与有效配置行，会误将注释行当作有效内容；不处理\r\n换行差异、连续空行或缩进注释，也无法保留键值对中间有意义的空格（如name = "john doe"），故必须按规则逐行解析而非简单清理。
为什么 strings.TrimSpace 不能安全清理带注释的配置字符串
直接用 strings.TrimSpace 去掉首尾空白，会误删行内注释前的空格，也可能把注释行（如 # port = 8080）当成有效配置。更糟的是，它对嵌套换行、连续空行、制表符混用完全无感。
真正要做的不是“清理”，而是“按规则拆解”：跳过以 # 或 ; 开头的整行，忽略行首行尾空白，但保留键值对中间的有意义空格（比如 name = "John Doe" 中的名字不能被截断）。
- 注释必须从行首开始才生效（
key = value # comment是合法值，不应截断） -
\r\n和\n都得统一处理，Windows 和 Unix 换行混用很常见 - 空行和纯空白行应跳过，但不要提前终止解析（配置可能有逻辑分段）
用 bufio.Scanner 逐行解析时如何正确识别注释与空行
bufio.Scanner 默认按 \n 切分，且自动去掉换行符，适合做第一层预处理。关键在每行拿到后，先 trim 左侧再判断是否为注释或空行——因为 # 可能前面有空格（如缩进注释），但标准配置语法通常不承认这种写法，所以保守起见只认行首非空白字符是 # 或 ; 的才算注释。
示例逻辑：
scanner := bufio.NewScanner(strings.NewReader(configStr))
for scanner.Scan() {
line := strings.TrimSpace(scanner.Text())
if line == "" || strings.HasPrefix(line, "#") || strings.HasPrefix(line, ";") {
continue
}
// 此时 line 是干净的有效行
}
- 别用
strings.Split(configStr, "\n")—— 它无法统一处理\r\n，且会保留空字符串元素 -
strings.TrimSpace放在注释判断之后，否则会把"\t# comment"变成"# comment"，导致误判 - 如果配置支持 C 风格注释（
//），需额外检查strings.Index(line, "//") == 0，但多数 INI/TOML/YAML 不认这个
解析键值对时怎么避免 strings.Split 破坏带空格的值
像 name = John Doe 这种，用 strings.Split(line, "=") 会得到 ["name ", " John Doe"]，然后你再 trim 两边，看似没问题。但遇到 path = /usr/local/bin/program --flag value 就崩了：等号右边本就含空格，不该被切开。
正确做法是只切第一个等号，并保留右侧全部内容（包括前导空格）：
eqIdx := strings.Index(line, "=")
if eqIdx == -1 {
continue // 跳过无等号行
}
key := strings.TrimSpace(line[:eqIdx])
value := strings.TrimSpace(line[eqIdx+1:])
- 不要用
strings.FieldsFunc或正则——过度设计，且难以控制边界 - 如果值用引号包裹（如
desc = "multi word string"），需额外做引号解析；没引号时，strings.TrimSpace对 value 是安全的 - 某些格式（如 Dockerfile 的 ENV）允许
=出现在值里，此时必须依赖引号或转义，纯靠位置分割不可靠
遇到 BOM 头或 UTF-8 带签名时解析失败怎么办
Windows 记事本保存的 UTF-8 文件常带 BOM（\uFEFF），它会附着在第一行开头，导致 key 变成 "\uFEFFkey"，后续匹配失败。这不是编码问题，是字节前置污染。
解决方法很简单，在传给 bufio.Scanner 前先剥离 BOM：
configStr = strings.TrimPrefix(configStr, "\uFEFF")
- 不要试图用
encoding/json或其他包去“自动检测 BOM”——配置字符串是 raw text，没理由走编码解码流程 - 如果配置来源是文件，建议用
ioutil.ReadFile（Go 1.16+ 用os.ReadFile）读取原始字节，再手动 strip BOM，比依赖 Scanner 更可控 - BOM 只可能出现在开头，strip 一次即可；重复 strip 不影响结果，但没必要
复杂点在于注释符号和等号的语义边界容易被格式细节绕晕——比如缩进空格算不算注释一部分、制表符是否等价于空格、值里能不能有未转义的换行。实际项目里，优先按目标格式规范（如 INI RFC 之流）实现，别自己发明规则。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
