dmesg -t -l err 是最直接有效的致命错误查看方式，因它按内核定义的err级别精准过滤，避免grep -i error的漏报（如failed command无“error”字）和误报（如info日志含“error code”）。
dmesg -l err 是查看致命错误最直接有效的方式，不是 dmesg | grep -i error，后者漏报率高、误报多。
为什么 dmesg -l err 比 grep -i error 可靠
内核日志的“错误”是通过日志级别（level）标记的，不是靠正文是否含“error”字眼。很多真实致命错误根本没写这个单词：
-
ata1.00: failed command: READ FPDMA QUEUED—— 级别是err，但正文无“error” -
nvme 0000:01:00.0: reset controller—— 常见于链路超时，级别为err -
PCIe Bus Error: severity=Fatal—— 明确标出 Fatal，但grep -i fatal在旧内核里可能不生效，而-l err一定捕获
用 grep 容易把 error 当成普通名词匹配（比如 error code 出现在 info 日志里），反而掩盖真正 err 级别报错。
dmesg -l err 必须搭配 -T 或 --time-format=iso
裸跑 dmesg -l err 输出的是内核启动后偏移秒数（如 [ 1245.678901]），对不上业务故障时间点。必须加时间格式化：
-
dmesg -T -l err—— 最常用，转为本地可读时间（如Tue Sep 21 21:33:12 2026） -
dmesg --time-format=iso -l err—— 更稳，不受 NTP 大步长校正或虚拟机时钟漂移影响，输出如2026-09-21T21:33:12.456789 - 别用
dmesg -H查错误：它默认倒序+着色，适合浏览，但会隐藏部分原始字段，且老内核不支持
遇到空输出，不是没错误，而是缓冲区被刷没了
执行 dmesg -T -l err 后如果没输出，常见原因有：
- 环形缓冲区已满，旧的
err日志被新info日志覆盖（尤其在高负载或长时间运行的边缘设备上） - 系统启用了
kernel.dmesg_restrict=1（RHEL/CentOS 8+、Debian 11+ 默认），普通用户看不到完整内容，需sudo dmesg -T -l err - 内核日志根本没落盘，重启即丢；此时应立刻补查持久化日志：
journalctl -k -p err --since "2 hours ago"
注意：journalctl -p err 和 journalctl -k -p err 不是一回事——前者查所有 unit 的错误（包括 systemd、服务崩溃），后者才专盯内核日志。
进阶：只看 PCIe Fatal 错误这类子类
某些硬件错误（如 PCIe AER）会在 err 级别里带明确关键词，可进一步过滤：
dmesg -T -l err | grep -i "aer\|fatal\|uncorrectable\|link.*down\|corrected hardware error"- 特别注意
corrected hardware error：虽标“corrected”，但高频出现就是 ECC/内存/链路隐患信号，不能忽略 - 看到
PCIe Bus Error: severity=Fatal，立刻执行：lspci -vv -s $(echo "0000:xx:xx.x" | cut -d' ' -f4)（提取 PCI 地址后查设备详情）
真正难的不是命令怎么敲，而是区分哪些 err 是偶发可恢复的（如单次 PHY reset），哪些是持续恶化信号（如 5 分钟内出现 3 次 nvme I/O timeout）。这时候时间戳对齐和上下文连读比单行过滤更重要。
