命令行提示符出问题时的排查顺序:从现象到根因

效率 · 3 分钟阅读· 253 次阅读

提示符渲染超过 50ms 就会被感知成「终端变慢」

正确的第一步是分类:起不来、连不上、跑得慢,三条路完全不同。

先说结论

先分三类,再由外向内查:网络、进程、配置、依赖、资源。

  • 先确认现象能复现,且能描述清楚
  • 由外向内:端口、进程、配置、依赖、资源
  • 读第一条错误,不是最后一条
  • 改一个变量,验证一次,别一次改五处
  • 留下记录:现象、假设、验证、结论

第一类:起不来

先看进程在不在,再看它为什么退出:提示符渲染超过 50ms 就会被感知成「终端变慢」。

  • 查看服务状态与最近日志(不是全部日志)
  • 确认端口是否被占用、权限是否足够
  • 确认配置文件语法(多数服务支持 test 模式)
  • 确认依赖的数据目录存在且可写

第二类:连不上

按「本机、网络、代理、应用」四层查:

层级 验证方式 典型原因
本机 本机 curl / telnet 端口 没监听、只听 127.0.0.1
网络 从另一台机器访问 防火墙、安全组、VLAN
代理 检查反代配置与证书 路径、超时、头部大小
应用 看访问日志与错误日志 鉴权、限流、连接池耗尽

第三类:跑得慢

把退出码、当前目录、git 分支放进去,比放时间戳有用。

慢的问题先分清是「等」还是「算」:CPU 高是算,CPU 低但延迟高是等(IO、锁、网络)。

命令行提示符出问题时的排查顺序

这个服务的高频故障点

同类的坑基本集中在这些位置:

  • starship 用 Rust 写,冷启动约 5-10ms,比多数 shell 主题快
  • 提示符渲染超过 50ms 就会被感知成「终端变慢」
  • 把退出码、当前目录、git 分支放进去,比放时间戳有用
  • oh-my-zsh 插件加载过多时,开一个终端要 0.5-1.5 秒

别做的事

提示符里跑 git 命令,大仓库里每次回车都卡

把整个 PS1 写成一行超长转义,换主题时全部重写

一次改多个参数,会让下一次故障更难查。

把结论写下来

排查记录不是给别人看的,是给三个月后的自己看的。oh-my-zsh 插件加载过多时,开一个终端要 0.5-1.5 秒。

还有几处容易忽略的

都是小地方,但出问题时往往就卡在这里。

  • 提示符里同步查 git status,十万文件的大仓库能卡 100-300ms
  • 提示符里显示语言版本要读文件,node 项目里查一次约 30-80ms
  • 装了十几个 zsh 插件,每开一个终端等一秒

排障能力不是知道更多命令,是知道先查什么。

评论 (3)

南
南风

「先看日志再猜」这句话值一篇文。

老
老吴

备份没验证过等于没有,这条我认。

L
lin

最小可用配置这个说法很好,先跑起来再优化。

发表评论

验证码

提交后需站长审核,通过后才会显示。