在 Firefox 中让大文件下载可续传
Firefox 在大文件续传方面长期不可靠，引发了不少抱怨；有些用户转而使用手动文件技巧或 aria2、wget、JDownloader 以及 2000 年代的经典下载管理器等外部工具。评论者认为，尽管专用下载软件在故障容忍下载方面已有几十年成熟经验，现代浏览器在中断传输处理上仍然表现很差——尤其是在不稳定或高延迟连接上。大家也怀疑简单的配置调优并不能真正解决问题，并进一步抱怨浏览器开发往往把 UI 润色放在了比鲁棒的容错下载更高的优先级。
Firefox 下载可靠性与相关错误
- 许多评论者表示，Firefox 的可续传下载长期不稳定，有时可以追溯到 2000 年代中期；也有人说自己通常都能顺利续传下载。
- 有人建议系统性复现问题并查看源代码，但也有人指出很难知道该从哪里入手。
- 还提到了一些其他 Firefox 问题：损坏的“模态”搜索高亮，“Whole Words”与“Match Diacritics”之间别扭的行为，通过 service workers 的下载会在恰好 30 秒时取消，以及在 CPU 负载下的界面冻结。
变通方法与外部下载工具
- 许多人强烈倾向于完全绕过浏览器来下载大文件：
aria2、wget -c、curl、axel、JDownloader、IDM/NDM，以及历史上的工具如 GetRight、Go!Zilla、FlashGet、DownThemAll 等。 - 提到的优点包括：稳健的续传、多连接、更好地处理不稳定网络、与 cookie 集成（例如
--load-cookies、浏览器扩展），以及持久化下载。 - 缺点是：一些工具被认为臃肿、缓慢或“可疑”（捆绑软件、非开源组件），而且在涉及登录、验证码或等待计时器时也不容易使用。
一次性 URL 与续传语义
- 文中描述了一种手动技巧：重新开始一次下载以获得新的
.part文件，把旧的部分文件替换进去，然后继续续传。 - 需要注意的是：如果服务器现在提供的是不同的文件，Firefox 会把不匹配的内容拼接在一起，悄悄破坏结果；如果可用，建议使用哈希值。
- 讨论指出，一次性 URL 在重复使用时返回 410/400，使得在浏览器内实现稳健续传变得困难，因为浏览器无法知道两个 URL 是否代表同一个文件。
网络条件与工程优先级
- 一些评论认为，浏览器工程师默认面向的是快速、稳定的连接和性能强劲的机器，而忽视了高延迟、抖动大或供电不可靠的用户。
- 讨论中举了跨境链路、农村连接和特定 ISP 的例子；这被视为一种社会经济层面的盲点。
关于配置修复与正确性的争论
- 有评论者称调整
network.http.response.timeout有帮助；另一位则反驳说这只是“安慰剂”，并引用了 Firefox 代码路径：在启用 TCP keepalive 时该偏好会被忽略，而且只在第一个字节到达之前生效。 - 还指出，Firefox 除此之外不会进行隐藏重试。
更广泛的浏览器与 AI 评论
- 有人不满浏览器在经典下载管理器早已解决下载问题的几十年后，仍然在下载上“挣扎”；一些人认为浏览器团队更重视视觉润色（圆角、极简 chrome）而不是鲁棒性。
- 还提到了专用下载管理器和一个在下载处理上更好的新浏览器项目作为替代方案。
- 这里还有关于对 LLM 使用的敌意，以及用 AI 来克隆或重新实现下载工具的元讨论，同时也提出了依赖 AI 生成代码带来的安全担忧。