emoeem

QQ 聊天记录防丢失与自动归档系统一个独立于 QQ 客户端的聊天记录归档系统：把你能合法、稳定获取到的 QQ 消息与多媒体，落到你自己的 SQLite 数据库与媒体目录里，用一个中文网页管理界面来搜索、浏览、导出。 一句话定位：它不能阻止 QQ 删除消息，但能保证凡是曾经到达过本系统的消息，以后都不会再丢。 目录 它解决什么问题 核心能力（真实实现，非演示） 快速开始 三种部署形态 项目结构 技术选型（及为什么） 数据模型 中文全文检索是怎么做的 导入格式 采集端与它的真实边界 扫码登录 QQ 备份与恢复 安全模型 测试 许可证 开源项目复用清单与许可证说明 已实现 / 有局限 / 未实现 后续扩展方向 常见问题 它解决什么问题QQ 聊天记录的丢失有几个不同来源，混在一起谈会得出错误的方案： 丢失来源 能否用本系统解决 怎么解决 手机换机 / 重装 / 清理缓存，本地记录没了 能 提前把已获取的记录导入归档，独立于 QQ 存储 群消息超过 5000 条被 NapCat LRU 清理 能 长期挂采集端 + 断点续传，进了库就永久保留 已撤回的消息后来想...

怎么把它跑起来用（照着做即可） 本文的每一条命令都在本机实际跑过，输出就是下面贴的那些。最小的那一步只需要 Node.js ≥ 22.5，不需要 npm install（本项目生产依赖为 0）。 它由两个独立的部分组成，先分清这一点，后面就不会乱： 部分 是什么 跑在哪 必须吗 归档服务器 数据库 + 网页 + API + 媒体存储（本项目） 你的电脑或 Linux 服务器 必须 采集端 通过 OneBot 接口读到 QQ 消息的东西（NapCat） 需要一台能跑 QQ 客户端的机器 只有”持续采新消息”才需要 只想把已有的导出文件存起来 + 网页看？只做 Part A 就够了。 Part A：把归档服务器跑起来（约 3 分钟）A1. 前置检查node --version # 需要 >= 22.5（实测 24.21 可用） A2. 拿到源码并配置源码目录里唯一需要动的文件是 config.json： cd /path/to/QQ cp config.example.json config.json chmod 600 config...

QQ 聊天记录归档系统 · 完整使用手册 这份文档是给使用者看的：它把这套工具”能做什么、怎么用、遇到问题怎么办”全写在了一起。面向实施细节的文档另有 ARCHITECTURE.md（架构）、DEPLOYMENT.md（部署运维）、format-mapping.md（导入格式映射与有损清单）、INDEPENDENT-VERIFICATION.md（独立复核：哪些验证过、哪些没有）。 目录 这是什么，能做什么 它做不到什么（先看这一节，避免误解） 需要什么前提 五分钟上手 完整使用手册 5.1 导入已有的聊天记录 5.2 持续采集新消息（接 NapCat） 5.2.1 采集控制面板（看状态、开始、停止） 5.3 网页界面每一页能干什么 5.4 找消息：搜索与筛选 5.5 图片、视频、语音、文件 5.6 导出 5.7 撤回、以及”清除内容” 5.8 新消息会自动出现（自动刷新） 5.9 过滤：不想看的怎么少看点 5.10 备份与恢复 5.11 语音转文字 5.12 扫码登录 QQ 部署：本机、Linux 服务器、Windows 命令速查表 常见问题（FAQ） 安全与隐私（必读...

部署与运维手册本文档覆盖两种目标环境（Debian/Ubuntu 与 Arch Linux），以及三种部署形态： 形态 适用场景 说明 A. 单机全量 个人电脑 / 已登录 QQ 的机器 归档服务器 + 采集端在同一台机器 B. 服务器 + 采集端分离 有 Linux 服务器 服务器只存归档、跑网页；采集端在个人电脑 C. 纯离线导入 完全不装采集端 只用 import 导入导出文件，网页查看 重要前提：本系统的采集端不依赖任何第三方 QQ 协议实现的内置代码，只通过 HTTP 调用OneBot v11 的只读接口。OneBot 实现的安装与登录属于你自己负责的部分，见第 6 节。 1. 系统要求 项目 要求 操作系统 Debian 11+ / Ubuntu 20.04+ / Arch Linux / 其他现代 Linux；macOS 与 Windows 也可运行（Windows 有一键脚本，见 §9.1） 架构 x86_64 / arm64 均可（无原生编译依赖） Node.js ≥ 22.5（需要 node:sqlite 与 T...

