电脑从不“突然坏掉”：看懂日志，十分钟学会像侦探一样排障
先说结论
电脑很少会“毫无征兆地坏掉”。大多数时候，它早就把线索写进了日志：某个磁盘逐渐变满、某个服务先出现警告、某次 DNS 查询失败、某个进程反复启动又退出。真正的排障，不是看到红色报错就马上重装系统，而是像侦探一样回答五个问题：什么时候发生？谁发生了？严重程度怎样？前后还发生了什么？修好后能不能验证？
这篇文章不把日志讲成只有工程师才懂的黑话，而是把它比作电脑每天写的日记。你会看到 Windows 11、Ubuntu 26.04 和 macOS 26 的真实采集输出，拿到三套不依赖第三方服务的只读脚本，还能把同一套思路交给 Agent 自动执行。即使你是小学生，也应该能看懂其中大部分；如果你是开发者或运维人员，则可以直接把方法带回生产环境。
图 1：电脑不是神秘黑盒，它更像一个会写日记、会留下脚印的房间。
电脑为什么会“突然”出问题
孩子问：“电脑刚才还好好的，为什么现在打不开了？”大人常常也只能回答：“可能系统抽风了。”
但电脑通常不会真的“抽风”。它更像一座有值班记录的学校：
- 保安会记下哪扇门什么时候打开过；
- 老师会记下哪个程序什么时候开始上课、什么时候离开；
- 仓库管理员会记下哪个货架已经没有空间；
- 校车调度员会记下某个地址有没有找到。
这些记录，就是日志（log）。日志不是专门给机器看的，它首先是给“未来的自己”看的：当问题发生时，你可以沿着时间、对象和结果把故事拼回来。
图 2：先出现空间变少，再出现写文件失败，最后才可能表现为页面超时。最后一幕不一定是根因。
日志到底记录了什么
时间：事情发生的顺序
日志通常带有时间戳。时间戳像作业本上的日期，也像监控录像右下角的时间。它的价值不在于“看起来很专业”，而在于帮你判断先后顺序。
如果页面在 10:04 超时，而磁盘在 10:02 已经只剩很少空间，那么“网络坏了”可能只是表面现象；真正的故事可能是程序在 10:02 开始写不进文件，10:03 服务退出，10:04 用户才看到网页打不开。
对象：到底是谁在说话
一条日志一般会告诉你来源：Windows 的事件提供程序、Ubuntu 的 systemd 服务、macOS 的进程名，或者某个应用自己的模块名。
这就像班级里传来一句“有人把门关了”。如果不知道是谁做的，你只能猜。日志告诉你“谁写下这句话”，就能把范围缩小：是磁盘、DNS、SSH、数据库、浏览器，还是你的应用？
级别：红灯不一定是事故终点
INFO 可以理解为“我做了什么”；WARNING 是“我发现了风险”；ERROR 是“这一次动作失败了”；FAULT 往往代表更严重的系统级异常。
但级别不能单独证明根因。某些程序会把普通重试写成 ERROR，也有系统会把真正重要的线索写成普通信息。日志级别像交通灯：红灯提醒你先看这里，但你还要观察车辆从哪里来、往哪里去。
图 3：级别是“导航”，不是“判决书”。看到 ERROR 后，别立刻认定这就是根因。
教孩子也能学会的五步排障法
先定时间
不要问“最近为什么不稳定”，先问“第一次看到问题是什么时候”。时间范围越小，日志越容易读。
例如：“从今天下午 3 点到 4 点，只看这一个小时。”这比把整台电脑几个月的日志全部倒出来更有用。把整座图书馆搬到桌面上，不叫认真，叫让线索互相遮住。
再定对象
如果只是浏览器打不开，先看浏览器、DNS、网络接口和目标服务，不要一上来搜索整个系统的每一条错误。
如果是服务器上的任务失败，就先确认任务名称、服务名称、进程名称和对应日志源。
读级别，但不迷信级别
先看 ERROR 和 FAULT，再把它们前后几分钟的 WARNING 与 INFO 补回来。很多根因在“红色报错”前已经出现了，只是当时看起来不严重。
把零散日志串成时间线
单条日志像一句话，连续日志才像故事。把事件按时间排好，标记“先发生”“随后发生”“用户感知到”，通常会发现一个很朴素的因果链。
图 4：页面超时可能是最后的“感受”，而不是最早的“原因”。
最后做验证
修复不是“执行了命令”就算结束。修复后需要重新做一次动作：再次启动服务、再次解析域名、再次写入文件，确认相同问题不再出现。
侦探找到嫌疑人之后，还要回到现场复演。否则你只是“感觉修好了”。
图 5：把排障拆成五个小问题，孩子就能从“我不会修电脑”走到“我知道下一步该看什么”。
实验一：磁盘空间快满，为什么应用开始报错
磁盘像书包。书包不是等到拉链完全拉不上才算出问题，塞到只剩一点缝时，已经会影响拿东西。
macOS 上可以先运行：
df -h
Ubuntu 上可以加上文件系统类型和 inode 检查：
df -hT
df -ih
Windows 11 可以用 PowerShell：
Get-Volume | Select-Object DriveLetter, SizeRemaining, Size
这些命令不会删除任何东西，只是问仓库管理员“每个货架还剩多少空间”。如果你看到剩余空间很低，再去找谁占用它；不要因为看到一个大目录就立即删除。
图 6：真实采集输出已去除计算机名、用户和地址；截图表达的是证据形式，而不是某台机器的隐私。
实验二：服务启动失败，为什么网页最后才超时
服务像餐厅后厨。网页是前台，数据库、缓存和后台服务是后厨。前台说“没有菜了”，不等于前台坏了，也许是后厨早就停电。
Ubuntu 上先看失败服务：
systemctl --failed --no-pager
journalctl -b -p warning..alert --since "1 hour ago" --no-pager
Windows 上查看最近的系统和应用错误：
$since = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2,3; StartTime=$since} -MaxEvents 100
macOS 没有完全相同的 systemd 入口，但可以检查统一日志：
log show --last 1h --style compact \
--predicate 'messageType == error OR messageType == fault'
下面这张截图是 macOS 26 在真实环境里用 log show 收集到的统一日志片段。它看起来有点吵，但这正是“先缩小时间，再按进程或级别过滤”的原因：日志不是越多越好，而是要让真正相关的几行浮出来。
图 8：真实 macOS 日志截图已去敏；它展示的是系统原生输出格式和字段关系。
下面的 Ubuntu 截图来自真实 journalctl 输出。你会发现，日志里把来源、进程、时间和错误信息放在了一起；这就像值班老师写下“几点、哪间教室、谁、出了什么事”。
图 7：先看错误发生在哪个服务，再决定是否需要查看配置、端口或依赖。
在 macOS 上，我还用系统自带的 launchctl 查询一个不存在的服务，制造了一个安全的“找不到服务”示例：
图 8：失败输出本身也是线索。没有服务、服务没启动、服务启动后马上退出，是三个不同的问题。
实验三：网络请求超时，先看 DNS 还是先看应用
“网页打不开”至少可能有四类原因：域名没有解析、网络接口没有地址、端口没有监听、应用处理太慢。它们在用户眼里都像“网络坏了”，在日志里却是四本不同的日记。
先做最小验证：
getent ahosts example.com # Ubuntu
dscacheutil -q host -a name example.com # macOS
Resolve-DnsName example.com # Windows
如果 DNS 能解析，再看本机监听端口：
ss -lntup # Ubuntu
netstat -anv -p tcp # macOS
Get-NetTCPConnection -State Listen # Windows
我用一个保留给示例的不存在域名做了受控查询，输出没有泄露真实网络信息，但能展示“解析失败”的证据形态：
图 9：先判断“名字找不到”，再讨论“服务有没有启动”，不要把所有问题都叫网络问题。
Windows 11、Ubuntu 26.04、macOS 26 的入口有什么不同
三个系统的按钮和命令不同，但排障思维完全相同：找到系统的“值班记录本”，缩小时间窗口，按对象过滤，再验证。
图 10：Windows 侧重事件日志，Ubuntu 侧重 systemd journal，macOS 侧重统一日志。它们都在回答同样的四个问题。
Windows 11：事件查看器和 Get-WinEvent
图形界面入口是“事件查看器”，适合第一次接触日志的人：按“Windows 日志 → 系统”或“应用程序”浏览，并用“筛选当前日志”限定时间和级别。
PowerShell 更适合重复操作和 Agent：
$since = (Get-Date).AddHours(-4)
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Level = 1, 2, 3
StartTime = $since
} -MaxEvents 200 |
Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message
Get-WinEvent 的关键不是命令很长，而是 FilterHashtable 让系统先筛选，再把结果交给你。就像先告诉图书管理员“只找今天、只找三年级、只找数学作业”，不要让他把整个图书馆搬出来。
Ubuntu 26.04：journalctl 和 systemctl
Ubuntu 的很多系统服务由 systemd 管理。systemctl 更像“值班表”：服务是否运行、哪些服务失败；journalctl 更像“值班日志”：服务在什么时候说了什么。
systemctl status your-service.service --no-pager
journalctl -u your-service.service --since "30 minutes ago" --no-pager
journalctl -p err..alert -b --no-pager
如果服务没有输出，别急着说“没有问题”。可能是时间窗口不对、权限不够、服务名写错，或者日志已轮转。排障的每一步都要记录“我查了什么”和“结果是什么”。
macOS 26：Console 和 log show
macOS 的“控制台”应用适合边看边搜索；log show 适合脚本化。
log show --last 30m --style compact \
--predicate 'process == "your-process"'
如果只想看错误和故障，可以用：
log show --last 30m --style compact \
--predicate 'messageType == error OR messageType == fault'
统一日志可能非常多，因此时间窗口、进程过滤和输出行数非常重要。日志越多，不等于证据越多；垃圾线索太多时，真正的线索反而更难被看见。
一键自动采集脚本：只读、不上传、先保存证据
三套脚本已经放在文章附件中：
它们有四条共同边界：
- 只使用系统自带工具；
- 默认只读，不重启服务、不删除文件、不改防火墙；
- 报告写到本地指定目录，不上传第三方服务；
- 输出前遮盖 IPv4、计算机名、用户名、内网域名和常见密钥格式。
人工自动执行
Windows 11：
Set-ExecutionPolicy -Scope Process Bypass
.\collect-windows-11.ps1 -Hours 4 -OutputDirectory "$HOME\Desktop\log-report"
Get-Content "$HOME\Desktop\log-report\windows-log-report.txt" -TotalCount 80
Ubuntu 26.04：
chmod +x collect-ubuntu-26.04.sh
./collect-ubuntu-26.04.sh --hours 4 --output "$HOME/log-report"
sed -n '1,120p' "$HOME/log-report/ubuntu-log-report.txt"
macOS 26：
chmod +x collect-macos-26.sh
./collect-macos-26.sh --hours 4 --output "$HOME/log-report"
sed -n '1,120p' "$HOME/log-report/macos-log-report.txt"
先打开报告，再决定要不要继续深挖。报告只负责把案发现场整理好，不替你猜根因。
Agent 自动配置
如果让 Codex、Claude、OpenClaw、HermesAgent 或其他 Agent 帮忙，建议把下面这段提示词完整交给它：
目标：只读采集当前电脑最近 4 小时的排障证据。
硬性边界：
1. 只使用操作系统自带命令，不安装第三方工具，不上传日志。
2. 禁止删除文件、重启服务、修改防火墙、修改 DNS、修改用户或权限。
3. 先执行采集脚本，再读取报告；不要先猜根因。
4. 输出报告前遮盖完整 IP、计算机名、用户名、内网域名、密钥和令牌。
5. 把每一个结论分成“日志直接证明”“合理推测”“还需要验证”三类。
6. 如果想执行修复，必须先展示证据、风险、回滚方法，并等待人工确认。
7. 最终给出：时间线、最可能根因、替代假设、验证命令和未解决问题。
Agent 最危险的行为不是“不会写命令”，而是“没有证据就很自信”。把只读、去敏、确认和验证写进提示词，就是给它戴上安全帽。
图 11：Agent 可以提高整理速度，但最终的高风险动作仍然应该由人确认。
常见误区：看日志时最容易犯的错
只看最后一条红色错误
最后一条记录往往是“受害者”。它告诉你哪里倒下了，不一定告诉你谁推倒了它。应该把时间窗口向前扩展几分钟，寻找第一条异常。
把每个 ERROR 都当成根因
系统后台会有重试、探测、兼容性告警。没有上下文的 ERROR 只是线索，不是结论。
把“没有日志”当成“没有发生问题”
可能是查错了日志源、权限不够、时间窗口太小、日志轮转，或者程序根本没有启动到能写日志的阶段。
一上来就清空日志
清空日志就像把监控录像删掉，确实可以让房间看起来干净，但也会让你失去证据。除非有明确的保留策略和合规要求，否则不要为了“看起来舒服”删掉现场。
把完整日志发到公共聊天群
日志可能含地址、用户名、Cookie、令牌、路径和业务数据。先去敏，再分享；如果只是为了请人判断，通常只需要时间线和相关几行。
Q&A：孩子和初学者最常问的问题
日志看不懂，是不是我不适合排障？
不是。先不要试图读懂每一个单词。先找时间、来源、级别和重复出现的关键字。读日志像读侦探小说，不需要一开始就认识每个角色，先知道谁在什么时候做了什么。
一条日志能不能直接告诉我答案？
少数情况下可以，大多数情况下不能。日志更像证据，不像答案。它能证明“某个动作失败了”，但根因可能在更早的配置、权限、空间或依赖。
我只用图形界面，可以学会吗？
当然可以。Windows 事件查看器、macOS 控制台和 Linux 的服务管理界面都能帮助入门。命令行的优势是可以复制、重复、过滤和交给 Agent，不代表图形界面不专业。
为什么要去敏？我只是自己看日志。
因为排障经常需要把截图发给别人，或者交给 Agent。今天只在本机看的文件，明天可能进入工单、聊天群、备份或公开文章。养成先去敏的习惯，比出了事故再追查泄露路径容易得多。
Agent 能不能直接帮我修？
低风险、可回滚的动作可以考虑自动化；删除数据、改网络、改权限、重启核心服务等动作必须先确认。最好的 Agent 不是“什么都敢做”，而是“知道什么时候应该停下来问人”。
图 12：如果孩子能回答这三个问题，他已经掌握了排障的骨架。
最后：电脑一直在写日记，别只等它大喊“我坏了”
日志排障最重要的能力，不是背诵一百条命令，而是建立一种顺序感：先观察，再提问；先取证，再推测；先验证，再修复。
Windows 11 的事件查看器、Ubuntu 26.04 的 journalctl、macOS 26 的 log show 只是不同的日记本。真正通用的是同一套思路：缩小时间范围，定位对象，理解级别，串起时间线，最后复现验证。
如果你只记住一句话，就记住这句：
电脑不是突然坏掉的；它往往只是早就写下了日记，而我们一直没有翻到那一页。