Motrix 2.0.0-beta.13 发布全解析多分发渠道门禁、宿主无关下载内核与 MDXP/插件体系【免费下载链接】MotrixA full-featured download manager.项目地址: https://gitcode.com/GitHub_Trending/mo/MotrixMotrix 2.0.0-beta.13 是一次部分成功的跨渠道发布演练5 个桌面构建与 GitHub 预发布、R2 更新源全部完成而 Server 容器在 QEMU 交叉构建环节中断、Snap 按设计跳过。本指南以该版本的官方发布说明为主体结合仓库内发布脚本与核心源码系统讲解这次重建版下载器的分发结果、可靠性门禁、新技术栈Electron 43 / React 19 / TypeScript 7、宿主无关共享下载内核、MDXP 任务交接与 QuickJS 插件沙箱帮助读者理解预发布分发为什么不是原子操作以及 v2 架构相对 v1 的根本性变化。一、版本概览一次多渠道分发的完整复盘Motrix 2.0.0-beta.13 的发布运行整体上完成了桌面渠道5 个桌面构建、3 个 Finalize job、assemble、GitHub 预发布版以及 R2 更新数据源但Server 容器渠道没有完成Snap 则是受保护的预发布 run——它通过了 source validation并按设计跳过架构构建与 Store 发布未上传或发布任何 Snap revisionlatest/edge无变化。这次发布特别强调两点原则渠道独立门禁容器发布是独立门禁的分发渠道桌面成功不代表全渠道原子发布成功因此文档明确说不能把该结果描述为跨分发渠道的原子发布。tag 不可变性v2.0.0-beta.13tag 保持不可变、不会移动或复用未完成的容器发布结果由后续的 2.0.0-beta.14 发布说明 取代。从当前仓库快照看版本线已演进到2.0.0-beta.28见 package.json也印证了tag 只增不移、失败结果由下一版本取代的发布纪律。实际分发结果可汇总为下表发布方式架构结果macOS 12 或更高版本arm64Apple Silicon、x64Intel已发布 DMG 和 ZIPWindowsx64已发布未签名的 NSIS 安装包.exe和 ZIPLinuxx64、arm64已发布 DEB 和 RPMFlatpak Native Host 配套程序linux/x64、linux/arm64GitHub 预发布版已包含Motrix-Native-Host-2.0.0-beta.13-linux-arch.tar.gzDocker Hub / GHCRlinux/amd64、linux/arm64两个 registry 都没有发布2.0.0-beta.13Snap Store—本 beta 未发布原计划的容器引用为docker.io/motrixapp/motrix-server:2.0.0-beta.13和ghcr.io/agalwood/motrix-server:2.0.0-beta.13但两者都不是可用的 beta.13 发布镜像。需要部署 Server 的读者应参考 Docker Server 部署指南另有 英文版选择后续已成功验证的版本。二、桌面应用技术栈重建Electron 43 React 19 TypeScript 7beta.13 所在版本线的最大变化是使用 Electron 43、React 19 和 TypeScript 7 从头重建桌面应用并带来可自定义 Dashboard、深色模式、跨平台应用菜单以及更清晰的任务检查器反馈。在当前仓库的 package.json 中可以直接看到这套栈的落地版本electron: 43.4.0第 98 行typescript: ~7.0.2第 105 行react / react-dom: ^19.2.8第 142–143 行配套 UI 体系还包括base-ui/react、tailwindcss ^4、react-router ^8、zustand ^5、recharts等。与可自定义 Dashboard、深色模式对应的界面层实现集中在 src/renderercomponents、hooks、routes三大目录而仓库e2e测试目录为这些用户可见能力提供了可运行的验收证据e2e/dashboard.spec.ts验证 Dashboard 面板的加载与交互e2e/navigation.spec.ts 与 e2e/application-menu.spec.ts覆盖跨平台导航与应用菜单e2e/activity-tile.spec.ts、e2e/task-inspector-activity.spec.ts对应更清晰的任务检查器反馈中的活动时间线能力。也就是说重建不只是换依赖版本而是连同 UI 行为都用 Playwright Electron 的端到端用例固定下来。三、宿主无关的共享下载内核桌面与 Server 共用一套核心发布说明强调的第二点架构变化是桌面应用和 Node/Web Server 共用与宿主无关的下载内核能力覆盖 SQLite session 恢复、Tracker 管理、UPnP/NAT-PMP以及 HTTP、FTP、BitTorrent 和磁力链接下载。从源码结构看这套宿主无关内核的落点非常清晰引擎抽象层定义在 src/core/engine/engine-adapter.tsEngineAdapter接口把下载引擎收敛为统一的契约——createDownload、addTorrent、pause/resume/removeTask、changeOption、getTaskStatus、getGlobalStats、listActiveAndWaiting、searchHistory、exportSession等还包含引擎中立的恢复策略DownloadResumePolicynone | checkpoint | sequential-prefix见第 33 行。代码注释明确写着Engine-neutral、Concrete adapters translate this product policy说明上层任务管理只依赖抽象不绑定具体引擎。引擎生命周期由 src/core/engine/engine-supervisor.ts 管理包含进程拉起、RPC 连接重试冷启动ENGINE_READY_TIMEOUT_MS 15_000第 51 行、健康检查每 30 秒一次最多 3 次连续失败、最多 5 次重启退避、SQLite 损坏诊断等。aria2 引擎适配实现位于 src/core/engine/aria2其中aria2-process-manager.ts负责子进程托管aria2-config-builder.ts负责把配置生成 aria2 参数aria2-rpc-client.ts/web-socket-transport.ts走 JSON-RPC 与事件推送aria2-sqlite-recovery.ts处理 SQLite 持久化的故障恢复aria2-trust-store.ts则管理可信任的引擎产物。HTTP/FTP/BT/磁力四种下载类型在发布说明中的定位与 engine-adapter.ts 中protocol: http | ftp | sftp | bt | magnet | metalink的协议枚举一一对应。四个附加能力同样能在源码中找到对应模块SQLite session 恢复会话与数据库模块位于 src/core/sessionsession-manager.ts、motrix-database.ts、migrations/BT 种子与任务元数据另有 src/core/task/torrent-meta-store.ts。仓库依赖better-sqlite3 ^13并且在package.json中为 Electron/Node 分别提供了rebuild:for-electron、rebuild:for-node的原生模块重建脚本这正是桌面与 Server 共享内核但各自宿主的工程细节。Tracker 管理完整实现在 src/core/tracker包括tracker-manager.ts、tracker-store.ts、tracker-syncer.ts、tracker-http-client.ts、tracker-prober.ts等并配套独立测试。UPnP/NAT-PMP仓库依赖motrix/nat包主进程侧有 src/core/nat/settings-nat-provider.ts 与 src/main/nat 负责将 NAT 设置接入应用层。宿主无关性桌面主进程入口在 src/main/index.tsNode/Web Server 入口在 src/server/index.ts二者都建立在src/core之上src/server另有自己的task-persistence.ts、runtime-directories.ts、download-path-policy.ts等服务端专用设施。四、统一 MDXP 协议CLI/浏览器任务交接与 device-code 配对发布说明的第三点官方 CLI 和浏览器任务交接统一使用 MDXP并支持本地发现及远程 Server 的 device-code 配对。motrix/mdxp ^0.5.0与motrix/cli ^0.4.0都是本仓库的正式依赖见 package.json。在源码层面协议与配对逻辑集中在 src/core/bridgemdxp-dispatcher.ts、mdxp-session-context.tsMDXP 消息分发与会话上下文管理web-socket-bridge-server.ts与bridge-connection.tsWebSocket 桥接传输与连接生命周期device-code-service.tsdevice-code 生成与轮询校验——这是远程 Server 场景下无密码、短时码配对的实现核心pairing-service.ts、file-pairing-store.ts、trusted-extension-registry.ts本地文件配对、配对记录持久化与受信扩展注册表resolve-cli-pair.ts把 CLI 发起的配对请求解析成可处理的会话。测试侧 src/core/bridge/tests/device-code-mdxp.test.ts 与 device-code-service.test.ts 直接覆盖了 device-code 配对的 MDXP 交互路径。端到端层面e2e/bridge 目录下的cli-pair-and-download.spec.ts、pair-and-submit.spec.ts、revoke.spec.ts、receiver-direct.spec.ts则验证了从 CLI/浏览器扩展配对、任务交接提交到撤销授权的完整链路。此外主进程侧 src/main/bridge 负责桥的生命周期bridge-manager.ts、桌面配对弹窗pairing-dialog-controller.ts与 Native Host 安装/路径解析native-host-path.ts、native-messaging-installer.ts。五、QuickJS 插件沙箱与应用内插件市场发布说明的第四点带能力授权的 QuickJS 插件沙箱、内置插件和应用内插件市场。这标志着 Motrix v2 将插件系统作为一等公民——插件不再是放开手写 JS而是在受限运行时里按声明的能力逐项授权运行。仓库证据非常密集沙箱宿主QuickJS Worker 实现在 src/core/plugin/host/quick-js-worker.ts依赖quickjs-emscripten ^0.32.0见 package.jsonHost 目录下还有bridge-protocol.ts、capability-bridge.ts等负责宿主与沙箱的通信与授权桥接。能力capabilities声明与分发见 src/core/plugin/capabilities其中就包括 crypto.ts插件清单 schema 使用独立的motrix/plugin-manifest-schema ^2.1.0依赖做结构校验。插件注册表、查询、安装与市场逻辑对应 src/core/plugin 下的plugin-registry.ts、queries.ts、registry/、install/、update/、manifest/等子目录服务端同样复用了这套插件运行时见 src/server/plugin与宿主无关内核的设计一致。内建/受信插件的签名防线仓库根目录提供builtins-signing.pub.pem与 src/shared/builtin-signing.ts发布流水线用 scripts/fetch-builtins.mjs 拉取内置插件并校验签名builtins.lock.json锁定具体版本。测试侧有大量端到端用例锁定沙箱边界e2e-builtins.test.ts、e2e-capabilities.test.ts、orchestrator.e2e.test.ts、plugin-call-graph.spec.tse2e 目录以及 tests/integration/community-plugin-install.test.ts后者专门覆盖社区插件安装的集成路径。六、发布可靠性门禁Cosign、Provenance、SBOM 与 fail-closedbeta.13 是发布流水线在可靠性机制上明显加码的一个版本。发布说明列出的核心门禁包括Cosign 签名后的匿名 registry 可见性等待签名后会对匿名 registry 的可见性做有界等待如果任一 registry 始终没有公开有效签名流程仍然fail-closed失败即关闭而不是半信半疑地放行。BuildKit provenance 匹配构建来源provenance必须匹配当前仓库的精确 workflow run以及当前或更早的有效 attempt——防止把跨 run/跨重试的产物误判为本轮结果。跨渠道一致性保留跨 registry 的不可变 digest 一致性、amd64/arm64 镜像与 attestation、SPDX SBOM、精确源码 revision、provenance 完整性以及 runtime smoke 门禁全部保留。Windowsx64未签名发布继续明确采用未签名发布同时保留发布前的最终安装包验证避免不签名就什么都不验。桌面 Finalize 全平台门禁所有桌面目标完成 Finalize 后才能组装且每份规范 updater manifest 都在发布前通过最终验证。这些门禁虽然主要由 CI workflow 编排但每一步在仓库的 scripts 中都有可独立运行的实现与测试可以对照阅读门禁环节仓库实现脚本容器发布验证registry 发布状态、publication 状态scripts/verify-container-publication.mjs、container-publication-state.mjs、container-platform-metadata.mjsServer 镜像 smoke / 测量scripts/smoke-server-image.mjs、scripts/measure-server-images.mjsServer 包构建与验证scripts/stage-server-app.mjs、scripts/verify-server-package.mjs、scripts/smoke-server-package.mjsElectron 桌面包 stage/verify/smokescripts/stage-electron-app.mjs、scripts/verify-electron-package.mjs、scripts/smoke-electron-package.mjs发布产物组装与 AppImage finalizescripts/assemble-release-artifacts.mjs、scripts/finalize-appimage-artifact.mjs更新源 / updater manifest 验证scripts/verify-update-artifacts.mjsSnap artifact 与 Store 渠道验证scripts/verify-snap-artifact.mjs、scripts/verify-snap-store-channel.mjs、scripts/prepare-snap-project.mjs第三方声明与法律产物scripts/generate-third-party-notices.mjs配合 THIRD_PARTY_NOTICES.md这些脚本大多在 tests/scripts 下有同名.test.ts覆盖例如verify-container-publication.test.ts、smoke-server-image.test.ts、verify-update-artifacts.test.ts、verify-snap-store-channel.test.ts说明发布可靠性门禁本身是被测试守卫的代码而不是一次性手工操作。结合 package.json 的build:snap:prepare、check:snap、check:snap-store、check:update-artifacts等命令可以看出仓库把门禁下沉为可反复调用的 npm 脚本供 CI 矩阵逐平台执行。七、未完成渠道的复盘Server 容器与 Snap本次发布最值得技术复盘的是Server 容器渠道为什么失败。发布说明给出了完整因果链容器 job 在 x64 runner 上使用QEMU执行合并 Buildx 构建中的linux/arm64部分ARM 的pnpm install层运行到约 57.27 秒时QEMU 因目标signal 4Illegal instruction退出此后 build action 一直保持运行状态约 33 分钟后容器 job 被取消剩余容器步骤均未执行两个 registryDocker Hub 与 GHCR都没有发布 beta.13 不可变 tag没有签名最终 index也没有完成匿名平台、provenance、SBOM 或 runtime 验证。由此可以提炼出一条工程教训在 x64 runner 上用 QEMU 模拟 arm64 做依赖安装/构建属于慢且脆的路径——一旦二进制指令与模拟器不兼容job 会进入既不失败也不推进的悬挂状态最终只能超时取消。容器发布是独立门禁桌面成功并不能挽救容器渠道这正是文中反复强调非原子发布的原因。Snap 渠道则相反属于按设计的跳过受保护的预发布 Snap run 在 source validation 通过后即停止没有构建或发布 Snap artifact。这与仓库中 Snap 相关脚本prepare / verify-artifact / verify-store-channel体现的预发布阶段先把门禁跑通、正式发布才真正上传的分阶段策略一致。八、已知发布限制一览beta.13 明确列出以下发布限制测试与集成方需提前知晓本 beta未发布 AppImageFlatpak 单独完成验证但没有随该版本 tag 发布GitHub 预发布版包含其 Native Host 配套程序压缩包。配套的 Flatpak 工程文件在 flatpak 目录Native Host 打包脚本为 packages/native-host/package-flatpak-companion.mjs不提供 Windowsarm64和任何 32 位安装包Windows 安装包未签名可能触发 Windows SmartScreen 警告应仅从官方 GitHub 预发布版下载Beta 容器 tag不会更新latest、stable或其他稳定版浮动 tagSnap 未发布预发布 run 在 source validation 后停止。九、测试前须知给 beta 试用者的数据安全建议作为预发布软件发布说明对试用者给出了明确的数据安全指引这里完整保留并补充说明安装前请备份现有 Motrix 应用数据和下载文件Motrixv1 数据的迁移路径尚未经过验证请勿让本 beta 使用你唯一一份 v1 数据条件允许时建议通过独立的系统账户、设备或 Docker 数据目录与现有环境并行测试 v2请勿让本 beta 成为重要下载文件的唯一存储位置。结合 README.zh-CN.md 与 docker-server.zh-CN.md 可知v2 的 session 落在 SQLite 数据库中见 src/core/session/motrix-database.ts应用数据目录与 v1 并不互认——这也是迁移路径未验证风险的来源。用独立数据目录并行测试是最稳妥的隔离方式。十、反馈渠道遇到可复现的问题时应通过仓库官方 GitHub Issues 反馈并在报告中附上操作系统、架构、安装包类型与复现步骤。仓库内的 CONTRIBUTING.zh-CN.md、SECURITY.zh-CN.md 也分别说明了贡献规范与安全问题的上报边界可作为提交反馈前的补充参考。小结Motrix 2.0.0-beta.13 的价值不在于发布全部成功而在于它把一个多分发渠道预发布流程的成功与失败都透明地记录了下来桌面端完成了 Electron 43 / React 19 / TypeScript 7 全栈重建并用 e2e 用例守住了 Dashboard、菜单与任务检查器等用户界面行为下载能力收敛为宿主无关的src/core内核桌面主进程与 Node/Web Server 共享同一套引擎抽象engine-adapter.ts与 SQLite 会话/Tracker/NAT 等基础模块任务交接统一走 MDXP含 device-code 配对插件运行在带能力授权的 QuickJS 沙箱内内置插件与应用内市场机制完整落地发布侧引入 Cosign 可见性有界等待、provenance/workflow-run 精确匹配、digest 一致性、SPDX SBOM、runtime smoke、桌面 Finalize 门禁等一系列宁可 fail-closed 也不带病发布的可靠性机制并把它们实现为仓库 scripts 中可独立测试的命令。对于正在评估 v2 路线或搭建自有发布流水线的读者建议重点研读 scripts 目录下与本文表格对应的验证脚本、package.json 中的命令编排以及 2.0.0-beta.14 发布说明 中容器渠道的后续进展以完整理解该版本线的演进脉络。【免费下载链接】MotrixA full-featured download manager.项目地址: https://gitcode.com/GitHub_Trending/mo/Motrix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
