基础篇
进阶篇
高频篇
精选篇
手写篇
面经篇
AI 篇
原理篇
每日一题
小程序题库
  • 知识卡片碎片时间过考点
  • 场景篇按分类整理的大前端场景考点
  • 历年面经按年份追踪真实考点
  • 算法题库NEW在线编码即时判题
  • 专项自测100 题快速查漏
  • 前端基础
    • HTTP从报文一路讲到 HTTPS
    • 浏览器渲染、事件循环、进程
    • 计算机基础Linux、网络、操作系统
  • 进阶专项
    • 设计模式23 种模式怎么用
    • 前端系统进阶学习大型项目工程化
    • 前端综合文章长期沉淀的实践文
  • 工程与工具
    • Node学习指南从环境搭建到服务端
    • NPM工作流script、依赖与发布
    • Docker容器化部署上手
    • Canvas图形与动画实战
  • 路线与导图
    • 思维导图知识点全景图
    • 学习路线按图索骥不跑偏
  • 动态
    • 公众号动态公众号历史文章
    • 博客动态站长的技术博客
    • 开发者导航常用工具与文档站
    • AI 热点每日 AI 资讯与动向
AI 工作台
旧版
AIHT
内容
精选全部 AI 动态热点榜AI 日报收藏
分类
模型行业编程产品技术观点开源
更多
Agent 接入
返回首页开发者导航
AIHT
精选 / 资讯详情
8.0
热点
AI SCORE
编程提效2025-11-28 05:22

Claude Code优化Shell启动速度提升95%

DEV Community · Nick Taylor#Claude#性能优化#实战案例
Editor brief · 编辑速览

实战案例展示Claude Code如何诊断和优化终端配置瓶颈,程序员可直接套用这套问题排查工作方法。

文章思维导图
Knowledge map
拖拽缩放
Full translation

完整中文译文

我的终端用起来很卡。每次打开新标签页,都要经历一段恼人的延迟,之后才能开始输入。于是我决定深入排查一下。在 Claude Code 的帮助下,我把启动时间从 770ms 降到了仅仅 40ms,速度提升了 19 倍。

问题并不是我积累了太多工具。.zshrc 里的大多数东西我确实都需要,但每添加一样东西,都会增加 shell 的启动时间。说实话,我以前从没认真研究过这个问题,就这么一直忍着。后来 John Lindquist 前几天发了这篇内容,我便想,不如让 Claude Code 帮我提速。

和往常一样,我对 Opus 4.5 的第一个测试是:“请为我的 ~/.zshrc 提出 10 项改进建议。”因为我想看看,这些工具能不能立刻让我的生活变得更轻松。

测量基准数据

首先,我需要知道实际情况到底有多糟:

平均每次启动 shell 约需 770ms。仅仅打开一个终端,就要等将近一整秒。很不理想。

到底是什么拖慢了速度

Claude Code 帮我找出了几个主要元凶:

最大的突破:Lazy Loading

大多数工具并不需要在启动时加载,等到我真正使用它们时再加载就可以。因此,可以把这些开销较大的操作推迟到第一次运行相关命令时再执行。

自销毁包装函数来救场

这正是其中巧妙的地方。感谢 Claude Code。包装函数会在第一次使用后删除自身:

  • 第一次调用:包装函数开始运行,执行耗时的初始化,然后删除自身
  • 后续调用:直接执行,零额外开销

每个会话只需要付出一次初始化成本。

我不再使用下面这种拖慢启动速度的代码:

现在,我改用包装函数:

更新于 2025-11-28:我已经放弃 nvm,改用 fnm,因此后来删除了 nvm、node、npm 和 npx 的包装函数。如果你仍然使用 nvm,请保留它们。

unset -f 和 unfunction 命令会在第一次使用后移除包装函数。此后的效果,就像这些工具从一开始便正常加载了一样。

pyenv 也采用同样的处理方式

第一次调用 pyenv 时,初始化大约需要 150ms;之后便始终是直接执行。

Homebrew 的环境并不会经常变化,所以只需把它缓存起来:

我以前每次启动 shell 时,都会访问一次 macOS Keychain:

由于只有处理 npm 相关操作时才需要它,因此我把它移到了 npm 包装函数中:

更新于 2025-11-28:如上所述,我已经改用 fnm,因此在删除 npm 包装函数后,也调整了这里的做法。现在,对于我的 OpenAI API key,我只会在需要时调用一个函数:

我的 newsletter 中还介绍了更多关于 macOS Keychain 的技巧。

我还顺便清理了一些基础配置:

  • 把 7 处不同的 PATH 修改合并成一行
  • 删除重复的 GPG_TTY 导出
  • 修正执行顺序,确保在 starship init 之前设置 STARSHIP_CONFIG

完成所有修改之后:

所谓的“取舍”——其实算不上

没错,第一次使用每个工具时,确实需要付出一次性的时间成本:

第一次运行 node/npm/npx:增加 400ms

但每个终端会话只会发生一次。说实话,与这些命令实际执行的操作相比,这点延迟几乎察觉不到。

如果你的 shell 很慢,首先测量完整的启动时间:

如果超过 200ms,就还有优化空间。要准确找出慢在哪里,可以分析 .zshrc,或者你正在使用的其他 shell 配置文件:

这样就能逐项看出,究竟是哪些命令占用了你的启动时间。

我更新后的 Shell 配置文件

这是我更新后的 shell 配置,其中包含了全部性能优化。

开发工具带来的开销累积得很快,而且这种“千刀万剐”式的性能损耗很容易被忽视。Lazy Loading 模式可以解决这个问题,而且几乎没有任何实际缺点。

特别感谢 John L. 和 Claude Code,帮助我找出了性能瓶颈以及相应的解决方案。

注意:文中的性能影响数据和对比表是在 Claude Code 的帮助下生成的。实际效果可能会因你的具体配置而异。😅

如果你想与我保持联系,可以在 nickyt.online 找到我的所有社交账号。

照片由 Unsplash 上的 Marc Sendra Martorell 拍摄。

Original source

本文由 AI 翻译整理,来源 DEV Community · Nick Taylor,原文版权归原作者所有。

阅读原文
上一篇
从零构建本地RAG系统完整指南
下一篇
Runprompt:CLI命令行Prompt文件运行工具

资讯速览

DEV Community · Nick Taylor · 2025-11-28 05:22

AI 评分 8.0 / 10

相关标签

#Claude#性能优化#实战案例

继续阅读

  • Claude单轮反编译实战:意外的高效性
  • 从零构建本地RAG系统完整指南
  • Runprompt:CLI命令行Prompt文件运行工具
  • 浏览器LLM自动生成Git提交信息实验录
  • AI Agent在日常压力下存在规则崩坏风险