Claude Code 的资源黑洞: 从 11.3MB 单文件打包到 1.2TB 磁盘吞噬

Claude Code 的客户端是一个没有资源生命周期管理的 Node.js 单文件应用: 启动时解析 11.3MB 的打包文件, 运行时无限制地写入磁盘, 关闭终端后进程继续存活并持续消耗内存, 直到系统崩溃. 基于 GitHub Issues 中的真实用户报告和社区逆向分析, 本文系统梳理其在内存, CPU, 磁盘三个维度上的资源管理缺陷, 揭示打包架构, 存储设计和进程生命周期管理中的结构性问题. 这些不是边缘 case, 而是从 2025 年 8 月到 2026 年 4 月持续被社区报告, 却被 stale 机器人批量关闭的系统性架构缺陷.

打包架构: 11.3MB 单文件的代价

Claude Code 的核心是一个名为 cli.js 的单文件打包产物, 体积约 11.3MB. 社区用户 paultendo 在 Issue #29481 中对其进行了详尽的静态分析, 揭示了多个严重的架构问题.

V8 启动耗时: 32% 时间用于解析

CPU profiling 显示 compileSourceTextModule 消耗了启动阶段 31.7% 的采样时间. V8 引擎需要约 300ms 来解析这个 11.3MB 的单文件, 而一个裸 Node.js 脚本的解析时间仅需 23ms. 额外的 7.3% 消耗在 spawnSync 调用上, 3.5% 消耗在垃圾回收上. 这意味着在用户输入任何指令之前, 已经有超过 40% 的启动时间被浪费在了纯粹的解析开销上.

全量加载: 只有 20 个动态 import

整个打包文件在启动时被完整解析和执行, 仅有 20 个 import() 表达式. 每个用户都为所有功能付出了代价, 无论是否使用. 以下是本应按需加载却被全量打包的组件:

pie title 打包文件组成 (约 13.5MB)
    "应用核心逻辑" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 种语言)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "其他 (Ink, Zod, Ajv, Axios 等)" : 1807

一个编码助手需要高亮 Brainfuck, MIPS assembly, Flix, Zephir, Inform7, Lasso 等 182 种语言, 这本身就说明了打包策略的粗放程度. 仅保留约 40 种常用语言就能节省约 786KB 的解析开销.

依赖冗余: 四个 HTTP 客户端, 三个验证库

不同 SDK 各自引入了独立的依赖, 导致打包文件中同时存在四个 HTTP 客户端 (Axios, Undici, Got, 原生 fetch) 和三个验证库 (Zod, Ajv, JSON Schema). 在 Node 18+ 环境中, 原生 fetch 已经完全可用, 根本不需要额外的 HTTP 客户端.

413 个同步文件系统调用

打包文件中包含 196 个 existsSync, 109 个 statSync, 108 个 readFileSync, 58 个 mkdirSync 等, 总计 413 个同步文件系统调用. 每一个都会阻塞事件循环. 许多调用遵循 existsSync(path) && readFileSync(path) 的模式, 两个系统调用本可以用一个 try { await readFile(path) } catch {} 替代.

1087 个 CJS/ESM 互操作包装器

每个被打包进 ESM 的 CommonJS 模块都生成了 __toESM/__commonJS/__require 兼容性垫片, 总计 1087 个. 这些垫片既增加了解析权重, 又带来了每个模块的微小运行时开销.

不必要的 Node 20 polyfill

打包文件中包含 62 个 Promise 垫片 (Node 0.12 起原生支持), 57 个 Symbol 垫片 (Node 4 起原生支持), 57 个 async 转换辅助函数 (Node 8 起原生支持), 以及 3 个 AbortController polyfill (Node 15 起原生支持). 这些来自为旧版 Node 或浏览器环境编译的传递依赖, 在目标运行时完全多余.

ripgrep 打包全部 6 个平台二进制: 61MB

ripgrep 的 6 个平台二进制全部被打包, 总计 61MB. 与之对比, sharp 正确使用了 optional dependencies, 仅安装当前平台的二进制. 这意味着每个安装都浪费了约 51MB 的磁盘空间.

Ink 渲染性能随对话长度退化

终端 UI 使用 Ink (React for Terminal). 分析显示组件树中有 6457 个 createElement 调用, 578 个 useState hooks, 但仅有 11 个 React.memo() 包装器, 比例仅 1.9%. 在 Ink 中, 每次状态更新都会触发完整的虚拟 DOM 协调. 流式响应期间, 每个到达的 token 都触发状态更新, 导致未 memo 化的组件不必要地重新渲染. 随着对话增长, 渲染输出增长, 每次重新渲染需要 diff 更多终端内容. 这与 Issue #22265 中报告的 “会话进行中越来越慢” 现象一致.

