从“系统卡住”到一条可验证的调用链

“卡住”可能是任务等待、死锁、中断被屏蔽，也可能只是日志停止输出。排障第一步，是区分观察手段失效和系统真正停止工作。

先标记最后一个确认点

按时间顺序记录已确认发生的事件，例如中断到达、任务变为就绪、调度决策、上下文切换和任务开始执行。不要把预期路径当成实际路径。优先找相邻两个确认点之间缺失的证据。

分别观察 CPU、任务和锁

任务在哪个 CPU 上运行、是否绑定核、当前状态是什么，与该 CPU 的中断状态是不同维度。检查等待对象、持锁者和锁顺序，必要时绘制等待关系，寻找循环等待或永远不会到来的事件。

事件到达 → 状态更新 → 调度决策 → 上下文切换
                         ↑
                 预期与证据从哪里分开？

日志也会改变时序

高频串口输出会增加耗时，打印锁甚至可能改变并发行为。关键路径可先写入有界缓冲区，事后导出；但同样要考虑缓冲区覆盖、跨核时间基准和可见性。没有一种观测方式是完全没有代价的。

一次只验证一个假设

减少核数、任务数或输入负载可以帮助缩小范围，但这些变化也可能只是隐藏问题。恢复原始压力条件并验证，才能判断修复是否成立。

每一次实验，都应该让某个假设更可信，或者让它被排除。