不一定。默认csv.Reader要求引号字段严格闭合、换行仅限引号内，符合RFC 4180；若数据来自不可控源（如用户上传），需设LazyQuotes=true容忍不规范引号，但须配合FieldsPerRecord校验字段数。
Go 处理特殊格式文件没有统一“万能模式”，核心是按数据结构选包、按边界条件调参、按错误类型做 fallback。
csv.Reader 处理含换行/引号字段时必须设 LazyQuotes 吗？
不一定。默认情况下 csv.Reader 要求引号字段严格闭合、换行只能出现在引号内，符合 RFC 4180。但现实数据常有不规范写法，比如："foo"bar 或未闭合的 "name,addr —— 这时会报 invalid quoted field。
解决方式取决于你对数据质量的容忍度：
- 若数据源可控（如自产 CSV），保持默认，靠报错暴露格式问题
- 若数据来自用户上传或第三方系统，启用
r.LazyQuotes = true可跳过部分引号校验，但要注意：它不会修复逻辑错误，只让解析“继续下去” - 永远配合
r.FieldsPerRecord使用，比如设为5，一旦某行字段数不是 5 就立刻中断，比事后遍历检查更早发现问题
读取大 JSON 文件不能直接用 json.Unmarshal？
对。如果整个 JSON 是一个巨型数组（如百万条日志），json.Unmarshal 会把全部内容加载进内存再解析，极易 OOM。
立即学习“go语言免费学习笔记（深入）”；
正确做法是流式解析：
- 用
json.NewDecoder(file)替代json.Unmarshal - 对数组结构，先读
{或[，再循环调用decoder.Decode(&item)单条解码 - 注意：JSON 流中不能有注释、尾逗号，否则会报
invalid character—— 这类非标准格式需先预处理或换库（如goccy/go-json）
二进制协议头解析为何总读错字段偏移？
常见原因是结构体内存对齐和字节序混用。例如定义：
type Header struct {
Magic uint32
Len uint16
Flags uint8
}
实际二进制可能是紧凑排列（共 7 字节），但 Go 默认按 4 字节对齐，导致 Len 实际读到的是第 4–5 字节，而非预期的第 4–5 字节 —— 这就错位了。
安全做法是避免直接 decode 整个 struct：
- 用
binary.Read逐字段读：binary.Read(r, binary.BigEndian, &h.Magic)，再读&h.Len - 确认原始协议文档指定的字节序（
BigEndian还是LittleEndian），不要凭感觉猜 - 字段类型必须显式用
uint32/int16等固定宽度类型，禁用int或uint
XML 解析失败却没报具体哪一行出错？
encoding/xml 默认不带行号信息，xml.SyntaxError 的 Line 字段常为 0，尤其在嵌套深或含 CDATA 时。
要准确定位，得自己包装 reader：
- 用
xml.NewDecoder替代xml.Unmarshal - 传入一个带行号追踪的
bufio.Scanner或自定义io.Reader（记录当前 offset） - 捕获
xml.SyntaxError后，结合 offset 查原始字节流，比依赖Line更可靠
真正难的不是选哪个包，而是判断“这个格式到底算不算‘特殊’”——有些文件看着像 CSV，实则是用竖线分隔、首行无标题、末尾多空行；有些 JSON 带 BOM 头、字段名大小写混乱。这些细节才是决定解析成败的关键点。