磁盘吞噬: 从 GB 到 TB 的无限制增长

磁盘问题是 Claude Code 最严重的资源管理缺陷, 影响范围最广, 后果最严重.

Windows .node 原生模块泄漏: 每周 20GB

Issue #23095 记录了一个持续数月未修复的问题: Claude Code 的 Windows 原生二进制文件 (claude.exe) 在每次会话时向系统临时目录提取原生 Node.js 插件文件, 但从不清理. 每个文件约 6.6MB, 用户 SlothKing16 在 4 天内累积了 2813 个文件, 共 18GB. 用户 kolkov 的统计更为惊人: 约 20GB/周, 重度用户可达 100GB/周. 这个问题从 2025 年初被报告至今, 期间被机器人多次标记为重复并尝试关闭.

~/.claude 目录: 3GB+ 无管理

用户 kolkov 在 Issue #5024 中对一台日常使用 8 个月的机器进行了审计:

pie title ~/.claude 目录占用 (约 3.1GB)
    "projects/ (会话记录)" : 2500
    "debug/ (调试日志)" : 303
    "file-history/ (文件快照)" : 232
    "history.jsonl (全局历史)" : 10
    "其他" : 55

关键数字: 最大单个会话 JSONL 文件 203MB, 最大子代理 JSONL 文件 72MB, history.jsonl 包含 37000+ 条目. 所有数据没有轮转, 没有压缩, 没有清理机制. file-history/ 中的文件快照没有去重, 同一文件编辑 10 次就存储 10 份完整副本. debug/ 目录中的调试日志从不清理.

后台任务输出文件: 1.2TB 的自我引用死循环

Issue #32282 揭示了一个令人难以置信的设计缺陷. 当 Claude Code 启动多个后台代理并自动运行一个检查进度的 bash 命令时, 该命令的输出文件被写入与被 glob 匹配的同一目录, 形成自我引用的无限反馈循环:

flowchart LR
    A["bash: for f in tasks/*.output; tail -5 $f"] --> B["输出写入 tasks/task-A.output"]
    B --> C["glob 匹配到 task-A.output 自身"]
    C --> D["tail -5 读取自身输出"]
    D --> E["追加写入自身"]
    E --> C

多个用户报告了相同的问题: 1.2TB, 460GB, 303GB, 235GB, 480GB, 36GB. 该 issue 的评论者统计了 70 个相关的 open issues, 分为 15 组, 仅前两组报告的磁盘消耗就达约 9.5TB. 写入速率可达 425MB/s, 持续 18 分钟, 直到磁盘耗尽.

级联故障: 磁盘满后的不可逆崩溃

Issue #24207 描述了当磁盘被填满后的灾难性连锁反应:

flowchart TD
    A["磁盘空间 = 0"] --> B["写入 .claude.json 失败"]
    B --> C["产生零长度文件"]
    C --> D["读取为无效 JSON"]
    D --> E["覆盖所有项目设置"]
    E --> F["OAuth/API 令牌损坏"]
    F --> G["需要重新认证"]
    G --> H["所有运行中的代理/会话停止"]
    H --> I["即使释放磁盘空间也无法恢复"]

没有预警, 没有优雅降级, 没有恢复路径. 用户必须手动终止所有进程, 手动释放空间, 手动恢复配置, 重新认证, 重新配置所有设置.

并发写入: 没有锁, 没有事务, 没有协调

~/.claude/ 目录中唯一的锁文件是 .update.lock (5 字节). 其他所有文件写入都没有保护. 当多个 Claude Code 进程同时运行时 (代理 + 子代理是正常使用场景), 它们对共享文件的写入没有任何协调:

Windows 上情况更糟: 原子写入的变通方案 (先写 .tmp 再 rename()) 在 Windows 上失败, 因为当目标文件被其他进程持有时 rename() 返回 EPERM, 完全破坏了原子性.

内存与 CPU: 从 13GB RSS 到内核恐慌

Windows 极端内存消耗

Issue #24840 记录了 Windows 上的极端案例: RSS 13.21GB, 虚拟内存提交 47.17GB, 而机器总内存仅 42.56GB. 页面错误 375 万次, 表明持续进行磁盘 I/O. 运行时间 347 秒中, 用户态 CPU 时间仅 35 秒, 约 90% 的时间花在等待 I/O 和 swap 上. 这导致其他应用 (如 Opera 浏览器) 完全无法响应.

macOS 内核恐慌