架构契约（冻结版 v1） 本文件是并行开发的唯一接口依据。任何模块之间的调用都必须遵守这里的签名与语义；需要变更时先改本文件 + packages/core/src/types.ts，再改实现。 0. 目录布局QQ/ ├── packages/core/ @qqarchive/core 领域类型、配置、日志、键生成、错误 ├── packages/db/ @qqarchive/db SQLite 存储层（迁移/仓储/FTS/备份恢复） ├── packages/import/ @qqarchive/import 导入器（QCE JSON/JSONL、TXT、通用）+ 媒体归档 ├── packages/collect/ @qqarchive/collect 采集适配器（OneBot/NapCat）+ 调度与告警 ├── packages/server/ @qqarchive/server HTTP API + 静态前端托管 + 认证 ├── apps/cli/ CLI 入口（ser...

导出格式 → 归档模型 映射说明本文描述 packages/import 如何把外部导出文件转换为本系统的标准模型，以及哪些信息在转换后丢失或降级。所有映射实现都在： packages/import/src/qce-map.ts（QCE 字段映射、时间解析、元素/资源/提及/引用提取） packages/import/src/normalized-map.ts（generic-jsonl 的归一化消息映射） packages/import/src/txt-parse.ts + packages/import/src/importers/qce-txt.ts（纯文本导出） packages/import/src/media-util.ts + packages/import/src/media.ts（媒体内容寻址归档） 标准模型定义见 packages/core/src/types.ts（NormalizedSession / NormalizedMessage / ResourceRef / ImportBatch），落库结构见 packages/db/src/schema....

验收测试报告 涵盖任务书「八、第六阶段：测试与验收」要求的 15 项测试，逐项给出状态、可复现的测试用例位置与真实运行输出。 本文件中的每一个数字都来自实际执行，不用编译通过替代功能测试，不虚构结果。 测试日期：2026-10-13　环境：CachyOS Linux / Node v24.21.0 / SQLite（Node 内置 node:sqlite）/ ffmpeg 9.0.2 0. 如何复现cd /home/emo/code/QQ # 类型检查（无编译步骤；Node 直接执行 .ts） npx tsc -p tsconfig.json --noEmit # 期望：无任何输出 # 全量自动化测试 node --test --experimental-strip-types "tests/**/*.test.ts" # 只跑本报告的 15 项验收 + 5 项真实联调 node --test --experimental-strip-types tests/acceptance.test.ts tests/integration.test.ts #...

独立复核报告：这些功能到底完成没有 复核日期：2026-10-13　复核对象：/home/emo/code/QQ（v0.1.0）复核方式：不看文档声称什么，只认我自己造出来的证据结论一句话：核心功能是真的、可用的、能过测试的；但我在复核中又抓出 6 处「实现了却没接线 / 前端与后端字段对不上」的真缺陷，全部已修并补了回归测试。 0. 先回答”你确定完成了吗”不完全确定 —— 所以我去查了。查下来的结论是： 维度 结论 之前声称的功能（导入/采集/媒体/网页/备份/部署） 属实，不是静态样板：网页连真库、媒体真落盘、采集真在跑 声称的测试全绿 属实：现在 347 个用例 0 失败（复核前是 263） 声称的”真机验证” 属实：库里有 282 条真实采集消息、25 个真实媒体文件，NapCat 此刻仍在采 但 23 个用例的测试套件测不出 6 个真缺陷 —— 因为它们全都出在”模块之间的接线”上，而单元测试只在模块内部打转 最后这条是关键。这个项目的测试写得相当扎实（真的起了子进程、真的开了 HTTP、真的算了 sha256），但测试和缺陷有共同盲区...

