启动器出问题时的排查顺序:从现象到根因

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

Raycast 的扩展用 JS 写,一个简单的脚本命令二十行以内

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

先说结论

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

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

第一类:起不来

先看进程在不在,再看它为什么退出:Raycast 的扩展用 JS 写,一个简单的脚本命令二十行以内。

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

第二类:连不上

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

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

第三类:跑得慢

文件索引首次建立要 1-3 分钟,索引没建完搜索会漏结果。

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

启动器出问题时的排查顺序

这个服务的高频故障点

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

  • 剪贴板历史是启动器里使用频率最高的功能,超过文件搜索
  • Raycast 的扩展用 JS 写,一个简单的脚本命令二十行以内
  • 文件索引首次建立要 1-3 分钟,索引没建完搜索会漏结果
  • 启动器常驻内存 100-300MB,老机器上能感觉到

别做的事

把启动器当文件管理器,深层目录还是得开访达

剪贴板历史里存了密码,还开了云端同步

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

把结论写下来

排查记录不是给别人看的,是给三个月后的自己看的。启动器常驻内存 100-300MB,老机器上能感觉到。

还有几处容易忽略的

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

  • Spotlight 的 ⌘+Space 与第三方启动器冲突,装完第一件事是改键
  • 把常用脚本挂进启动器,比记住脚本所在路径实际得多
  • 装完不改快捷键,两个启动器一起弹出来

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

评论 (3)

L
lin

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

南
南风

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

K
Kevin

版本差异要强调,我照着做结果参数名全变了。

发表评论

验证码

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