更新日志
由发布说明本身生成 —— 应用内的「检查更新」读的是同一份数据，所以两处看到的版本与内容永远一致。
发布台账
每次发布、日期、附件数与预发布标记。这里没有一处是手写摘要 ——与下载页渲染的是同一份数据。
全部字段由 GitHub API 读取，与下载直链同源
这里突然多出来，通常意味着构建里新加了一个产物
改脚本不升版本号的话，用户永远收不到更新 —— 判据是版本号
改了东西就必须升版本号 —— 这是本项目的硬规则，不是建议
v2.7.23
2026-11-03 · 5 个附件
云取 YunGet 2.7.23 —— TurboDL 0.4.1.0 可靠性修复 + ABI 分包 这一版是下一版客户端更新，不会改变已经安装的 2.7.22；请安装本版获得新引擎与修复。 【更新兼容】 旧版 2.7.22 更新器只会取 Release 中第一个 APK。 本 Release 的第一个 APK 固定为 universal 包，确保旧版用户能先升级到 2.7.23；2.7.23 起才按设备 ABI 选择分架构包。 后续版本也必须保留 universal 包，不能只发三个分架构包。 【ABI 分包】 universal：33.1MB，兼容所有设备与旧版更新桥。 arm64-v8a：31.9MB，主流 Android 设备。 armeabi-v7a：23.7MB，32 位 ARM 设备。 x86_64：23.8MB，模拟器与 x86_64 设备。 …
v2.7.22
2026-10-31 · 1 个附件
云取 YunGet 2.7.22 更新日志： 1. 同步 TurboDL 0.3.1.0 核心引擎： 默认开启 AdaptiveConcurrencyMode.DOWNWARD，先以用户配置线程数满速起跑，平稳后自动按需收敛多余连接，彻底消除小文件启动速度慢的缺陷； 修复多任务调度与并发分片供给逻辑。 2. 修复分享解析与目标文件续传边缘情况。 3. 纯净 Android 端发布，保持单一框架演进。
v2.7.21
2026-10-31 · 1 个附件
云取 YunGet 2.7.21 把 Android 端内嵌引擎同步到 TurboDL 0.3.0.0。 下载引擎 同步 0.3.0.0 的调度与资源预算重做：公平任务槽、全局连接预算接口、懒启动 worker、动态分片供给。 修复目标文件被删除后旧进度复活、收尾托管越界写入、预热误读整文件、暂停后 await 旧结果、暂停/取消竞态、完成 Job 泄漏等隐性缺陷。 桌面 JVM 使用直接 ByteBuffer；Android/Dalvik 自动回落堆缓冲，手机端内存策略不放宽。 手机端现有 UI、默认线程数与下载行为不变；全局连接预算暂未在设置页暴露。 验证 :app:assembleRelease 成功。 :app:verifyApkVersion 通过：versionCode 69 / versionName 2.7.21。 `:app:tes…
v2.7.20
2026-10-29 · 1 个附件
修复 带提取码的分享解析失败：页面参数里自带一个空的提取码占位（kd 为 0），旧逻辑看到"页面里已经有这个字段"就不再覆盖，把空值提交给服务端，服务端返回"密码错误"。即使用户填对了提取码也进不去。现在只要提供了提取码，就以用户输入的为准。 文件夹分享的识别：新版分享页没有旧版的分页标记，会被当成单文件分享，结果列表为空。现在同时按分享 id 的前缀（文件夹以 b 开头）判断。 验证 用真实公开分享链接实测：无提取码的文件分享与带提取码的文件分享都能正常解析、取直链并完整下载（分别为 875 字节与 166789 字节，字节数一致）。
v2.7.19
2026-10-29 · 1 个附件
修复 连接失效后的等待时间没有按上一版说明生效：应用侧的默认值仍是 60 秒，覆盖了引擎改成 30 秒的新默认值。现在应用默认值与引擎一致。 这一组默认值原来在设置项、设置页"恢复默认"、以及测试里各写了一份，改引擎时三处不会一起动。现在只有一处来源，测试直接与引擎默认值比对，下次再漂移会立刻被测出来。 说明 已手动改过"读超时"的用户仍保留自己的设置，不受影响。
v2.7.18
2026-10-29 · 1 个附件
修复 个人网盘下载文件和文件夹时，取链接前漏掉了一步"提交提取码"，服务端因此返回"请输入密码"，界面上却显示成"提取码错误"——而用户根本没有输入过提取码。现在会按浏览器的方式先提交提取码再取链接。 分享链接里自带提取码时（链接末尾带 pwd 参数），现在会识别出来。此前这一步被丢掉，只能按"无提取码"流程取链接，必然失败。 只提交过一次提取码却被拒绝时才提示"提取码错误"；没有提交过提取码则提示"该分享需要提取码，请填写后重试"，不再一律说成提取码错误。 分享文件夹翻页被拒绝或触发限流时，保留已经加载出来的文件，不再把整个列表判为失败（2.7.17 已包含）。 测试 新增一条用例，覆盖"分享页是否停在提取码表单"的判定。该判定是解锁流程的入口。
v2.7.17
2026-10-28 · 1 个附件
修复 修正网盘分享文件夹的翻页请求。分享页已经解锁后，翻页时再带一次提取码会被判为"密码错误"，现在会先去掉提取码重试。 已经加载出文件列表后，如果后续翻页被拒绝或触发限流，保留已加载的内容，不再把整个列表判为失败并弹出"提取码错误"。 打开分享的第一页就失败时，仍会给出对应原因：提取码错误、请求过于频繁、或解析失败。
v2.7.16
2026-10-28 · 1 个附件
本次更新含引擎自 0.2.4.0 以来的全部变化，以下按用户能感知的部分列出。 下载速度 分片改为直接写入目标文件的对应位置，不再为每个分片创建临时文件、下完再合并。同一块盘、16MB 数据实测：512 个分片时，旧方式创建文件加合并需 728 毫秒，直接写只需 11 毫秒；高并发下吞吐由 20 MB/s 提升到 88 MB/s，且不再随连接数增加而下降。 每条连接使用独立的写入通道。此前所有连接共用一个通道，16 条连接同时写入会排队，聚合速度被压在单条连接的水平。 增加域名解析缓存，避免几十条连接各自重复解析、在建立连接阶段白等。解析失败的结果也会短暂缓存，防止大量连接同时打满解析。 提升启动爬升速度：每档间隔由 250 毫秒缩短为 100 毫秒，从 4 条爬到设定连接数由 500 毫秒降到 200 毫秒。 实测：本机 256MB、16 连接为 165–200 MB…
v2.7.14
2026-10-27 · 1 个附件
账号管理页现在能加账号了 上一版把多账号做了，但账号管理页只能看、切换、删除，加不了新号 —— 想再加一个账号得退回「网盘」页重新点那个平台，而那里已经登录过的平台 显示的是「已登录」，看不出再点一次是新增还是覆盖。 现在这一页每张平台卡片下面都有「添加账号」；没登录过的平台也列在 「其他平台」里，点一下就能登。登录页那个「保存为新增账号」开关照常在。 网站 版本信息不再滞后：站点上的内置引擎版本、最低安卓版本改为从构建配置读取 修复文档页在桌面端把目录和正文的列宽弄反了（正文被压成 300px 宽） 修复移动端横向溢出：宽表格、长 URL、长代码行、卡片网格
v2.7.13
2026-10-26 · 1 个附件
视频链接解析改为插件 微博、小红书、Pixiv 的分享链接解析，从程序内置挪到了下载引擎的插件里。 这对你意味着什么：这三个平台的页面结构以后再变，修复跟着引擎升级走，不用等应用发版。引擎本身对这三个平台一无所知——它只认「把链接变成可下载请求」这件事，具体是哪个平台由插件负责。 对你没有任何操作要求：功能、界面、行为都不变，链接照样粘进解析页就行。内置的抖音、快手、B站、AcFun 解析器保持原样，它们的签名算法和网页交互比较特殊，暂时还留在应用侧。 多账号 新增「账号管理」页，一个平台登录几个账号都能看 登录时可以选择「加为新账号」还是「覆盖当前账号」 可切换主账号、可给账号加备注、可删除（删掉主账号会自动提拔另一个） 夸克、UC 等平台的取链会优先用刚刷新过的主账号，避免直链签名过期 其他 内置下载引擎升级至 TurboDL 0.2.4.0…
v2.7.12
2026-10-23 · 1 个附件
重要修复 修正两个开关同时打开时，下载完成的文件可能是坏的 「下载中预先合并」和「收尾托管」是引擎高级参数里的两项。两者同时开启时，同一个文件区间会被两个不同的请求先后写入。如果两个请求恰好落到不同服务器，后写的内容会覆盖先写的。 表现是：文件大小正确，但内容损坏，且下载过程中不会报任何错。 现在只要「收尾托管」开着，就会自动停用「预先合并」。 修正「HTTP 版本策略」选“自动”却实际走 HTTP/2 「HTTP 版本策略」默认就是“自动”，因此程序无法区分“你明确选了自动”和“你没设置过”。它只能用另一个开关——「强制 HTTP/1.1」——来决定，结果是你把这个开关关掉后，策略显示“自动”，实际生效的却是“允许 HTTP/2”。 HTTP/2 会把多个分片挤进同一条连接，多线程反而可能完全没有加速。 现在“自动”就是自动，不再被其他开关…
v2.7.11
2026-10-23 · 1 个附件
云取 YunGet 2.7.11 这一版把内置下载引擎真正升级到了 0.2.3.0，并把它的可调项补齐。 引擎其实一直没升上去 TurboDL 0.2.3.0 做得是网络健壮性：UA 协商、失败快速收敛、错误归因。但那次发版只上传了 CLI 包，引擎核心和四个插件模块虽然编译出来了却没发布。 结果就是 App 里声明的依赖一直解析到 0.2.2.0——那三项改进在手机上一次都没生效过。 这次把缺失的制品补齐并发了出去，依赖也真的指过去了。 顺带修掉一处死代码 0.2.3.0 让分片层记录了"真实失败原因"（服务器返回了哪个 HTTP 状态码、连接是不是被重置、body 是不是只回了一半），因为只有分片层拿得到响应信息。但它发失败事件时用的还是异常自带的 message，而那句在往上冒的过程中已经退化成"failed to connect"之类。 所以那个精心做的错误归因，从来没有人…