树莓派跑了个 M3U8 下载服务，内存从 600MB 降到 2MB
树莓派跑了个 M3U8 下载服务，内存从 600MB 降到 2MB
最近在树莓派上跑了个 M3U8 下载服务，用 Rust 写的。跑了一周发现内存涨到 237MB，峰值冲到过 607MB，差点把树莓派撑死。
先说说这个服务是干嘛的。就是提供一个 Web 页面，贴个 M3U8 链接进去，服务端下载完转成 MP4。用油猴脚本配合的话，浏览视频网站时点一下就把链接发给服务器了，不用在自己电脑上下载。
问题的根源
查了两天代码，发现三个要命的地方：
1. 直传模式的内存泄漏
服务有个"直传"功能，下载的同时通过浏览器传回给用户。代码里用了一个 BTreeMap 缓存乱序到达的视频片段，但没有任何大小限制。如果片段 0 下载慢了，后面 139 个片段全堆在内存里。一个片段 2-5MB，堆 100 多个就是 300-700MB。
修复很简单，加了个 max_buffered 上限，超出就 sleep 等待消费掉再继续：
let max_buffered = self.concurrent.saturating_mul(2).max(8);
if buffer.len() >= max_buffered {
tokio::time::sleep(Duration::from_millis(100)).await;
}
2. 回调风暴
每下载完一个片段就触发一次进度更新，每次更新都 spawn 一个异步任务。140 个片段 × 20 次更新 = 2800 个短暂任务，调度开销全变成了堆碎片。
改成 250ms 节流：用 AtomicU64 记录上次更新时间，间隔不足就跳过。
3. 合并时整段读入内存
下载完成后合并片段时，每个片段都 read_to_end 读到 Vec 里再写出去，大片段一把就吃掉 10MB。
改成 tokio::io::copy 流式拷贝，64KB 缓冲区搞定。
修完后的效果
改了之后重启，空载时常驻内存从 237MB 掉到 1MB：
# 优化前（跑了一周）
sudo systemctl status down
Memory: 237.6M (peak: 607.9M)
# 优化后（刚启动，空载）
sudo systemctl status down
Memory: 1.0M (peak: 1.7M)
跑了几个下载任务之后再测，1.5 小时常驻 146MB，峰值 273MB——比起旧版同期数据（启动就 200M+，跑着跑着奔 607M）已经稳定太多了：
# 优化后（1.5 小时，跑过多次下载任务）
sudo systemctl status down
Memory: 146.2M (peak: 273.3M)
再也不用担心树莓派 OOM 了。
另外还加了个 Content-Type 检查：有些 M3U8 链接过期后服务器返回 HTML 错误页，以前要重试 4 次等 15 秒才报错，现在 1 秒内快速失败。
用到的技术栈
- Rust + axum（Web 框架）
- tokio（异步运行时）
- reqwest（HTTP 客户端）
- m3u8-rs（M3U8 解析）
- FFmpeg（TS 转 MP4）
代码放 GitHub 了：https://github.com/Sunrisies/m3u8_download
感兴趣的可以 clone 下来，cargo build --release 编出来 5MB，scp 到树莓派上就能跑。依赖就一个 FFmpeg（用来合并转码），其他全静态编译。