lux 实测：6 线程下载快 3.9 倍，8 线程反而慢｜实测库

lux 是 Go 写的视频下载器，一个 23003648 字节的 exe 顶掉一堆工具：给一个网页链接，它解析出可用的清晰度，再连音频一起下下来。

拿一个 9896267 字节的测试文件做限速实测：每条连接限在 3.1 MB/s，单线程 3.0 秒下完，开 6 线程 600 毫秒——但开到 8 线程又掉回 1.6 秒。这里面有个参数必须先搞清楚，不然线程数白设。

21.9 MB 单文件，解析只要 0.18 秒

lux --version
lux: version 0.24.1, A fast and simple video downloader.

lux -i https://example.com/video
 Site:      example
 Title:     test landscape clip
 Type:      video/mp4
 Streams:   # All available quality
     [default]  -------------------
     Quality:         default
     Size:            9.44 MiB (9896267 Bytes)
     # download with: lux -f default ...

-i 只解析不下载，输出里带着站点名、标题、MIME 类型和每一档清晰度的大小。0.184 秒这个速度说明解析走的是页面的结构化数据，不是把视频预读一遍。

不加 -m，-n 完全不生效

这是用之前必须知道的一条。lux 有两个看起来相关的参数：

--multi-thread, -m    Multiple threads to download single video (default: false)
--thread, -n          The number of download thread (only works for multiple-parts video) (default: 10)

-n 只负责设线程数，真正的开关是 -m，而且它默认是关的。-n 的说明里那句「only works for multiple-parts video」也容易误导——普通 mp4 加上 -m 一样会分段。

实测验证过：只传 -n 1、-n 4、-n 8，三次耗时分别是 3.22、3.21、3.27 秒，几乎一模一样。加上 -m 之后差异才出来。

六线程最快，八线程掉回两线程的水平

6 线程是峰值。同一个命令跑两遍，6 线程一次是 16.47 MiB/s、800 毫秒，另一次是 25.18 MiB/s、600 毫秒，绝对值浮动不小；但 8 线程两次都掉到 6.77 MiB/s 上下，和 2 线程一个水平，这个趋势是稳定的。

原因在服务端：这台测试服务器用多线程响应每个 Range 请求，连开 8 个线程时线程调度开销盖过了并行收益，反而互相拖慢。换到能扛并发的 CDN 上，拐点会往后挪，但「不是线程越多越快」这条规律不变。

下载中断是什么样

多线程下载时如果服务端先断开，控制台会看到连接被重置，整个任务停下来而不是静默少一段：

ConnectionResetError: [WinError 10054] 远程主机强迫关闭了一个现有的连接

lux 默认重试 10 次（--retry 可调）。这个设计对分片下载很重要：几百个分片里断一两个是常事，不重试就会得到一个时长不对的文件，而且不看日志发现不了。

另一个边界是线程数大于分片数。视频只有 3 个分片时给 -n 8，多出来的线程直接空转，不会有任何加速。

还有一个很容易撞上的：-o 指定的目录必须已经存在，lux 不会自己建。第一次跑会直接失败：

CreateFile D://out//s2: The system cannot find the file specified.

目录建好之后同一条命令就能跑通，不带任何提示，看起来像是「有时能下有时不能」。

它和通用下载器的分工

lux 的价值在「解析」这一步：给它一个视频页地址，它自己找出真实的媒体流，不用手动翻开发者工具。这一点是 curl、aria2 这类通用下载器做不到的。

反过来，如果手上已经是直链，aria2 的分片和断点续传更成熟。lux 能做到 11.31 MB/s，aria2 在同一条链路上也不会差，但少一次解析。

它的定位是「一次性把网页上的视频拿到本地」：命令短、不用配置、跨平台单文件。要批量订阅、定时下载，那是另一类工具的事。