更新日志
由发布说明本身生成 —— 每条都链到对应的发布页，完整正文与文件都在那里。
发布台账
每次发布、日期、附件数、是否预发布。这里没有一处是手写摘要 —— 这张表与下载页渲染的是同一份数据。
releases.json
由 website/refresh_releases.py 从 GitHub API 抓取后提交进仓库 —— 站点运行时不会去调 API。
按体量排
按附件数排的前六次发布。这里突然多出来，通常意味着构建里新加了一个产物。
v0.4.1.0
2026-11-03
TurboDL 0.4.1.0 —— 工业级可靠性 + 高并发真正增益 这一版继续修正确性与高并发缺陷，并把“线程数”从显示值改成真实吞吐能力。 【正确性】 HTTP 416 不再把未完成分片标记成功；瞬时 416 会重试，持续 416 会给出明确失败原因。 动态尾段侧车按顺序持久化并校验完整覆盖；残缺快照不会覆盖最后一次有效进度。 镜像终址缓存按“任务 + 原始来源”双键隔离；跨源镜像和跨 origin 302 不继承 Cookie、Authorization、API key，Proxy-Authorization 仍只给代理层。 任务事件改为单消费者有序转发；MERGING、COMPLETED、FAILED 都有明确 StateChanged 再发终态，宿主不会先收到完成、后收到状态。 暂停清理不再覆盖已经完成、失败或取消的终态。 DownloadRequest…
20 个文件 · 发布页
v0.4.0.0
2026-11-01
TurboDL 0.4.0.0 —— 正确性大修 + 多镜像来源 这一版以修 bug 为主：内部审计翻出 13 个真实缺陷，其中 3 个会让输出文件静默损坏。 【P0：会造成静默数据损坏】 1. 续传取证：强校验器已变、但内容指纹取不到时，不再复用旧分片（否则会拼出新旧混合、长度校验却通过的文件）。 2. 整文件回退：写入前强制截断目标文件（旧文件尾部不再被保留；窗口下 delete() 失败也不影响）。 3. 进度侧车：persist 串行化 + 完整网格校验 + reset 同时清理 .tmp/.bak（并发写不再产生混合快照）。 【P1：真实会踩到的坑】 4. 「全局限速」现在是全进程一个令牌桶（之前是每任务一个，3 任务 = 3 倍）。 5. resume() 暂停时完成 Deferred、失败时落 FAILED（之前 await() 会永久挂起）。 6. 背压可以降到 1 路（服…
20 个文件 · 发布页
v0.3.1.0
2026-10-31
TurboDL 0.3.1.0 核心更新： 1. 自适应并发控制全面增强：新增 AdaptiveConcurrencyMode.DOWNWARD（默认），先以用户设定最高并发立即起跑拉满速度，在网络稳态后向下探求最小无损连接数；保留 UPWARD 模式供低并发上探场景使用。 2. 调度器性能与并发拉升重做：移除并发调度停滞，首段与后续分片立即喂饱多连接，杜绝小文件（如 30MB）连接数上不去的缺陷。 3. 完整性校验：支持 expectedSha256 流式哈希计算与校验，校验失败自动清理不可信侧车。 4. 宿主控制下放：开放慢启动错峰与初始并发策略，满足宿主应用与网盘场景多样化并发需求。 5. 包含 6 个核心模块完整 Maven 依赖包、全量 CLI 工具与 mavenLocal 离线压缩包（共 20 项产物）。
20 个文件 · 发布页
v0.3.0.0
2026-10-31
TurboDL 0.3.0.0 是继 0.2.8.0 自适应并发之后的一次完整性/资源重做。 核心变化 全局连接预算 maxTotalConnections，多任务共享连接上限，任务结束/暂停/失败按预算归还。 任务槽改为 Mutex + FIFO，配置调大后立即唤醒排队任务，不再并发穿透。 侧车进度改为“主文件 + .bak”替换；主文件损坏时可回退恢复。 修复目标文件被删除后旧分片复活、收尾托管边界写入、预热误读整文件、暂停后 await 旧结果、完成 Job 泄漏等隐性缺陷。 收尾托管按 ETA 选择慢分片；重试退避加入 ±25% 抖动；JVM 使用直接 ByteBuffer，Android/Dalvik 自动回落堆缓冲。 固定并发启动不再被慢启动的错峰延时拖住，明确请求高并发时会立即启动 worker。 验证 199 个核心测试全绿。 …
20 个文件 · 发布页
v0.2.8.0
2026-10-30
核心变化 连接数现在是吞吐上限，不再一开跑就强制打满。引擎从 8 路开始，只有聚合吞吐再提升至少 30% 才翻倍加档，遇到平台期退回最后有效档并保持。 每连接独立限速的下载源会继续从 8 扩到 16、32、64、128、256；服务端存在聚合封顶时则自动收敛，避免“线程越多反而越慢”。 worker 协程和分片网格都随实际并发懒创建。请求 256 路但只需 8 路时，不再创建 256 个空转协程或上千个无效小分片。 并行写入前一次性预留目标文件的逻辑长度，避免 128/256 条连接反复争抢 NTFS 扩容元数据锁。 新增独立进程并发矩阵基准工具、Python/Node 限速测试服务器，以及 scheduler 调试开关。 实测 6.4MB 回环单测：约 229ms → 154–170ms，约 1.35 倍。 本地无限速 64MB：8、16、32、64、…
20 个文件 · 发布页
v0.2.7.0
2026-10-28
修复 某条连接耗尽重试后，被顺带中断的其他连接不再计入自己的重试次数。此前几次连带会让一批正常连接一起被判定失败，整个任务随之失败。 失败提示改为指向真正出错那条连接的原因。此前显示的可能只是其他连接留下的信息，与实际原因无关。 已完成的数据始终保留在目标文件中，任务失败后再次启动即可接着下载。 优化 连接失效的判定时间由 60 秒缩短为 30 秒。 连接失效判定仅对"已收到数据后停止推进"的连接生效，仍在排队等待服务器的连接不会被误判。 继续下载时直接按设定连接数开始，不再从 4 条逐步增加。 域名解析结果增加短时缓存，减少重复解析的等待。 服务器在响应中给出重试等待时间时，按其指定时间重试。 移除 移除"预先合并"与"分片写缓冲"两个开关，对应机制在当前写入方式下已不存在。 从 0.2.4.0 升级时的累计变化 分片直接写入目标文件的对应位置，不…
19 个文件 · 发布页
v0.2.6.0
2026-10-28
在 0.2.5.0「分片直写」的基础上继续收口。这一版的所有改动都是拿 aria2 1.37 当场对比测出来的，不是凭感觉调。 基准方法 本地起一个支持 Range、可按连接限速的 HTTP 服务器，让两个引擎跑同一个文件、同一台机器、同样的连接数。 aria2 的 -x 上限是 16，所以公平对比取 16 连接。 改了什么 1. 每写入线程独立的 FileChannel 一开始所有分片共用一个通道做位置写。打点发现：每条连接累计"读"只用 3~13ms，而"写"要 87~318ms —— 写入比读取慢二三十倍，且 16 条连接的写入串行排队（单连接 106 MB/s，聚合仍然 106 MB/s）。 位置写本身是允许并发的，是共用同一个通道句柄把并发吃掉了。改成每线程一个通道后，写入耗时降到 18~98ms。 2. DNS 带 TTL 的缓存 原…
19 个文件 · 发布页
v0.2.5.0
2026-10-28
一次结构性的吞吐改造。不是调参，是换掉了分片落盘的方式。 原来的瓶颈 每个分片写一个临时文件 seg_x_y.part，全部下完再由 PartMerger 顺序拼进目标文件。 问题不在合并，而在创建文件本身。同一块盘、同样 16MB 数据、去掉 fsync 的公平条件下： | 分片数 | 分片文件 创建+写 | 收尾合并 | 合计 | 按偏移直写一个文件 | |---|---|---|---|---| | 64 | 148 ms | 28 ms | 176 ms | 9 ms | | 128 | 178 ms | 43 ms | 221 ms | 9 ms | | 512 | 627 ms | 101 ms | 728 ms | 11 ms | 512 片时旧结构把 16MB 写成 25 MB/s，直写是 1454 MB/s…
19 个文件 · 发布页
v0.2.4.0
2026-10-26
新增一个可选模块 turbo-plugin-parser：视频/社交平台分享链接解析，做成引擎级原生插件，与 turbo-plugin-hls 同一套机制。 它做什么 把一条分享链接变成可下载的请求： | 平台 | 产出 | |---|---| | 微博 | 最高可用清晰度 MP4 + 图集原图 | | 小红书 | 无水印视频 + 原图 | | Pixiv | 每一页的 urls.original 原图 | 它只往 LINK_PARSER 注册一个解析器、往 PROTOCOL_HANDLER 每个平台声明一条。turbodl-core 与 turbo-plugin-runtime 一行未改 —— 引擎内核对这三个平台一无所知。 为什么这样切 LinkParser.parse 必须返回 DownloadRequest，而 `Down…
19 个文件 · 发布页
v0.2.3.1
2026-10-23
修三个只在同时启用两个开关时才发作的缺陷。这类问题在设置界面里很容易被用户踩到。 1. 预先合并 + 收尾托管 = 写坏文件 收尾托管把分片 [A,B] 缩成 [A,M] 并新建 [M+1,B]；预先合并又把已完成分片直接写进目标文件。若原分片在托管生效前已写过 M 之后，它的数据会盖到接管分片的区间上——两段内容来自不同请求（可能命中不同 CDN 节点），谁后写谁赢。 表现：长度正确、SHA-256 不符。 长度校验拦不住，损坏会静默落地。 TurboConfig 的注释里一直记着这个缺陷，但代码层面从来没有互斥检查——只判断了 overlapMerge 自己。现在托管优先：只要 tailAssist 开着就禁用预先合并。理由是收益不对等——托管消除的是收尾长尾（可能几十秒），预先合并省的是 6% 的合并 I/O。 2. 选 AUTO 反而变成强制…
16 个文件 · 发布页
v0.2.3.0
2026-10-20
这一版修什么 三处让引擎"要么完全下不了、要么看起来卡死"的网络缺陷，都在真实链路上复现过，都有回归测试。 1. UA 被拦导致零字节失败 国内镜像站按 UA 分档：浏览器 UA 被拦（403 + HTML），curl 类放行。而默认 UA 是浏览器 UA， 于是默认配置在这些站上一个字节都下不了，curl 跑同一链接却飞快。 现在探测阶段会协商：只在拿到 HTML/401/403 时换 UA，依次试 curl/x、aria2/x， 协商成功后该任务所有分片都用这个 UA。用户自己指定过 UA 则永不覆盖； 超时/5xx 不触发协商（那换 UA 也没用，只会白打请求）。 2. 失败判定被串行化（看起来像卡死） 某个分片耗尽重试预算时只记了失败原因，但 worker 的退出条件里没有它。 其余分片继续各自走完指数退避，于是失败判定被串行处理： 2 MiB / 16 个…
17 个文件 · 发布页
v0.2.2.0
2026-10-11
TurboDL 0.2.2.0 这一版主要是修了一个会让「继续下载」完全没反应的缺陷，另外补上原生插件（L2）的加载契约和文件处理器挂载点。 修复：暂停后点「继续」没有任何反应 resume() 原来在协程内部移除并等待旧任务结束，而 jobs.putIfAbsent 是紧接着同步执行的。那个协程此时还没被调度，旧任务仍在表里，于是 resume 认为「已经有任务在跑」，返回失败并取消刚创建的协程。结果是用户点了继续，任务永远不会到达完成或失败状态。 现在改成同步等待旧任务结束后再启动新任务。端到端测试覆盖了这条路径：暂停、等待、继续，然后校验最终文件逐字节正确。 新增 原生插件（L2）的加载契约：定义插件来源、加载器接口与加载失败分类。引擎侧只定义契约，实际的类加载由宿主实现——引擎是纯 JVM 库，不包含 Android 的 dex 机制。 文件处理器挂…
16 个文件 · 发布页
v0.4.1.0 里发了什么
最新一次发布，逐个文件列出来。大小就是 API 给的数字。
v0.4.1.0 · 附件
与下载页列的是同一份清单，来自同一次 API 响应。
这一页是怎么来的
整站没有任何手写的版本号、日期或文件名。