Scanner读配置文件漏最后一行是因为其按行末换行符切分，末尾无换行时不触发Scan()返回true；应检查scanner.Err()是否为io.EOF并手动处理残留，或改用bufio.Reader+ReadString('\n')。
Text/Scanner 读配置文件时为啥总漏掉最后一行？
因为默认的 Scan() 是按“行末换行符”切分，但文件末尾没换行时，最后一行不会触发 Scan() 返回 true，直接跳过。这不是 bug，是设计如此——Scanner 只保证“成功扫描到完整分隔符”，不保证“读完所有字节”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
scanner.Err()检查是否因io.EOF导致提前退出，再手动处理缓冲区残留（scanner.Bytes()或scanner.Text()） - 更稳妥的做法：改用
bufio.Reader+ReadString('\n')，它对末尾无换行的情况返回当前已读内容 +io.EOF - 如果坚持用
Scanner，初始化时显式设置分隔符：scanner.Split(bufio.ScanLines)（虽默认就是它，但显式写出来能提醒自己行为边界）
如何跳过注释和空行而不影响字段解析？
Scanner 本身不识别语法，所谓“跳过”得靠你手动判断每行内容。常见错误是只检查 strings.HasPrefix(line, "#")，却忘了 //、空格缩进、BOM 字节、Windows 换行符等干扰项。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
strings.TrimSpace()去首尾空白，再判断是否为空或以#、;开头（INI 风格常用分号） - 避免用
strings.Split()直接切字段——它无法处理带空格的值（如path = /usr/local/bin），应改用正则或状态机提取key = value - 注意 UTF-8 BOM：读取前用
bytes.TrimPrefix(data, []byte("\xef\xbb\xbf"))清理，否则TrimSpace也去不掉
用 Scanner 解析 key=value 时，等号右边的引号怎么处理？
标准 Scanner 不做词法分析，引号只是普通字符。如果你的配置允许 name = "John Doe" 这种写法，就必须自己实现基础字符串解析逻辑，不能依赖 strings.SplitN(line, "=", 2)。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 简单场景：用正则
^(\w+)\s*=\s*(.*)$提取键值，再对值部分手动处理双引号（去掉首尾、转义内部\"） - 中等复杂度：写个极简状态机，遍历字节，遇到未转义的引号就切换“是否在字符串内”标志，只在非字符串状态下认等号
- 别碰单引号——Go 标准库没提供类似 Python 的
ast.literal_eval，自己解析单引号容易漏掉'it\'s'这类转义，不如统一要求双引号
Scanner 在大配置文件里内存暴涨？
Scanner 默认缓冲区是 64KB，遇到超长行（比如一行 base64 编码的证书）会自动扩容，但不会释放旧缓冲区，导致反复扫描后内存只增不减。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化时限制最大行长：
scanner.Buffer(make([]byte, 4096), 65536)，第二个参数是上限，超限会返回ErrTooLong - 每次循环开始前调用
scanner.Reset(reader)并重置缓冲区，尤其在复用Scanner实例时 - 真要处理大文件且格式规整，考虑流式解析：用
bufio.NewReader+ReadLine()手动控制内存，比 Scanner 更可控
词法分析最易被忽略的点不是语法多复杂，而是“配置文件到底算谁的输入”——用户随手粘贴的 Windows 换行、编辑器自动加的 BOM、值里混入的制表符，都会让看似简单的 = 分割崩掉。别急着写 parser，先用 hexdump -C 看一眼真实字节。
