strings.TrimSpace 是预清洗必选操作，因其依据 unicode.IsSpace 统一清除首尾所有 Unicode 空白符（含 \r、\t、\u3000、\u200b 等），避免空行漏判；必须先 trim 再判断非空和注释，顺序不可颠倒。
为什么 strings.TrimSpace 是预清洗的必选操作
因为配置行里混着 \r、\t、全角空格 \u3000、零宽空格 \u200B 等，只用 len(line) > 0 判断会漏掉看似“非空”实则无意义的行。比如 "\t # comment" 或 "\u3000"，strings.TrimSpace 能统一识别并清空——它依据 unicode.IsSpace，覆盖所有 Unicode 空白符，不是只认 ASCII 空格。
常见错误是写 strings.Trim(line, " \t\n\r")：漏掉 \f、\v 和中文空格；更糟的是硬编码字符集，遇到新编码或用户粘贴内容就失效。
-
strings.TrimSpace性能好，底层单次扫描首尾，不遍历全文 - 对空字符串、全空白字符串安全，返回
"" - 不会动中间空白，比如
"a b"→"a b"，符合配置解析预期
注释行判断必须放在 trim 之后
顺序错了就会误判。例如 " # comment"（开头有空格），如果先 strings.HasPrefix(line, "#")，结果是 false；但 strings.TrimSpace(line) 后变成 "# comment"，再判就准了。
所以逻辑必须是：trimmed := strings.TrimSpace(line) → trimmed != "" && !strings.HasPrefix(trimmed, "#")。不能反过来，也不能省略 TrimSpace 直接对原始 line 做判断。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 短路求值保证安全：先判
trimmed != ""，避免对空串调HasPrefix（虽不 panic，但语义模糊） - 别用
else if拆条件——那等于“非注释 OR 非空”，会把# hello和"\n"都放进来 - Windows 行尾
\r\n导致的残留\r，TrimSpace自动吃掉，不用额外处理
什么时候该用 strings.Trim 而不是 TrimSpace
当你明确要剔除某些非空白但干扰解析的前缀/后缀时，比如 INI 键值行末尾的 ; 或自定义标记 ~，strings.Trim 更精准。
例如配置行 "host = 127.0.0.1 ; prod"，你想保留 ; 后的注释但去掉行尾空格和分号本身，可以：strings.TrimRight(line, " ;\t\n\r")。但注意：Trim 第二个参数是字符集，不是子串，" ;" 表示删掉末尾所有空格或分号，直到遇到其他字符为止。
-
Trim不识别 Unicode 空白，只认你给的字符，适合可控环境 - 若需删 BOM（
\uFEFF）或特定控制符，得用TrimLeftFunc配合unicode.IsSpace或自定义函数 - 别在循环里反复
Trim同一类字符——提前提取成常量，比如const trimChars = " \t\n\r\f\v\u3000"
bufio.Scanner 读取时如何避免换行符污染
bufio.Scanner 默认以 \n 为分隔符，但 Windows 文件带 \r\n，Linux/macOS 是 \n，有些日志或导出数据甚至含 \r 单独结尾。直接拿 scanner.Text() 的结果做判断，可能残留 \r 在末尾，导致 strings.HasPrefix 失效或 TrimSpace 无法完全清理。
稳妥做法是：读完一行后立刻 strings.TrimSpace，而不是依赖 Scanner 自动去 \r。Scanner 不保证帮你抹掉 \r，尤其当输入流编码异常或混杂时。
- 不要写
line := strings.TrimSuffix(scanner.Text(), "\r")——太窄，漏掉\f、\v等 - 大文件别用
strings.Split(data, "\n")全加载进内存，Scanner+TrimSpace是流式安全解法 - 如果原始数据来自 HTTP body 或用户上传，务必先
TrimSpace再进任何条件分支，否则空行、注释行都可能逃逸
真正容易被忽略的点是：预清洗不是“可选项”，而是解析链的第一道闸门。一旦 TrimSpace 没做，后续所有判断——包括注释识别、键值分割、甚至 JSON unmarshal——都会继承脏数据。这不是性能问题，是逻辑正确性的起点。
