5个视频在线压缩方案图解原理与选型避坑
昨天帮一个做跨境电商的朋友排查故障，他发来的代码是从某技术论坛复制的“视频在线压缩”片段，本地跑报错，服务器部署直接502超时。这种复制来的代码跑不通不知道怎么调的情况太常见了。大家以为视频压缩就是调个API传个参数，其实背后涉及转码引擎、分片上传、流式处理等复杂链路。今天不整虚的，直接通过图解原理拆解市面上主流的5种技术方案，帮你避开那些看不见的坑。
各自定位：谁在解决什么问题
在深入代码之前，必须先厘清这五种方案的核心定位。很多新手一上来就写代码，结果发现选错了方向，性能瓶颈根本不在代码层，而在架构层。
1. 纯前端WebAssembly方案
代表技术：ffmpeg.wasm
定位：隐私敏感、小文件、无后端依赖场景。
核心逻辑：将FFmpeg编译为WASM，在浏览器内存中运行。用户无需上传文件到服务器，数据不出本地。
痛点：浏览器内存限制（通常2GB），大文件直接崩溃；首次加载WASM包体积巨大（~30MB），CDN优化不当会导致白屏。
2. Node.js后端流式处理方案
代表技术：fluent-ffmpeg + S3
定位：中小规模SaaS、需要即时反馈、逻辑复杂的处理链。
核心逻辑：Node.js接收上传，启动FFmpeg子进程，流式读取输入，流式写入S3。
痛点：Node.js单线程模型在处理高并发视频流时容易阻塞Event Loop；FFmpeg是CPU密集型任务，需要Worker Threads或PM2集群支撑。
3. 微服务容器化方案
代表技术：Docker + Go/Rust + FFmpeg CLI
定位：高并发、高吞吐、需要水平扩展的场景。
核心逻辑：视频任务进入消息队列（如Kafka/RabbitMQ），消费者Pod启动容器执行压缩，完成后回调通知。
痛点：容器冷启动延迟；资源隔离导致CPU利用率波动；调试难度极大，需要完善的日志追踪链路。
4. 云端GPU加速方案
代表技术：AWS Elemental MediaConvert / 阿里云MPS
定位：超高分辨率、4K/8K、AI增强（如超分、降噪）、对成本不敏感的B端业务。
核心逻辑：直接调用云厂商API，上传OSS/S3，获取任务ID，轮询状态。
痛点：按量付费成本高昂；厂商锁定（Vendor Lock-in）；网络带宽成为主要瓶颈。
5. 混合边缘计算方案
代表技术：Cloudflare Workers + R2 + WASM
定位：全球分发、低延迟、边缘预处理。
核心逻辑：视频在边缘节点进行轻量级转码或元数据提取，重负载任务回源中心集群。
痛点：边缘节点CPU资源极其有限，只能做极低码率或短片段处理；开发调试环境受限。
核心差异：一张表看懂底层逻辑
很多开发者纠结选哪个，往往是因为没看清底层IO模型和资源占用差异。下表从关键维度做了横向对比，建议截图保存，选型时对着打勾。
维度
纯前端WASM
Node.js流式
微服务容器
云端API
边缘混合
数据隐私
⭐⭐⭐⭐⭐ (本地处理)
⭐⭐⭐ (传输加密)
⭐⭐⭐ (内网传输)
⭐ (数据上云)
⭐⭐⭐⭐ (边缘处理)
大文件支持
❌ (内存瓶颈)
✅ (需分片)
✅ (分片+队列)
✅ (分片上传)
❌ (边缘限制)
启动延迟
高 (WASM加载)
中 (进程启动)
高 (容器冷启)
低 (API调用)
低 (边缘就近)
CPU利用率
受限于浏览器线程
易阻塞主线程
可控 (K8s Limit)
厂商托管
极低
开发复杂度
高 (前端工程化)
中 (异步流处理)
高 (分布式系统)
低 (SDK调用)
高 (边缘逻辑)
成本结构
低 (用户设备算力)
中 (服务器算力)
高 (集群维护)
高 (按量付费)
中 (带宽+算力)
典型场景
剪辑预览、隐私视频
社交App、UGC平台
企业级媒体平台
广电、影视后期
全球CDN视频分发
关键洞察：没有银弹。如果你的业务是用户自拍上传到社交平台，Node.js流式是性价比之王；如果是金融级隐私视频，纯前端WASM是唯一解；如果是4K影视分发，别犹豫，直接上云端API，自己搭集群不如买服务。
代码写法对比：从入门到入土
光说不练假把式。下面给出三种最常用方案的核心代码片段，并标注关键陷阱。注意，这些代码是精简版，生产环境需增加错误处理、重试机制和监控埋点。
1. 纯前端：ffmpeg.wasm (JavaScript)
这是最容易踩坑的方案。很多人忽略SharedArrayBuffer和Cross-Origin Isolation的要求，导致浏览器直接拒绝执行。根据MDN Web Docs关于WebAssembly的说明，使用多线程WASM必须满足COOP/COEP头设置。
// 依赖: npm i @ffmpeg/ffmpeg @ffmpeg/core
import { FFmpeg } from '@ffmpeg/ffmpeg';
import { fetchFile } from '@ffmpeg/util';
const ffmpeg = new FFmpeg();
// 关键：必须在HTTPS下，且响应头包含 COOP/COEP
// 如果没配这俩头，load() 会直接报错
const loadFFmpeg = async () = {
await ffmpeg.load({
coreURL: await toBlobURL(`${coreURL}/ffmpeg-core.wasm`, 'application/wasm'),
wasmURL: await toBlobURL(`${coreURL}/ffmpeg-core.js`, 'text/javascript'),
});
return ffmpeg;
};
const compressVideo = async (file) = {
const ff = await loadFFmpeg();
// 1. 写入文件到虚拟文件系统
await ff.writeFile('input.mp4', await fetchFile(file));
// 2. 执行压缩命令
// 注意：-crf 23 是H.264默认质量，数值越小质量越高文件越大
// -preset fast 是编码速度与质量的平衡点
const exitCode = await ff.exec([
'-i', 'input.mp4',
'-c:v', 'libx264',
'-crf', '28', // 这里设为28，平衡体积与画质
'-preset', 'fast',
'-c:a', 'aac',
'-b:a', '128k',
'output.mp4'
]);
if (exitCode !== 0) {
throw new Error('Compression failed');
}
// 3. 读取输出文件
const data = await ff.readFile('output.mp4');
const blob = new Blob([data], { type: 'video/mp4' });
// 4. 清理虚拟文件系统，防止内存泄漏
await ff.deleteFile('input.mp4');
await ff.deleteFile('output.mp4');
return blob;
};
避坑点：fetchFile 会占用内存，处理大文件时务必在 exec 完成后立即 deleteFile。否则，处理100MB视频，浏览器内存占用会飙升到500MB+，移动端直接卡死。
2. Node.js：流式处理 (TypeScript)
Node.js处理视频的核心是流管道（Pipeline）。切记不要使用 fs.readFileSync 读取视频文件，那会瞬间击穿内存。必须使用 ReadableStream 和 WritableStream。
import { spawn } from 'child_process';
import { createReadStream, createWriteStream } from 'fs';
import { pipeline } from 'stream/promises';
import { S3 } from 'aws-sdk';
const s3 = new S3();
async function compressToS3(inputPath: string, outputKey: string) {
// 1. 启动FFmpeg进程
const ffmpegProcess = spawn('ffmpeg', [
'-i', inputPath,
'-c:v', 'libx264',
'-crf', '25',
'-preset', 'medium',
'-f', 'mp4', // 强制格式，防止容器封装错误
'pipe:1' // 输出到stdout
]);
// 2. 捕获错误流
ffmpegProcess.stderr.on('data', (data) = {
console.error(`FFmpeg: ${data}`);
// 生产环境需解析FFmpeg日志，区分警告与致命错误
});
// 3. 创建S3上传流
const uploadParams = {
Bucket: 'your-bucket',
Key: outputKey,
ContentType: 'video/mp4'
};
const s3Upload = s3.upload(uploadParams);
// s3.upload 返回的对象支持作为WritableStream使用
// 4. 管道串联：FFmpeg stdout - S3
// pipeline 会在任一环节出错时自动销毁所有流，防止内存泄漏
try {
await pipeline(
ffmpegProcess.stdout,
s3Upload
);
} catch (error) {
console.error('Pipeline error:', error);
// 清理临时文件
fs.unlink(inputPath, () = {});
throw error;
}
ffmpegProcess.on('close', (code) = {
if (code !== 0) {
throw new Error(`FFmpeg exited with code ${code}`);
}
});
}
避坑点：spawn 是异步的，但 pipeline 是Promise。务必监听 close 事件确认退出码。如果FFmpeg因参数错误退出，stdout 可能没有数据，S3上传会成功但文件是0字节。这是新手最常遇到的“鬼畜”bug。
3. Go：微服务消费者 (Go)
Go适合做高并发的任务消费者。核心优势是Goroutine轻量级，适合处理大量并发任务，但FFmpeg调用本身是阻塞的，需要封装好。
package main
import (
context
fmt
log
os/exec
time
)
func processVideo(ctx context.Context, inputPath, outputPath string) error {
// 创建带超时的Context，防止FFmpeg挂死
ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)
defer cancel()
// 构建FFmpeg命令
cmd := exec.CommandContext(ctx, ffmpeg,
-i, inputPath,
-c:v, libx264,
-crf, 23,
-preset, fast,
-y, // 覆盖输出
outputPath,
)
// 捕获stderr，FFmpeg日志在这里
cmd.Stderr = os.Stderr
cmd.Stdout = os.Stdout
// 启动命令
if err := cmd.Start(); err != nil {
return fmt.Errorf(failed to start ffmpeg: %w, err)
}
// 等待完成
if err := cmd.Wait(); err != nil {
return fmt.Errorf(ffmpeg exited with error: %w, err)
}
return nil
}
func main() {
// 模拟从队列获取任务
for {
select {
case -ctx.Done():
return
case inputPath := -taskChannel:
outputPath := fmt.Sprintf(%s_compressed.mp4, inputPath)
log.Printf(Processing %s, inputPath)
if err := processVideo(ctx, inputPath, outputPath); err != nil {
log.Printf(Error processing %s: %v, inputPath, err)
// 这里应发送错误到死信队列或重试机制
continue
}
log.Printf(Successfully processed %s, outputPath)
}
}
}
避坑点：exec.CommandContext 是Go 1.20+的推荐方式。旧版本使用 exec.Command 后手动 Kill，容易导致僵尸进程。另外，FFmpeg在Linux下依赖大量系统库（libx264, libvpx等），Docker镜像务必使用 ffmpeg 官方镜像或自行编译静态链接版本，否则容器启动报 shared library not found。
适用场景：对号入座
别被技术名词忽悠，根据你的业务形态选：
个人博客/小工具：用纯前端WASM。零服务器成本，用户数据隐私好。但限制是文件大小，超过500MB就别硬撑了，引导用户走云端。
社交/UGC平台（日活10万）：Node.js流式。开发快，生态好，配合S3分片上传，能扛住一定并发。记得用PM2集群，单进程CPU跑满就挂了。
企业级媒体平台/视频SaaS：微服务容器化。Go或Rust写消费者，K8s部署。虽然开发重，但弹性伸缩能力强，峰值流量来了自动扩容，闲时缩容省钱。
广电/影视/4K需求：云端API。别自己折腾GPU集群了，AWS MediaConvert或阿里云MPS，虽然贵，但省心。你的核心竞争力是内容，不是转码引擎。
全球化低延迟需求：边缘混合。在Cloudflare或阿里云边缘节点做轻量转码（如720p预览），高清原片回源中心处理。用户体验极佳，但架构复杂，适合有大团队维护的公司。
选型建议与进阶技巧
分片上传是标配：无论选哪种后端方案，前端必须实现分片上传。视频文件动辄几个G，HTTP单请求超时是常态。分片后，每个分片独立重试，失败只重传该分片。
异步化是底线：视频压缩耗时从秒级到分钟级不等，严禁同步等待。必须返回任务ID，通过WebSocket或SSE推送进度，或提供轮询接口。
参数调优：-crf 和 -preset 是黄金组合。CRF 18-23 视觉无损，CRF 23-28 网络流媒体常用，CRF 30 画质明显劣化。Preset ultrafast 编码最快但文件最大，slow 编码最慢但文件最小。根据业务容忍度调整。
监控与告警：FFmpeg退出码非0是致命错误。必须监控 stderr 日志，并设置超时熔断。如果FFmpeg进程挂死，你的队列会堆积，最终雪崩。
格式兼容性：MP4是Web端通吃格式，但H.265 (HEVC) 编码效率更高，文件更小。然而，旧版Safari对HEVC支持不佳。建议输出H.264为主，HEVC为可选高级选项。
最后，关于性能测试：不要只看代码跑通，要做压力测试。用 wrk 或 k6 模拟并发上传，监控CPU、内存、磁盘IO。你会发现，瓶颈往往不在FFmpeg本身，而在磁盘IO或网络带宽。提前规划好存储层，比优化代码更重要。
你在项目里踩过这个坑吗？比如FFmpeg内存泄漏、S3上传断点续传失败，还是WASM在移动端崩溃？评论区聊聊，看看谁踩的坑更深。 
长河君 · 2026/9/22 2:08:39 · 阅读 1.2k 5个视频在线压缩方案图解原理与选型避坑
5个视频在线压缩方案图解原理与选型避坑
昨天帮一个做跨境电商的朋友排查故障，他发来的代码是从某技术论坛复制的“视频在线压缩”片段，本地跑报错，服务器部署直接502超时。这种复制来的代码跑不通不知道怎么调的情况太常见了。大家以为视频压缩就是调个API传个参数，其实背后涉及转码引擎、分片上传、流式处理等复杂链路。今天不整虚的，直接通过图解原理拆解市面上主流的5种技术方案，帮你避开那些看不见的坑。
各自定位：谁在解决什么问题
在深入代码之前，必须先厘清这五种方案的核心定位。很多新手一上来就写代码，结果发现选错了方向，性能瓶颈根本不在代码层，而在架构层。
1. 纯前端WebAssembly方案
代表技术：ffmpeg.wasm
定位：隐私敏感、小文件、无后端依赖场景。
核心逻辑：将FFmpeg编译为WASM，在浏览器内存中运行。用户无需上传文件到服务器，数据不出本地。
痛点：浏览器内存限制（通常2GB），大文件直接崩溃；首次加载WASM包体积巨大（~30MB），CDN优化不当会导致白屏。
2. Node.js后端流式处理方案
代表技术：fluent-ffmpeg + S3
定位：中小规模SaaS、需要即时反馈、逻辑复杂的处理链。
核心逻辑：Node.js接收上传，启动FFmpeg子进程，流式读取输入，流式写入S3。
痛点：Node.js单线程模型在处理高并发视频流时容易阻塞Event Loop；FFmpeg是CPU密集型任务，需要Worker Threads或PM2集群支撑。
3. 微服务容器化方案
代表技术：Docker + Go/Rust + FFmpeg CLI
定位：高并发、高吞吐、需要水平扩展的场景。
核心逻辑：视频任务进入消息队列（如Kafka/RabbitMQ），消费者Pod启动容器执行压缩，完成后回调通知。
痛点：容器冷启动延迟；资源隔离导致CPU利用率波动；调试难度极大，需要完善的日志追踪链路。
4. 云端GPU加速方案
代表技术：AWS Elemental MediaConvert / 阿里云MPS
定位：超高分辨率、4K/8K、AI增强（如超分、降噪）、对成本不敏感的B端业务。
核心逻辑：直接调用云厂商API，上传OSS/S3，获取任务ID，轮询状态。
痛点：按量付费成本高昂；厂商锁定（Vendor Lock-in）；网络带宽成为主要瓶颈。
5. 混合边缘计算方案
代表技术：Cloudflare Workers + R2 + WASM
定位：全球分发、低延迟、边缘预处理。
核心逻辑：视频在边缘节点进行轻量级转码或元数据提取，重负载任务回源中心集群。
痛点：边缘节点CPU资源极其有限，只能做极低码率或短片段处理；开发调试环境受限。
核心差异：一张表看懂底层逻辑
很多开发者纠结选哪个，往往是因为没看清底层IO模型和资源占用差异。下表从关键维度做了横向对比，建议截图保存，选型时对着打勾。
维度
纯前端WASM
Node.js流式
微服务容器
云端API
边缘混合
数据隐私
⭐⭐⭐⭐⭐ (本地处理)
⭐⭐⭐ (传输加密)
⭐⭐⭐ (内网传输)
⭐ (数据上云)
⭐⭐⭐⭐ (边缘处理)
大文件支持
❌ (内存瓶颈)
✅ (需分片)
✅ (分片+队列)
✅ (分片上传)
❌ (边缘限制)
启动延迟
高 (WASM加载)
中 (进程启动)
高 (容器冷启)
低 (API调用)
低 (边缘就近)
CPU利用率
受限于浏览器线程
易阻塞主线程
可控 (K8s Limit)
厂商托管
极低
开发复杂度
高 (前端工程化)
中 (异步流处理)
高 (分布式系统)
低 (SDK调用)
高 (边缘逻辑)
成本结构
低 (用户设备算力)
中 (服务器算力)
高 (集群维护)
高 (按量付费)
中 (带宽+算力)
典型场景
剪辑预览、隐私视频
社交App、UGC平台
企业级媒体平台
广电、影视后期
全球CDN视频分发
关键洞察：没有银弹。如果你的业务是用户自拍上传到社交平台，Node.js流式是性价比之王；如果是金融级隐私视频，纯前端WASM是唯一解；如果是4K影视分发，别犹豫，直接上云端API，自己搭集群不如买服务。
代码写法对比：从入门到入土
光说不练假把式。下面给出三种最常用方案的核心代码片段，并标注关键陷阱。注意，这些代码是精简版，生产环境需增加错误处理、重试机制和监控埋点。
1. 纯前端：ffmpeg.wasm (JavaScript)
这是最容易踩坑的方案。很多人忽略SharedArrayBuffer和Cross-Origin Isolation的要求，导致浏览器直接拒绝执行。根据MDN Web Docs关于WebAssembly的说明，使用多线程WASM必须满足COOP/COEP头设置。
// 依赖: npm i @ffmpeg/ffmpeg @ffmpeg/core
import { FFmpeg } from '@ffmpeg/ffmpeg';
import { fetchFile } from '@ffmpeg/util';
const ffmpeg = new FFmpeg();
// 关键：必须在HTTPS下，且响应头包含 COOP/COEP
// 如果没配这俩头，load() 会直接报错
const loadFFmpeg = async () = {
await ffmpeg.load({
coreURL: await toBlobURL(`${coreURL}/ffmpeg-core.wasm`, 'application/wasm'),
wasmURL: await toBlobURL(`${coreURL}/ffmpeg-core.js`, 'text/javascript'),
});
return ffmpeg;
};
const compressVideo = async (file) = {
const ff = await loadFFmpeg();
// 1. 写入文件到虚拟文件系统
await ff.writeFile('input.mp4', await fetchFile(file));
// 2. 执行压缩命令
// 注意：-crf 23 是H.264默认质量，数值越小质量越高文件越大
// -preset fast 是编码速度与质量的平衡点
const exitCode = await ff.exec([
'-i', 'input.mp4',
'-c:v', 'libx264',
'-crf', '28', // 这里设为28，平衡体积与画质
'-preset', 'fast',
'-c:a', 'aac',
'-b:a', '128k',
'output.mp4'
]);
if (exitCode !== 0) {
throw new Error('Compression failed');
}
// 3. 读取输出文件
const data = await ff.readFile('output.mp4');
const blob = new Blob([data], { type: 'video/mp4' });
// 4. 清理虚拟文件系统，防止内存泄漏
await ff.deleteFile('input.mp4');
await ff.deleteFile('output.mp4');
return blob;
};
避坑点：fetchFile 会占用内存，处理大文件时务必在 exec 完成后立即 deleteFile。否则，处理100MB视频，浏览器内存占用会飙升到500MB+，移动端直接卡死。
2. Node.js：流式处理 (TypeScript)
Node.js处理视频的核心是流管道（Pipeline）。切记不要使用 fs.readFileSync 读取视频文件，那会瞬间击穿内存。必须使用 ReadableStream 和 WritableStream。
import { spawn } from 'child_process';
import { createReadStream, createWriteStream } from 'fs';
import { pipeline } from 'stream/promises';
import { S3 } from 'aws-sdk';
const s3 = new S3();
async function compressToS3(inputPath: string, outputKey: string) {
// 1. 启动FFmpeg进程
const ffmpegProcess = spawn('ffmpeg', [
'-i', inputPath,
'-c:v', 'libx264',
'-crf', '25',
'-preset', 'medium',
'-f', 'mp4', // 强制格式，防止容器封装错误
'pipe:1' // 输出到stdout
]);
// 2. 捕获错误流
ffmpegProcess.stderr.on('data', (data) = {
console.error(`FFmpeg: ${data}`);
// 生产环境需解析FFmpeg日志，区分警告与致命错误
});
// 3. 创建S3上传流
const uploadParams = {
Bucket: 'your-bucket',
Key: outputKey,
ContentType: 'video/mp4'
};
const s3Upload = s3.upload(uploadParams);
// s3.upload 返回的对象支持作为WritableStream使用
// 4. 管道串联：FFmpeg stdout - S3
// pipeline 会在任一环节出错时自动销毁所有流，防止内存泄漏
try {
await pipeline(
ffmpegProcess.stdout,
s3Upload
);
} catch (error) {
console.error('Pipeline error:', error);
// 清理临时文件
fs.unlink(inputPath, () = {});
throw error;
}
ffmpegProcess.on('close', (code) = {
if (code !== 0) {
throw new Error(`FFmpeg exited with code ${code}`);
}
});
}
避坑点：spawn 是异步的，但 pipeline 是Promise。务必监听 close 事件确认退出码。如果FFmpeg因参数错误退出，stdout 可能没有数据，S3上传会成功但文件是0字节。这是新手最常遇到的“鬼畜”bug。
3. Go：微服务消费者 (Go)
Go适合做高并发的任务消费者。核心优势是Goroutine轻量级，适合处理大量并发任务，但FFmpeg调用本身是阻塞的，需要封装好。
package main
import (
context
fmt
log
os/exec
time
)
func processVideo(ctx context.Context, inputPath, outputPath string) error {
// 创建带超时的Context，防止FFmpeg挂死
ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)
defer cancel()
// 构建FFmpeg命令
cmd := exec.CommandContext(ctx, ffmpeg,
-i, inputPath,
-c:v, libx264,
-crf, 23,
-preset, fast,
-y, // 覆盖输出
outputPath,
)
// 捕获stderr，FFmpeg日志在这里
cmd.Stderr = os.Stderr
cmd.Stdout = os.Stdout
// 启动命令
if err := cmd.Start(); err != nil {
return fmt.Errorf(failed to start ffmpeg: %w, err)
}
// 等待完成
if err := cmd.Wait(); err != nil {
return fmt.Errorf(ffmpeg exited with error: %w, err)
}
return nil
}
func main() {
// 模拟从队列获取任务
for {
select {
case -ctx.Done():
return
case inputPath := -taskChannel:
outputPath := fmt.Sprintf(%s_compressed.mp4, inputPath)
log.Printf(Processing %s, inputPath)
if err := processVideo(ctx, inputPath, outputPath); err != nil {
log.Printf(Error processing %s: %v, inputPath, err)
// 这里应发送错误到死信队列或重试机制
continue
}
log.Printf(Successfully processed %s, outputPath)
}
}
}
避坑点：exec.CommandContext 是Go 1.20+的推荐方式。旧版本使用 exec.Command 后手动 Kill，容易导致僵尸进程。另外，FFmpeg在Linux下依赖大量系统库（libx264, libvpx等），Docker镜像务必使用 ffmpeg 官方镜像或自行编译静态链接版本，否则容器启动报 shared library not found。
适用场景：对号入座
别被技术名词忽悠，根据你的业务形态选：
个人博客/小工具：用纯前端WASM。零服务器成本，用户数据隐私好。但限制是文件大小，超过500MB就别硬撑了，引导用户走云端。
社交/UGC平台（日活10万）：Node.js流式。开发快，生态好，配合S3分片上传，能扛住一定并发。记得用PM2集群，单进程CPU跑满就挂了。
企业级媒体平台/视频SaaS：微服务容器化。Go或Rust写消费者，K8s部署。虽然开发重，但弹性伸缩能力强，峰值流量来了自动扩容，闲时缩容省钱。
广电/影视/4K需求：云端API。别自己折腾GPU集群了，AWS MediaConvert或阿里云MPS，虽然贵，但省心。你的核心竞争力是内容，不是转码引擎。
全球化低延迟需求：边缘混合。在Cloudflare或阿里云边缘节点做轻量转码（如720p预览），高清原片回源中心处理。用户体验极佳，但架构复杂，适合有大团队维护的公司。
选型建议与进阶技巧
分片上传是标配：无论选哪种后端方案，前端必须实现分片上传。视频文件动辄几个G，HTTP单请求超时是常态。分片后，每个分片独立重试，失败只重传该分片。
异步化是底线：视频压缩耗时从秒级到分钟级不等，严禁同步等待。必须返回任务ID，通过WebSocket或SSE推送进度，或提供轮询接口。
参数调优：-crf 和 -preset 是黄金组合。CRF 18-23 视觉无损，CRF 23-28 网络流媒体常用，CRF 30 画质明显劣化。Preset ultrafast 编码最快但文件最大，slow 编码最慢但文件最小。根据业务容忍度调整。
监控与告警：FFmpeg退出码非0是致命错误。必须监控 stderr 日志，并设置超时熔断。如果FFmpeg进程挂死，你的队列会堆积，最终雪崩。
格式兼容性：MP4是Web端通吃格式，但H.265 (HEVC) 编码效率更高，文件更小。然而，旧版Safari对HEVC支持不佳。建议输出H.264为主，HEVC为可选高级选项。
最后，关于性能测试：不要只看代码跑通，要做压力测试。用 wrk 或 k6 模拟并发上传，监控CPU、内存、磁盘IO。你会发现，瓶颈往往不在FFmpeg本身，而在磁盘IO或网络带宽。提前规划好存储层，比优化代码更重要。
你在项目里踩过这个坑吗？比如FFmpeg内存泄漏、S3上传断点续传失败，还是WASM在移动端崩溃？评论区聊聊，看看谁踩的坑更深。