一个运行在终端里的工具连续两次突然退出。
直觉上，最可疑的当然是工具本身：它是不是崩了、被信号杀了，或者某个插件把会话搞挂了？工具日志也恰好在异常时刻中断，看起来像是直接证据。
但系统留下的两份 crash report 指向了另一个结论：真正崩溃的是宿主终端应用。两次都是同一个 SIGSEGV 指纹，发生在主线程的文字视图绘制路径。终端工具只是随着宿主进程一起消失。
这类故障的难点不在看不懂日志，而在于很容易把“最后还能观察到的进程”误当成“故障源”。
🔗 进程关系决定证据怎么读
终端里的交互式工具并不是独立存在的。它依赖宿主终端提供伪终端、窗口和会话生命周期。宿主进程一旦崩溃，里面运行的 shell 和前台工具都会被连带终止。
因此以下事实不能单独证明工具自身故障：
- 工具日志在某个时刻突然停止；
- 工具没有写出正常退出记录；
- 会话窗口和工具同时消失；
- 重开工具后暂时恢复正常。
这些现象既符合“工具崩溃”，也符合“宿主终端崩溃”。它们只能描述结果，不能完成归因。
🧾 先找谁留下了系统级崩溃指纹
排查顺序应该从进程层级往外走，而不是先在工具配置里盲改参数。
第一步，确认故障时刻系统是否生成了 crash report。macOS 的报告通常能回答几个关键问题：
- 崩溃的进程到底是谁；
- 异常类型和访问地址是什么；
- 哪个线程触发了崩溃；
- 调用栈落在应用自身、系统框架还是插件；
- 多次故障是否具有相同指纹。
如果系统报告明确记录宿主终端在同一时刻发生段错误，而工具日志只表现为被动中断，那么证据优先级已经很清楚：先处理宿主崩溃，不能继续把工具当作已证实的根因。
⏱️ 时间对齐比单份日志更重要
单看任何一份日志都可能讲出一个合理但错误的故事。更可靠的方法是把证据放到同一条时间线上：
10:35:56 宿主终端触发 SIGSEGV
10:35:56 工具日志停止
11:35:04 宿主终端再次以相同调用栈崩溃
11:35:04 工具会话再次消失当两个独立数据源在时间上重合，而且宿主有明确的异常栈、工具没有自身崩溃指纹时，“宿主崩溃导致连带退出”比“工具连续两次自行崩溃”更符合证据。
这里最关键的不是相关性本身，而是异常归属加上时间相关性：系统报告告诉你谁崩了，时间线告诉你其他进程为什么同时消失。
🧭 定位故障源，不等于找到最终触发条件
确认宿主终端是崩溃源，只完成了第一层归因。它仍然没有回答：为什么文字视图会崩？是特定输出内容、字体渲染、窗口状态，还是系统框架缺陷？
这两个结论必须分开表达：
- 已确认：宿主终端发生崩溃，工具是连带退出；
- 仍待确认：触发宿主渲染崩溃的具体输入或操作路径。
把第一层定位误写成完整根因，会让排查过早停止。更好的后续动作是保留下一次故障前的窗口内容、操作步骤和 crash report，再按异常类型、线程和栈顶函数比对指纹。
✅ 结论
看到某个终端工具突然退出，不要默认“消失的那个就是崩溃的那个”。在宿主—子进程结构里，子进程日志中断往往只是上游进程死亡的结果。
可靠的归因至少需要两步：先用系统 crash report 确认异常属于哪个进程，再把宿主报告与工具日志按时间对齐。
退出是现象，崩溃归属才是证据。两者之间不能靠直觉补齐。
马启航Marvis