缓存

“过早优化是万恶之源，但在正确的时机做正确的优化，则是工程艺术的巅峰。” 12.1 问题引入 一个成熟的 AI Agent 系统面临着多维度的性能挑战。Claude Code 作为一个包含数十万行 TypeScript 代码的终端 AI 助手，需要同时解决以下问题： 启动速度：用户在终端输入 claude 后，如何在亚秒级时间内完成初始化？数百个模块的加载、配置的解析、API 客户端的构建——任何一项阻塞都意味着体验的劣化。 上下文窗口管理：模型的上下文窗口是有限的（通常为 200K tokens），而一个长时间的编程会话可能产生数百万 tokens 的对话内容。如何在不超过窗口限制的前提下最大化信息密度？ 内存控制：终端 UI 需要维护大量的渲染状态。一个包含 1000 条消息的会话，如果不做虚拟化，仅 React fiber 和 Yoga 布局节点就可能消耗 250MB 内存。 渲染流畅性：流式输出时每个 token 都会触发渲染更新。如何避免因频繁重绘导致的 CPU 峰值和卡顿？ 本章将深入剖析 Claude Code 针对这些问题的系统性优化策略，从 Token 计数的精妙权衡，到上下文压缩的三级体系，再到终端渲染的虚拟滚动算法。每一项优化背后都蕴含着对"精确性"与"速度"之间平衡的深刻思考。 12.2 启动优化策略 12.2.1 性能度量驱动的优化 Claude Code 遵循一个朴素但有效的原则：不能度量的东西无法优化。启动阶段的每一个关键检查点都被 startupProfiler 精确记录： // startupProfiler.ts — 启动性能度量框架 const PHASE_DEFINITIONS = { import_time: ['cli_entry', 'main_tsx_imports_loaded'], init_time: ['init_function_start', 'init_function_end'], settings_time: ['eagerLoadSettings_start', 'eagerLoadSettings_end'], total_time: ['cli_entry', 'main_after_run'], } export function profileCheckpoint(name: string): void { if (!SHOULD_PROFILE) return // 非采样用户零开销 const perf = getPerformance() perf.mark(name) if (DETAILED_PROFILING) { memorySnapshots.push(process.memoryUsage()) } } 该框架采用分层采样策略：100% 的内部用户和 0.5% 的外部用户被采样记录启动性能指标，而完整的内存快照报告仅在显式启用 CLAUDE_CODE_PROFILE_STARTUP=1 时生成。这种设计确保了生产环境中性能数据的持续可观测性，同时将度量本身的开销降至最低。 ...