pro1能成功吗
使用的网络：
这个信息提供下，网络运营商和城市
这是一份针对萌卡平台（Mycard）Windows端下载卡死 Bug 的技术调试报告，旨在帮助开发团队定位并修复 download.service 中的逻辑缺陷。
技术调试报告：下载服务状态机挂起与 RPC 兼容性故障
1. 问题概述
-
受影响文件：
download.service.ts/download.service.js - 故障现象：下载进度达到 100% 后，UI 界面无响应，无法自动跳转至解包或安装阶段。
-
根本原因：由于对
aria2依赖库的 API 调用方式不当，导致 RPC 模式启动即崩溃，强制回退至“直接模式（Direct Mode）”，而直接模式存在进程监控逻辑漏洞和 Angular Zone 同步缺失问题。
2. 核心漏洞分析
A. 错误的 RPC 方法调用 (Critical)
在 download.service.js 中，代码尝试将 RPC 指令直接作为实例方法调用：
-
错误代码：
yield this.aria2.getVersion()、yield this.aria2.addMetalink(...)。 -
产生的报错：
TypeError: this.aria2.XXXX is not a function。 -
后果：该异常会导致
connectRpc()返回false，程序永久回退到不稳定的直接模式。
B. 直接模式下的 Promise 悬挂 (High)
当 RPC 失败回退到 addMetalinkDirect 时，程序通过监控进程 close 事件来转换状态：
-
逻辑缺陷：如果
aria2c.exe进程因为文件句柄未释放、子进程僵死或返回了非 0 退出码，task.status.status将永远无法变为'complete'。 -
后果：
progressDirect中的setInterval轮询永远不会清除，对应的 Promise 无法resolve，导致调用链下游（安装逻辑）被物理挂起。
C. Angular 变化检测失效 (Medium)
下载状态的刷新被包裹在 runOutsideAngular 中执行：
-
代码片段：
this.ngZone.runOutsideAngular(() => { ... setInterval(refreshDownloadList) ... })。 -
逻辑缺陷：
refreshDownloadList触发的updateEmitter.emit()发生在 Angular 区域之外。 -
后果：即使后台状态已更新为
complete，前端界面也不会触发 UI 刷新，用户看到的依然是下载中的界面。
3. 修复方案建议
方案一：修复 RPC 兼容性 (已验证有效)
将所有非原生库方法（如 open, close, call 以外的方法）改用 .call() 接口调用。
// 修改前
yield this.aria2.addMetalink(encodedMeta4, { dir: library });
// 修改后
yield this.aria2.call('addMetalink', encodedMeta4, { dir: library });
需同步修改：getVersion, tellActive, tellWaiting, tellStopped, getFiles, pause。
方案二：强制 UI 同步更新
在状态发射器处显式切回 Angular Zone。
// 在 refreshDownloadList 中
this.ngZone.run(() => { this.updateEmitter.emit(); });
方案三：增强直接模式的鲁棒性
在 progressDirect 逻辑中引入保护机制：
- 增加超时
reject。 - 在检测到文件物理大小已等于总长度时，即使进程未关闭，也应尝试强制进入完成状态。
4. 结论
目前的 Bug 是由“错误的库调用导致 RPC 崩溃”与“直接模式逻辑不严谨”叠加造成的。通过修复 this.aria2.call 机制，可以重新启用稳定的 RPC 链路，从而规避直接模式下的各种异常挂起。
报告提交者：Gemini 协作调试助手
日期：2026年4月29日