根本原因是Go子进程默认不继承shell环境（如PATH），需用绝对路径调用ffmpeg、显式设置工作目录、捕获stderr、加超时控制；Gin中应先保存上传文件为临时文件再处理；提取缩略图需用输入侧seek定位I帧；并发需用channel限流防OOM。
为什么 ffmpeg 命令在 Gin 的 exec.Command 中总失败？
根本原因不是 Gin 本身，而是 Go 子进程默认不继承 shell 环境（比如 PATH），且工作目录、权限、信号处理都和终端直跑不同。常见报错是 exec: "ffmpeg": executable file not found in $PATH 或静默退出。
- 别依赖系统
PATH：用绝对路径调用ffmpeg，例如/usr/bin/ffmpeg（先用which ffmpeg确认） - 显式设置工作目录：用
cmd.Dir指向一个有读写权限的临时目录，避免在/tmp外写入失败 - 捕获 stderr：必须用
cmd.Stderr = &buf，否则错误全丢掉，只看到空图或 0 字节文件 - 加超时控制：视频解析可能卡住，用
exec.CommandContext配合context.WithTimeout，建议上限 10 秒
Gin 路由怎么安全接收视频文件并提取缩略图？
不能直接把用户上传的 multipart/form-data 文件喂给 ffmpeg——它不支持从 stdin 读取任意格式的视频流（尤其 MP4 容器需要随机访问）。必须先落地为临时文件。
- 用
c.FormFile("video")获取上传句柄，再file.Open()得到*os.File - 用
os.CreateTemp("", "upload-*.mp4")创建带随机后缀的安全临时文件，避免重名或路径遍历 - 用
io.Copy写入（别用file.Write，它不保证写完），完成后defer os.Remove(tempPath) - 缩略图输出也走临时文件，生成成功后再
c.DataFromFS返回，别用c.File（它会尝试设置Content-Disposition，对图片不友好）
ffmpeg 提取关键帧的参数怎么选才又快又准？
“第一帧”不等于“首关键帧”，MP4/H.264 视频开头常是 B/P 帧，直接 -vframes 1 可能抽到黑图或花屏。得让 ffmpeg 先 seek 到最近 I 帧。
- 推荐命令：
ffmpeg -ss 00:00:01 -i input.mp4 -vf "scale=320:-1" -vframes 1 -y thumbnail.jpg -
-ss放在-i前是“输入侧 seek”，跳过解码，速度快；放后面是“输出侧 seek”，精度高但慢 -
scale=320:-1保持宽高比缩放，避免硬编码分辨率导致变形；-y强制覆盖，防止因文件存在而静默失败 - 如果首秒没画面（比如黑场片头），可试
-ss 00:00:05或加-skip_frame nokey强制只抽 I 帧（但会慢）
并发请求下缩略图服务为啥 OOM 或 CPU 爆满？
ffmpeg 是重量级进程，每个请求起一个实例，10 个并发就 10 个 ffmpeg 进程，内存和 CPU 瞬间吃紧。Gin 默认不带限流，得自己兜底。
立即学习“go语言免费学习笔记（深入）”；
- 用 channel 实现简单令牌桶：
var sem = make(chan struct{}, 3)，每个请求先sem ，处理完再 <code><-sem - 别用
runtime.GOMAXPROCS硬调，Go 调度器管 goroutine，不管ffmpeg进程 - 对同一视频 URL 的重复请求，应加内存缓存（如
map[string]string存文件路径），键用md5(videoBytes)或 URL + 分辨率组合 - 注意
os.RemoveAll清理临时目录的时机——如果多个请求共用一个临时目录，删早了会误删别人正在写的文件
真正麻烦的是视频格式兼容性：WebM、MOV、AVI 的关键帧分布、编码器差异极大，靠一套 ffmpeg 参数很难通吃。上线前务必拿真实用户上传的样本压测，而不是只用自己转的 MP4 测试。
