应结合文件头（magic bytes）和扩展名识别格式，优先信任不可伪造的 magic bytes；初始化时注册扩展名与解析器映射表，并维护 magic header 到解析器的结构体切片，读取最多16字节比对分发；解析 CSV/JSON/YAML/二进制等需分别处理脏数据、循环引用、变长字段及校验逻辑。
如何用 Go 识别并分发不同文件格式的解析逻辑
Go 没有内置的“文件类型路由”机制，os.File 本身不暴露格式信息。你得自己决定从哪读、读多少、怎么分发——最稳妥的方式是结合文件头（magic bytes）和扩展名，且优先信任 magic bytes，因为扩展名可伪造。
常见错误是只查 filepath.Ext()，结果遇到 report.xls.bin 或无后缀的配置文件就 panic。建议在初始化时注册一个映射表：
-
map[string]func(io.Reader) (interface{}, error)存扩展名对应解析器 - 额外维护一个
[]struct{ header []byte; parser func(...) }处理 magic bytes - 解析前先读取最多 16 字节（足够覆盖 PNG、PDF、JSON、ELF 等头部），再比对 magic 表
解析 CSV/TSV 时如何应对脏数据和内存失控
encoding/csv 默认把整行加载进内存，遇到超长字段或缺失换行符会 OOM。别直接传 os.File 给 csv.NewReader()，必须加约束：
- 用
io.LimitReader(f, maxFileSize)控制总读取量 - 调用
reader.FieldsPerRecord = -1允许变长列，避免record on line X has wrong number of fields - 对每行手动调用
reader.Read()并检查len(record) > expectedCols，截断或报错 - 避免用
ReadAll()—— 它会把全部内容塞进一个[][]string，GC 压力陡增
解析 JSON/YAML/TOML 配置文件时的嵌套与循环引用处理
Go 的 json.Unmarshal() 和第三方库如 gopkg.in/yaml.v3 默认不检测循环引用，深层嵌套结构可能栈溢出或无限递归。尤其 YAML 支持 &anchor 和 *alias，必须显式开启保护：
立即学习“go语言免费学习笔记（深入）”；
- YAML 解析务必设置
yaml.Decoder.SetStrict(true)，否则!!python/object类型可能触发非预期行为 - TOML 用
github.com/pelletier/go-toml/v2时，启用toml.UnmarshalOptions{DisallowUnknownFields: true}防止拼写错误静默忽略 - 所有结构体字段加
json:",omitempty"或yaml:"-,omitempty"，避免零值污染语义 - 禁止直接将
interface{}传给json.Marshal()—— 若含time.Time或自定义类型，会 panic
二进制格式（如 Protocol Buffers、PE、ELF）解析为何不能只靠 binary.Read()
binary.Read() 要求结构体字段顺序、对齐、大小完全匹配二进制布局，但真实格式往往含变长字段、跳过字节、条件段落。硬套会导致读偏移错位，后续全乱。
真正可行的做法是：用 binary.Read() 只读固定头部（如 ELF 的 e_ident 16 字节），再根据其中标志位（如 e_type, e_machine）决定后续解析策略；变长部分一律用 io.ReadFull() + 手动偏移计算。
- Protocol Buffers 必须用
proto.Unmarshal()，别试图用binary包——protobuf 是 TLV 编码，不是结构体镜像 - 读 PE 文件时，
OptionalHeader大小取决于PE32还是PE32+，得先读NT_HEADERS.Signature和FileHeader.Machine再分支 - 任何二进制解析器都要带校验：比如 ELF 的
e_ident[0:4]必须是[0x7f, 'E', 'L', 'F']，否则立刻返回fmt.Errorf("invalid ELF magic")
文件格式解析最难的不是读出数据，而是定义清晰的错误边界——哪些错要告警，哪些错要丢弃整份文件，哪些错可以跳过单条记录继续。这些判断点必须在解析器入口就固化，而不是等 panic 了再补 recover。
