必须读取前16字节比对magic number校验文件真实类型，JPEG为0xFF 0xD8、PNG为0x89 0x50 0x4E 0x47，禁用扩展名判断，校验需嵌入写入流程并绑定trace ID确保原子性与可追溯性。
上传后立刻校验文件头（magic number）
文件扩展名可伪造，仅靠 filepath.Ext 判断类型不可信。必须读取前几个字节比对 magic number，这是校验的第一道防线。
常见错误是直接用 os.Open 后全量读取再判断——既慢又浪费内存，尤其大文件上传时可能 OOM。应只读前 16 字节（足够覆盖 PNG/JPEG/ZIP/CSV 等主流格式签名）。
- 用
io.ReadFull配合bytes.NewReader或临时io.LimitReader控制读取长度 - JPEG 开头是
0xFF 0xD8，PNG 是0x89 0x50 0x4E 0x47，CSV 无固定 magic，需 fallback 到 MIME 推断或内容采样 - 注意：Windows 上传的文件可能带 BOM，UTF-8 CSV 若含
0xEF 0xBB 0xBF，别误判为非法
按业务类型调用对应解析器做结构校验
校验不能止于“是 PNG”，还要确认它是否真能被你的图像处理逻辑安全消费。不同业务场景要走不同解析路径：
- 图片类（
image.Decode）：用image.DecodeConfig先查尺寸和格式，避免解码超大图导致内存暴涨 - Excel（
excelize.File）：创建excelize.File实例后立即调用f.GetSheetList()，若 panic 或返回空说明文件损坏或非 Excel - CSV（
encoding/csv.Reader）：设reader.FieldsPerRecord = -1，读首行就校验列数是否符合预期；用csv.NewReader(io.LimitReader(file, 1024*1024))防止超长行阻塞 - JSON（
json.Decoder）：用decoder.DisallowUnknownFields()拒绝多余字段，配合io.LimitReader限制总大小
并发上传时校验失败需精准返回原始错误位置
多个 goroutine 并发处理上传文件时，若共用同一份日志或错误通道，容易混淆哪个文件、哪一行出错。错误信息必须绑定上下文。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 每个上传请求生成唯一 trace ID（如
uuid.NewString()），在所有校验日志和错误中透传 - 校验 CSV 时捕获
csv.ParseError，其Line和Column字段要原样带上，不要只返回 “CSV 格式错误” - 避免在 defer 中统一 recover —— 它会吞掉原始 panic 的堆栈，改用显式
if err != nil分支并包装为fmt.Errorf("validate csv %s: %w", filename, err)
校验结果必须与存储动作原子化
文件写入磁盘成功但校验失败，或校验通过但写入失败，都会导致状态不一致。不能先保存再校验，也不能校验完再保存——必须把校验嵌入写入流程。
- 用
io.MultiWriter将上传流同时写入内存 buffer（用于校验）和磁盘文件（os.Create），但注意 buffer 大小要可控（如 10MB 上限） - 更稳妥做法：先写入临时文件（
os.CreateTemp），校验通过后再os.Rename；失败则直接os.Remove临时文件 - 特别注意：
os.Rename在同分区是原子的，跨分区会退化为 copy+remove，此时需加锁或改用数据库事务标记状态
实际最难的不是写校验逻辑，而是让每种格式的“合法”定义和业务需求对齐——比如业务说“支持 Excel”，但没说清是否接受 .xls（OLE 格式），而 excelize 默认不支持；这种隐含假设，往往比代码本身更容易出问题。
