排查macOS服务超时需精准定位具体服务、阶段、时长及复现性，用log show命令结合日志特征（如watchdog timeout、failed to start in time等）、服务名筛选、时间窗口上下文分析及shutdown cause关联验证。
排查 macos 系统服务超时问题，关键不是泛泛查“慢”，而是锁定具体哪个服务在什么阶段卡住、卡多久、是否反复发生。log show 命令直连统一日志数据库，能精准捕获系统服务启动、响应、超时的完整时间线，比看 cpu 占用或进程列表更接近真相。
定位服务超时的典型日志特征
系统服务超时通常不会直接写“超时”二字，而是通过以下信号暴露：
- watchdog timeout：最明确的标志，常见于 kernel、launchd、WindowServer 等核心服务；
- reset_in_1 timeout 或 wdog：说明看门狗已介入强制复位，属于严重超时；
- failed to start in time、timed out waiting for、not responding after N seconds：launchd 或 XPC 服务常用表述；
- service did not respond within timeout：由 systemstats、symptomsd 等诊断服务记录，常附带子系统名和进程 ID。
按服务名或子系统筛选超时线索
先缩小范围，避免被海量日志淹没。常用命令示例：
WeChat macOS Proxy
下载
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
- 查所有含 watchdog 超时的日志（全局扫描）：
log show --predicate 'eventMessage contains "watchdog timeout" OR eventMessage contains "wdog"' --last 7d - 聚焦 launchd 管理的服务启动超时：
log show --predicate 'subsystem == "com.apple.launchd" AND eventMessage contains "timeout"' --last 24h - 检查图形界面相关服务（如 WindowServer、CoreDisplay）响应延迟：
log show --predicate 'process IN {"WindowServer", "coreduetd", "symptomsd"} AND (eventMessage contains "timeout" OR eventMessage contains "not responding")' --last 1h
结合时间窗口分析超时上下文
单条“timeout”日志意义有限，必须拉取前后几分钟完整流，观察触发前是否有资源争抢、驱动加载失败或内存压力提示：
- 以某次 watchdog timeout 时间点为锚，查前后 5 分钟：
log show --start "2026-07-08 22:15:00" --end "2026-07-08 22:25:00" --style syslog - 导出该时段全部日志供离线细读：
log show --start "2026-07-08 22:15:00" --end "2026-07-08 22:25:00" > ~/Desktop/watchdog_context.txt - 若怀疑是某次唤醒后超时，可用 --last boot 替代绝对时间，自动匹配最近一次开机全过程。
关联 shutdown cause 判断是否已引发系统级中断
频繁的服务超时可能升级为内核级故障。检查是否伴随非正常关机证据：
- 提取最近所有关机原因代码：
log show --predicate 'eventMessage contains "Previous shutdown cause"' --last 30d - 重点留意值为 5（温度过高）、-128（电源异常）或 3（Kernel Panic）的记录——这些往往由底层服务持续无响应触发看门狗复位所致；
- 若发现 shutdown cause 与某次 watchdog timeout 时间高度重合，基本可确认该超时是系统崩溃的直接诱因。
