go中调用ffmpeg命令行切片最稳，因其底层适配千种编码格式与时间戳异常，手动解析易出b帧、dts/pts错乱等问题；推荐-c copy加关键帧对齐，配合ffprobe校验元数据与文件完整性。
Go 里用 ffmpeg 命令行切片最稳，别硬写解码逻辑
直接调 ffmpeg 是当前 Go 处理视频切片最可靠的方式。FFmpeg 底层适配了上千种编码格式、容器封装和时间戳异常情况，自己用 gocv 或 goav 手动解析帧，大概率卡在 B-frame 顺序、DTS/PTS 错乱、非关键帧起始点这些细节上。
常见错误现象：output.mp4 播放卡顿、首帧黑屏、时长对不上、音频不同步——基本都是跳过了 ffmpeg 自动做的 stream re-muxing 和 timestamp correction。
- 使用场景：按时间切（如每 10 秒一段）、按关键帧切（
-force_key_frames）、抽帧存图（-vf fps=1） - 推荐命令结构：
ffmpeg -i input.mp4 -ss 00:01:30 -t 10 -c copy -avoid_negative_ts make_zero output_01.mp4 -
-c copy能避免重编码，但要求起始点必须是关键帧；否则加-noaccurate_seek+-c:a aac -c:v libx264回退到转码模式 - Go 中用
exec.Command调用，注意设置cmd.Stderr捕获Invalid data found when processing input这类提示——它往往意味着文件损坏或索引缺失，不是参数错
ffprobe 解析元数据比 Go 原生库快且准
想读视频宽高、码率、时长、编码格式、关键帧间隔？别碰 github.com/3d0c/gmf 或自己解析 MP4 Box，它们对 fragmented MP4、HEVC with HDR meta、QuickTime timecode track 支持极弱。直接跑 ffprobe -v quiet -print_format json -show_format -show_streams input.mp4 最省心。
常见错误现象：Duration: N/A 出现在输出里，说明文件没内建 duration 字段（常见于直播录制未正常结束的 .ts/.mp4），这时得靠解析 streams[0].duration_ts 和 streams[0].time_base 自己算，而不是盲信 format.duration。
立即学习“go语言免费学习笔记（深入）”；
- 关键字段优先级：时长看
streams[0].duration（有值就用），没有则用format.duration；若都空，再算duration_ts * time_base - 判断是否含音频：
len(streams)> 1 且存在codec_type == "audio"，不能只看format.nb_streams——有些文件 audio stream 被标记为attached_pic - Go 解析 JSON 时，把
duration字段声明为json.Number，避免 float64 精度丢失导致 123.999999999 秒
切片后校验不能只看文件大小和 err == nil
切片成功 ≠ 视频可播。很多脚本跑完 err == nil 就认为 OK，结果发现生成的 part_03.mp4 实际只有 200 字节（ffmpeg 写入中途被 kill 但没报错），或者音视频流时间基不一致导致播放器拒绝加载。
真实使用场景：批量切片后自动上传 CDN，某一段播不出，排查要 2 小时——其实本地加一步校验只要 200ms。
- 必做三件事：
os.Stat()看文件大小是否 > 1KB；ffprobe -v error -show_entries format=duration input.mp4 -of default=nw=1确保能读出 duration；ffmpeg -v error -i input.mp4 -f null -验证能否完整 decode（会吐出frame=XXXX行） - 特别注意
ffmpeg -f null -的退出码：0 = 正常播完，1 = 解码失败（如 missing codec），255 = 文件不可读（权限/路径错） - 如果切片量大，把校验逻辑塞进 goroutine，但限制并发数（比如
sem := make(chan struct{}, 3)），避免同时起一堆ffprobe把 CPU 打满
Windows 下路径空格和中文会让 ffmpeg 静默失败
Go 构造命令行时，input.mp4 路径含空格或中文，exec.Command("ffmpeg", "-i", path, ...) 在 Windows 上大概率失败，且 cmd.Run() 返回 nil 错误——因为 ffmpeg.exe 自己解析参数时崩了，根本没进主逻辑。
这不是 Go 的 bug，是 Windows CreateProcess 对参数分词的限制。Linux/macOS 下同样路径可能侥幸通过，但别依赖。
- 解决方法只有一个：所有路径参数（
-i、-o、-f后面的）都用双引号包裹，且在 Go 里显式加上，例如："-i", """ + path + """ - 更稳妥的做法：用
filepath.Abs(path)转成绝对路径，再strings.ReplaceAll(absPath, "\", "/")统一斜杠，最后包双引号 - 别信
exec.Command的文档说“自动处理空格”——它只负责把字符串传给系统 API，不负责 ffmpeg 怎么解析
复杂点在于，同一套代码既要跑在 CI 的 Linux Docker 里，又要支持运维同学本地 Windows 双击运行。路径处理这一步漏掉，后面所有切片都会“看似成功实则无效”，而且很难复现——因为开发机路径短、无空格，问题只在客户环境爆发。
