[导出] 大量消息导出选择流式传输下依然卡在50%

[Limbo-gate]

📦 QCE 版本

Client v6.2.2

📁 导出格式

HTML

💬 聊天类型

群聊

📊 大约消息数量

150w以上

🤔 发生了什么？

卡在50% 1,625,483 条消息不动了，大型消息记录。已经选择了流式传输

📋 错误信息

[�[31merror�[39m] [NapCat] [UtilityProcess] Worker进程退出，退出码: 18446744072635810000
08-02 19:19:42 [�[31merror�[39m] [Core] [Login] Login Error,ErrType:  1  ErrCode: 3

相对完整的一部分
INFO [BatchMessageFetcher] 时间筛选参数: 原始=Some(1483315200000)-Some(1578009599999)
 INFO [BatchMessageFetcher] 开始API调用 (尝试 1/4) batchSize=5000
 INFO [BatchMessageFetcher] 调用 getMsgHistory API, msgId=7660553440978034468, count=5000

08-02 19:17:40 [�[31merror�[39m] [NapCat] [UtilityProcess] Worker进程退出，退出码: 18446744072635810000

08-02 19:17:40 [�[33mwarn�[39m] [NapCat] [UtilityProcess] Worker进程意外退出 (1/3)，正在尝试重新拉起...

config_current_version:9.9.31-49738

config_prev_version:

load from:D:\program\QQ\versions\9.9.31-49738\QQNT.dll

NapCat Shell App Loading...
08-02 19:17:40 [�[32minfo�[39m] [PacketHandler] 加载成功

08-02 19:17:40 [�[32minfo�[39m] [Napi2NativeLoader] 加载成功

08-02 19:17:40 [�[32minfo�[39m] [FFmpeg] 检查 Native Addon 可用性...

08-02 19:17:40 [�[32minfo�[39m] [FFmpeg] ✓ 使用 Native Addon 适配器

08-02 19:17:40 [�[32minfo�[39m] [PacketHandler] 初始化成功

08-02 19:17:40 [�[32minfo�[39m] [NapCat] [Core] NapCat.Core Version: 4.18.13

08-02 19:17:41 [�[32minfo�[39m] [NapCat] [WebUi] WebUi Token:

08-02 19:17:41 [�[32minfo�[39m] [NapCat] [WebUi] WebUi User Panel Url: http://127.0.0.1:6099/webui?token=

08-02 19:17:41 [�[32minfo�[39m] [NapCat] [WebUi] WebUi User Panel Url: http://127.0.0.1:6099/webui?token=

08-02 19:17:41 [�[32minfo�[39m] 等待网络连接...

08-02 19:17:41 [�[32minfo�[39m] 网络已连接

08-02 19:17:41 [�[32minfo�[39m] 没有 -q 指令指定快速登录，将使用二维码登录方式

08-02 19:17:41 [�[32minfo�[39m] 可用于快速登录 of QQ：

📎 日志和截图确认

• 我已提供完整日志；即使启动失败，也已提供启动失败时生成的日志。
• 我已提供必要截图；如果不适用，已在问题描述中说明。

⚙️ 使用的导出选项

• 流式导出（超大消息量专用）
• 导出为 ZIP 压缩包
• 快速导出（跳过资源下载）
• 设置了时间范围
• 设置了关键词过滤
• 设置了排除用户

🖼️ 资源下载情况

跳过了资源下载

[Tyr1onX]

已提交修复 PR #635。

定位到的问题是：BatchMessageFetcher 原本只在超时时缩小 batchSize；QQ/NapCat UtilityProcess 退出后，Rust bridge 常见的 connection reset、EOF、broken pipe、error sending request 等错误会被当成普通 API 错误，下一次仍使用原来的 5000 条窗口。另外，即使窗口曾缩小，连续成功三批后也会逐步涨回 5000，可能再次触发 Worker 崩溃。

PR 中已改为：

• Worker 退出/bridge 连接重置时自动将批次折半重试；
• 将该次抓取的回升上限固定在缩小后的安全值，避免再次涨回已触发崩溃的窗口；
• 保留普通超时原有的渐进恢复逻辑；
• 添加 5000 → 2500 重试及“不再回升到 5000”的回归测试。

仓库的 Rust exporter/server tests、Node 多平台测试和 API smoke 已通过。还需要用这个 PR 的测试构建在原来的 150 万条群聊上做最终验证；若仍会退出，请补充 QCE 侧紧邻 API调用失败 的完整错误文本，以便继续覆盖实际的 bridge 错误形态。

[shuakami]

@Limbo-gate 您好，一位贡献值提交了相关pr修复，如果您目前有空的话，可以测试一下是否有用：

• Windows版本：https://github.com/shuakami/qq-chat-exporter/actions/runs/30751078443/artifacts/8834502467

[Limbo-gate]

@Limbo-gate您好，一位贡献值提交了相关pr修复，如果您目前有空的话，可以测试一下是否有用：

• Windows版本：https://github.com/shuakami/qq-chat-exporter/actions/runs/30751078443/artifacts/8834502467

失败了
INFO [BatchMessageFetcher] 时间筛选参数: 原始=Some(0)-Some(1785761519177)
INFO [BatchMessageFetcher] 开始API调用 (尝试 1/4) batchSize=3000
INFO [BatchMessageFetcher] 调用 getMsgHistory API, msgId=, count=3000
08-03 21:04:00 [�[31merror�[39m] [NapCat] [UtilityProcess] Worker进程退出，退出码: 18446744072635810000
08-03 21:04:00 [�[33mwarn�[39m] [NapCat] [UtilityProcess] Worker进程意外退出 (1/3)，正在尝试重新拉起...
config_current_version:9.9.31-49738
config_prev_version:
load from:
NapCat Shell App Loading...
08-03 21:04:00 [�[32minfo�[39m] [PacketHandler] 加载成功
08-03 21:04:00 [�[32minfo�[39m] [Napi2NativeLoader] 加载成功
08-03 21:04:00 [�[32minfo�[39m] [FFmpeg] 检查 Native Addon 可用性...
08-03 21:04:00 [�[32minfo�[39m] [FFmpeg] ✓ 使用 Native Addon 适配器
08-03 21:04:00 [�[32minfo�[39m] [PacketHandler] 初始化成功
08-03 21:04:00 [�[32minfo�[39m] [NapCat] [Core] NapCat.Core Version: 4.18.13
08-03 21:04:00 [�[32minfo�[39m] [NapCat] [WebUi] WebUi Token:

INFO [BatchMessageFetcher] 调用 getMsgHistory API, msgId=, count=3000
08-03 21:30:54 [�[31merror�[39m] [NapCat] [UtilityProcess] Worker进程退出，退出码: 18446744072635810000
08-03 21:30:54 [�[33mwarn�[39m] [NapCat] [UtilityProcess] Worker进程意外退出 (1/3)，正在尝试重新拉起...
config_current_version:9.9.31-49738
config_prev_version:
load from:
NapCat Shell App Loading...
08-03 21:30:54 [�[32minfo�[39m] [PacketHandler] 加载成功
08-03 21:30:54 [�[32minfo�[39m] [Napi2NativeLoader] 加载成功
08-03 21:30:54 [�[32minfo�[39m] [FFmpeg] 检查 Native Addon 可用性...
08-03 21:30:54 [�[32minfo�[39m] [FFmpeg] ✓ 使用 Native Addon 适配器
08-03 21:30:54 [�[32minfo�[39m] [PacketHandler] 初始化成功
08-03 21:30:54 [�[32minfo�[39m] [NapCat] [Core] NapCat.Core Version: 4.18.13
08-03 21:30:54 [�[32minfo�[39m] [NapCat] [WebUi] WebUi Token:
08-03 21:30:54 [�[32minfo�[39m] [NapCat] [WebUi] WebUi User Panel Url: http://127.0.0.1:6099/webui?token=
08-03 21:30:54 [�[32minfo�[39m] [NapCat] [WebUi] WebUi User Panel Url: http://[::]:6099/webui?token=

[Tyr1onX]

@Limbo-gate 您这次的结果确认了：前一版仍没有命中直接触发点。任务在第 1 批、已写入 0 条时就让 QQ/NapCat Worker 重启并丢失登录态，因此磁盘落盘和内存优化当时根本还没有机会生效。

进一步审计后发现旧路径有两个关键问题：

1. 群聊历史使用 getMsgsIncludeSelf/getMsgHistory；所谓 fallback 实际最终仍会调用同一个 QQ 内核接口，并不是独立备用实现；
2. 本地等待超时后会自动重试，但 QQ 内部的原生请求可能并未真正结束，新的调用可能与旧请求重叠，随后出现 Worker 重启、重新登录和任务一直为 0 条。

PR #635 已继续修改，当前提交：8e8196e。

这版不再只是降低 batchSize，而是对群聊流式导出彻底更换抓取链路：

• 不再调用 getMsgsIncludeSelf/getMsgHistory；
• 首次只读取 1 条消息取得最新 msgSeq；
• 后续只使用 getMsgsBySeqAndCount 向前分页；
• 批次从 20 开始，成功后才升到 50、100，最高 200；
• 所有历史请求全局串行，同一时间只能有一个；
• 超时或 Worker 异常立即停止，不再自动重复调用；
• 异常后熔断 30 秒，避免立刻再次压垮 Worker；
• 处理阶段取消会再次查询历史消息的“序列修复”。

Windows x64 测试构建：
https://github.com/shuakami/qq-chat-exporter/actions/runs/30963913890/artifacts/8914096933

对应提交：8e8196e
SHA-256：65eca3e3f175e7c051079c1a08ddcedcfa9651c17a79599fb389befa6aa85e23
产物有效期至 2026-08-12。

使用方式：

1. 下载并解压到一个新的空目录；
2. 关闭上一版测试构建；
3. 只从新目录启动，不要把新旧文件混在一起；
4. 重新登录后再开始一次流式导出。

这版启动群聊流式导出后，应当先看到类似：

正在使用安全序列分页读取群聊：单请求、全局串行、失败不重试

随后批次应从 20 条开始，而不应再出现 getMsgHistory ... count=1000。如果仍显示旧的 getMsgHistory/count=1000，说明实际启动的仍是旧目录。

请只反馈以下脱敏结果：

• 是否出现“安全序列分页”这行状态；
• 已写入数量是否从 0 开始增长；
• QQ/NapCat Worker 是否再次重启或要求重新登录；
• 最终是否生成 ZIP。

不需要粘贴完整日志，也不要公开 QQ 号、群号、昵称、聊天内容、二维码、WebUI Token 或完整本地路径。

[Limbo-gate]

我不知道完整替换上一版测试构建后启动什么意思，总之我下载你发的链接重新试了一次，这个有出现“开始API调用 ... batchSize=1000
调用 getMsgHistory API ... count=1000”。但最后依然卡主了，任务在继续，

至于“请把第一次 count=1000 开始，直到 Worker 重启后 QCE 后续行为的完整日志贴出来” 第一次count=1000 的内容以及被刷没了，而且直到重启后到控制台发二维码为止内容涵盖大量私人信息，无法批量复制。

[Tyr1onX]

@Limbo-gate 感谢前面的测试。我们继续审计后确认，这个问题不只是“50% 显示不动”，旧流式实现确实还有一个更根本的问题：它会先把抓到的全部原始消息累计在内存中，150 万条记录越到后面内存压力越大，最终可能从“看起来卡住”演变成真正变慢、换页或 OOM。

我们已经把之前的批次限制、Worker 重试、进度修复和这次的深层改造统一合并到 PR #635：

• 流式 getMsgHistory 首次请求和 bridge 边界均限制为最多 1000 条；
• Worker 退出、连接重置、EOF、broken pipe 或超时后自动减小批次重试；
• 两个原有流式接口已改为磁盘分块流水线：每抓取一批就立即写入独立 JSONL 暂存文件，不再把全部原始消息保存在内存；
• 抓取完成后逐批解析、逐批处理资源、每 1000 条生成一个最终输出分块；
• 流式 ZIP 中的查看器一次只加载一个消息分块，打开百万级记录时也不会一次把所有消息放进浏览器内存；
• 状态会持续显示已写入消息数、批次数、最近活动和当前请求等待秒数，不再用固定 50% 冒充真实总进度；
• 连续重复游标、连续空批次仍声称有更多消息时会主动停止，避免无限假运行；
• 完成、失败或取消都会清理原始消息暂存目录；异常退出后超过 24 小时的旧暂存也会自动清理；
• “快速导出/过滤纯多媒体消息”仍然会跳过图片、视频、语音和文件下载，不会因为新流水线而恢复下载全部资源。

当前自动验证结果：

• Rust exporter/server 测试已通过；
• Windows、macOS、Linux 上 Node 20/22 的插件测试均已通过；
• macOS 和 Framework 完整包已经构建成功；
• Windows x64 完整包与 API/Playwright smoke 在最后检查时仍处于构建阶段，因此请暂时不要下载旧测试包或中间构建。当前构建进度可在 https://github.com/shuakami/qq-chat-exporter/actions/runs/30929150066 查看。

新的 Windows x64 产物生成后，应只使用名称中包含 pr635 的本次构建：关闭旧测试包，解压到新的空文件夹，不要与旧版本文件混用。

后续测试也不需要提供完整日志。只需反馈以下脱敏结果：

• “已写入消息数”和批次数是否持续增长；
• Worker 是否再次重启；
• QCE 进程的大致内存峰值；
• 是否最终生成 ZIP，以及解压后 index.html 能否翻阅不同分块。

请不要公开 QQ 号、群号、昵称、聊天内容、二维码、完整本地路径或任何 Token。你之前的评论 #634 (comment) 中出现过 WebUI Token 字段，请编辑并删除该字段；若该 Token 仍有效，建议在 NapCat 中重置。

[Limbo-gate]

和之前一样，没有增长。
又让我重新登录了，重启了。

内存峰值是这个吗。 断了 没生成zip，我哪里操作有问题。

[ODRAN07]

我这里也出现一样的问题（除了消息数约98w外其他信息一模一样），应该是在收集完所有记录后准备开始压缩成zip时出现bug停止进程