台账 P21 第 2 条 + P19(b)：分块路径此前进来先 `part.discard()`、失败也 `discard()`， 188MB 的 JDK 任何一次失败都从 0 重下；M289 又给预算耗尽加了「不再重试、不再换源」的 短路，慢链路上一次晚到的失败就变成「这个文件下不来」。 写这一侧： * `ResumeMeta` 新增 `chunks: Option<Vec<ChunkRecord>>`（段区间 + 该段 SHA-1）， 由新增的 `chunk_resume::ChunkJournal` 每成功回收一段就原子落一次盘； * `fetch_chunk` 顺带带回段摘要、`Content-Range` 总长与 ETag/Last-Modified， 所以元数据里同时有 total / 源 URL / 分块清单 / 校验所需信息； * 分块失败不再丢中间文件，只有 `RangeUnsupported`（单连接接不住这种形状）才丢。 判这一侧： * `chunk_resume::decide`（纯函数）要求策略允许、URL / 总长 / 摘要 / 校验器全对得上， 且每条记录精确命中本次分块规划里的一段，否则从头再来； * `chunk_resume::verify_records` 按记录重读旧段、重算摘要：任何一段对不上就整份丢掉 （元数据本身已不可信，同批其它记录也不再被信任）； * 续传的段请求带 `If-Range`，让服务器回答「内容变了没有」； * 整文件摘要照旧在末尾整份重算，覆盖新下 + 复用的全部字节。 单连接路径零改动：`resume::decide` 的判定一字未动，只新增 「元数据里带分块清单 ⇒ 强行判 Restart 交给分块路径」这一条，避免预分配全长文件被 单连接的 `Complete` 误判成「已下满」。 判据（都是「服务端实际吐了多少字节」，不是「最终 hash 对」）： * 3/4 处失败后续传完成：41984 字节 / 40960 文件 = 1.025×（断言 < 1.5×）； * 变异（关掉续传同样夹具）：72704 = 1.775×，`< 1.5×` 必红（已实测）； * 变异（去掉旧段摘要自证）：坏段被复用 ⇒ 51200 ≠ 40960 必红（已实测）； * 变异（去掉总长比较）：旧大小的段被复用 ⇒ 61440 ≠ 40960 必红（已实测）。
Rust 原生单文件 Minecraft 启动器：CLI 完整可用（install/launch/accounts/java/diagnose/agent）， MCP server 接入外部 Agent 工具，GUI 开发中。
AskaEth
AskaEth
AskaEth
AskaEth