QQ 聊天记录防丢失与自动归档系统 — 项目报告 📌 修订说明：初稿写于独立复核之前（当时 263 个用例）。复核又抓出 6 个真缺陷并修复（引用内容端到端显示、备份对账与保留策略、数据目录搬迁、日志落库与保留、媒体重复下载、3 处前后端字段不一致），用例由 263 增至 347。§0 速览、§7 测试表格与全文用例数均已按当前实测刷新为 347 / 0 失败，复核过程见 INDEPENDENT-VERIFICATION.md。本文的架构、实现细节与边界分析仍然有效。 位置：/home/emo/code/QQ报告日期：2026-10-13口径说明：本文所有数字都是本机实测，不是文档抄写。与 README 中过时的计数冲突时，以本文为准；与更细的验收条目冲突时，以 acceptance.md 为准。 0. 一页速览 项 值 一句话 独立于 QQ 客户端的个人聊天记录归档系统：把已有导出文件导进来，把在线消息持续采下来，把图片/语音/视频/文件内容寻址落盘，用中文网页检索浏览，可备份可恢复可部署。 运行时 Node.js ≥ 22.5（实测 24.x），直接用...

最终报告 ⚠️ 本文是 2026-10-13 早间的交付记录，数字已过时（当时 240 个用例）。此后经过一轮独立复核，抓出并修复了 6 个真缺陷、补了 30 个回归用例，当前状态以INDEPENDENT-VERIFICATION.md 为准（347 个用例 0 失败）。本文其余的功能描述与边界说明仍然有效。 QQ 聊天记录防丢失与自动归档系统 · 交付版本 0.1.0报告日期：2026-10-13　环境：CachyOS Linux / Node v24.21.0 / SQLite（Node 内置）/ ffmpeg 9.0.2 一句话定位：本系统不能阻止 QQ 删除消息，它的目标是——凡是已经成功到达本系统的消息和媒体，就永久保留下来，不再依赖 QQ 客户端、不再受缓存清理、记录过期或设备更换影响。 配套文档：架构设计｜部署运维｜格式映射与有损清单｜验收测试报告｜开源项目调研 一、最终报告必须回答的 6 个问题1. 能否导入现有聊天记录？—— 能。已实现 5 种格式的导入，全部有自动化测试： 格式 说明 qce-json QQ Chat Exporter 的单...

QQ 聊天记录导出/归档项目调研检索日期：2026-10-13（Asia/Shanghai）。除特别注明外，star / commit / release 数据均来自 GitHub REST API（api.github.com）与各仓库 raw 文件，抓取时间同上。标注「未验证」表示未找到可核实的一手来源，请勿直接采信。 1. Tealina28/QQNT_Export 项 值 仓库 https://github.com/Tealina28/QQNT_Export 许可证 GPL-3.0（LICENSE 文件核实，文件头为 GNU GPL v3；API spdx_id=GPL-3.0） Stars / Forks 76 / 6 语言 Python 最新 Release v3.3.0，2026-07-12（另有 v3.2.0 2026-06-21、v3.1.0 2026-06-20） 最近 commit main 分支 API 返回最近一条为 2025-08-23（Merge pull request #21）；但仓库 pushed_at=2026...

QCE 复用性分析报告 分析对象：/home/emo/code/qq-chat-exporter（下称 QCE，shuakami/qq-chat-exporter，GPL-3.0）本仓现状基线：/home/emo/code/QQ（下称「本仓」）方法：QCE 与 NapCat 插件全部只读打开核实；本报告所有行号均为本轮实际打开文件确认。凡引用第三方侦察（/tmp/qce_media_findings.md）之处已显式标注。核实日期：2026-10-13本文档是本仓唯一被创建/修改的文件。 0. 结论速览 QCE 本身没有可”移植”的独立价值：它的采集能力全部寄生在 NapCat 上（一个注入 NapCat 进程的 Node 插件 + 一个 Rust bridge），不引 NapCat 就一行都跑不起来。”复用 QCE”这个说法必须拆开。 真正值得复用/已经复用的是两件与 QCE 代码无关的东西： A. NapCat WebUI 的 HTTP 契约（登录/扫码/快速登录）——这是 NapCat 的接口事实，QCE 只是众多调用者之一； B. 基于 msgSeq 的群消息缺口检测...