Issue #39253 报告了更严重的后果: 在 MacBook Pro M3 Pro (18GB RAM) 上, 运行多个 Claude Code 实例会导致 macOS 内核恐慌. 两种不同的恐慌类型被观察到: Jetsam OOM kill (内存压力导致 macOS 杀死了关键的 watchdogd 进程) 和 watchdog timeout (watchdogd 因系统资源饥饿 90+ 秒未签到). 系统在没有警告的情况下直接重启, 没有错误对话框, 没有保存工作的机会.

进程孤儿: 关闭终端后继续存活

Issue #44507 (2026 年 4 月, 就在几天前) 报告了一个基本的生命周期管理缺陷: 关闭终端窗口后, Claude Code 进程继续存活. 一个孤立的进程在 21 天内消耗了 35.4GB RSS, CPU 占用 95.5%. 根因是主 CLI 入口点没有 process.stdin.on("end") 处理器, 而 55+ 个 setInterval 定时器 (设置轮询, 遥测, 状态栏刷新等) 保持 Node.js 事件循环无限存活. V8 堆不受限制地增长, 没有空闲 GC 压力, 没有 --max-old-space-size 限制, 没有自终止看门狗.

100% CPU 冻结

Issue #27415 报告了 TaskStop 触发的 100% CPU 冻结, 根因是 Bun 运行时中 posix_spawn 的失控循环. Issue #26224 报告了 Claude Code 在处理大量提示时挂起 5-20 分钟的问题.

扁平文件架构的系统性失败

分配而不清理: 贯穿所有 issue 的架构模式

社区成员 kolkov 在多个 issue 中反复指出, 所有这些问题的根本原因相同:

这个 .node 泄漏不是一个孤立的 bug – 它是一种反复出现的架构模式的症状, 即 Claude Code 分配资源而不清理.

从 2025 年到 2026 年, 问题从 .claude.json 单文件膨胀演变为 JSONL 文件分散膨胀, 但根本架构没有改变: 扁平文件, 没有锁, 没有事务, 没有清理, 没有压缩.

SQLite 与本地守护进程: 社区的替代方案

社区多次提出使用 SQLite 替代扁平文件存储的建议. 一个 SQLite 数据库可以同时解决所有问题: WAL 模式提供并发读取 + 单写入的原子性, 事务保证会话写入的全有或全无, 内置压缩, TTL 清理, 内容去重, 跨平台一致性.

另一个建议是引入本地守护进程 (类似 LSP 服务器, Docker 的架构), 所有 Claude Code 进程通过 IPC 通信, 提供协调而不改变存储后端.

社区逆向工程与 stale 机器人的对比

社区成员 gebeer 的评论精准地概括了现状:

感谢你的详尽分析. 这本该由维护者很久以前就完成的.

kolkov 进一步指出:

讽刺的是, 社区实际上在替他们做调试 – 逆向工程混淆代码, 追踪错误路径, 提出带代码片段的修复方案 – 而回应是一个 60 天后关闭所有内容的 stale-issue 机器人.

同类工具的资源管理对比

GitHub Copilot 作为 VS Code 扩展运行, 受到扩展宿主的内存限制和生命周期管理约束; Cursor 基于 VS Code 的 fork, 继承了相同的资源管理框架; 两者的存储都使用 SQLite 或类似的数据库, 天然支持并发和事务. Claude Code 选择了独立进程 + 扁平文件的方案, 却没有实现独立进程应有的资源管理责任 – 没有内存上限, 没有磁盘配额, 没有进程看门狗, 没有优雅退出. 它的行为更像一个原型演示, 而不是一个面向生产环境的工具.

模型能力与工程质量的悖论

11.3MB 的单文件打包, 413 个同步文件系统调用, 1087 个 CJS/ESM 互操作包装器, 没有资源清理, 没有并发控制, 没有磁盘空间监控 – 这些不是边缘 case, 而是系统性的架构缺陷. 从 2025 年 8 月的 Issue #5024 到 2026 年 4 月的 Issue #44507, 社区持续报告相同类别的问题, 提供详尽的分析和修复建议, 而许多 issue 被标记为 “not planned” 或被 stale 机器人自动关闭. 一个 AI 编码工具, 其自身的代码质量却需要社区来审计和修复, 这本身就是一个值得深思的悖论.

如果你正在使用 Claude Code, 建议定期检查 ~/.claude 目录大小, 清理临时目录中的 .node 文件, 并在关闭终端前确保使用 Ctrl+C 正确退出. 如果磁盘空间突然消失, 现在你至少知道该去哪里找原因了.

• ←上一页
• 下一页→