视频文件应优先用ffprobe而非mp4ff，因其支持fragmented mp4、hevc with hdr等复杂场景，并能自动fallback计算duration_ts * time_base；mp4ff仅适合纯go的box层级修改。
别指望 os.Stat() 能读出视频时长、图片拍摄时间或 PDF 作者——它只返回操作系统级元数据，真要提取内容层属性，必须分格式选工具。
视频文件（MP4/TS/MOV）该用 ffprobe 还是纯 Go 库？
ffprobe 是事实标准，mp4ff 等纯 Go 库只适合特定修改场景。ffprobe 能处理 fragmented MP4、HEVC with HDR、QuickTime timecode，而 mp4ff 在 duration 为 N/A 时不会自动 fallback 到 duration_ts * time_base，容易返回 0。
- 直接执行：
ffprobe -v quiet -print_format json -show_format -show_streams input.mp4 - 解析
json.Number类型的format.duration字段，避免 float64 精度丢失（如"123.456"变成123.45599999999999） - Duration 为空时，遍历
streams找视频流，用duration_ts * time_base计算 - 音频流不固定在索引 1，需循环检查
codec_type == "audio" - HTTP URL 探测失败？服务端若不支持
206 Partial Content，ffprobe 会下载整个文件——大视频直接超时
图像文件（JPEG/WebP/AVIF/HEIC）怎么选解析库？
格式差异大，不能一把抓：JPEG/HEIC/TIFF 用 imagemeta，WebP 用 chai2010/webp，AVIF 目前没成熟 Go 库，得 fallback 到外部命令。
-
mime.TypeByExtension(".avif")返回空字符串——Go 原生不支持 AVIF -
chai2010/webp.GetInfo()对含 XMP 的 WebP 可能误判hasAlpha，因默认跳过非图像块 - 只需宽高？用
webp.GetInfo()，别调webp.Decode()全量解码 - 上传场景必须先读前 512 字节做
http.DetectContentType()，所有图像库都不校验文件头是否被篡改
PDF 和文档元数据为什么 os.Stat() 拿不到？
os.Stat() 返回的 FileInfo 里 Size() 和 ModTime() 都正常，但作者、标题、创建软件这些全为空——因为它们藏在 PDF 的 /Info 字典里，不是系统属性。
- 用
pdfcpu info file.pdf查看，先确认/Info字典是否存在（某些生成器会省略） - 别用
go-pdf或unidoc的低层 API 手动解析字典，容易漏字段或 panic - 容器环境记得装 Perl 运行时：Dockerfile 中
apt-get install -y exiftool perl，只 COPYexiftool二进制会卡住 -
go-exiftool启动失败时不会报错，而是NewExiftool()直接 panic——必须检查et, err := exiftool.NewExiftool()的err
HTTP 上传文件时，multipart.FileHeader 能信多少？
只信 fh.Size 和 fh.Header.Get("Content-Type")（后者仅作参考），其余全是浏览器可控字段，不可用于路径拼接或权限判断。
-
fh.Filename可能是"C:\fakepath\avatar.jpg"（IE/Edge）、空字符串（iOS Safari）或带../（恶意构造） - 上传时的真实 MIME 类型必须靠
http.DetectContentType()读前 512 字节，fh.Header.Get("Content-Type")可被伪造 - 别用
strings.HasSuffix(fh.Filename, ".jpg")判断类型——后缀毫无意义，fh.Header.Get("Content-Type")更不可靠 - 需要内容校验？必须打开文件并解析，
multipart.FileHeader不提供任何内容层信息
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
