journalctl -b 是查本次启动完整日志的首选命令，它结构化、时间准、来源清；dmesg 专用于内核早期硬件/驱动问题；/var/log/ 下文本日志仅作交叉验证。
直接看本次启动的完整日志用 journalctl -b
绝大多数现代 Linux（Ubuntu 22.04+、CentOS 7+、Debian 11+）都用 systemd，journalctl -b 就是查“这次开机从内核加载到桌面/服务就绪”的全部记录，不混入其他运行时日志。它比翻文件靠谱得多——因为 journal 是结构化存储，时间戳准、来源清、服务归属明确。
-
journalctl -b默认按时间正序输出，最新条目在最后；加--no-pager可避免卡在 less 里 - 想快速扫错误？用
journalctl -b -p err——只显示err及更严重级别（crit/alert/emerg），跳过大量 info 级干扰 - 别用
journalctl | grep failed：journalctl 自带过滤，管道进 grep 会丢失优先级、服务名等元数据，且可能截断长行 - 如果系统刚崩了进不去图形界面，SSH 也连不上，先别急着重装——只要还能进单用户模式或 recovery shell，
journalctl -b通常仍可用（journald 默认内存缓存，但若启用了持久化，日志已落盘到/var/log/journal/）
硬件/驱动问题优先查 dmesg，不是 journalctl
dmesg 输出的是内核环形缓冲区原始内容，从 GRUB 把控制权交给 kernel 的第一行开始，包括 CPU 检测、内存映射、PCIe 设备枚举、驱动 probe 成败——这些信息 journalctl -b 会收录，但会被格式化、截断，甚至因 journald 启动晚而漏掉 early boot 阶段。
-
dmesg -l err,warn比dmesg | grep -i "error"更可靠：前者按内核定义的 log level 过滤，后者可能匹配到正常字符串（比如某模块名含 “error”） -
dmesg -T加人类可读时间戳，但注意：该时间基于系统当前时钟，若 RTC 不准或 NTP 没同步，早期日志时间可能偏移；诊断冷启动失败时，优先用默认无-T的输出 - 如果
dmesg输出为空或极短，说明内核可能根本没跑起来（如 initramfs 解包失败、根文件系统找不到），这时要回头查 GRUB 参数或 initrd 内容，而不是继续翻日志 -
dmesg缓冲区大小有限（通常 64K~1M），老消息会被覆盖；若需长期保留，得靠systemd-journald持久化或手动执行dmesg > /tmp/dmesg.boot抓快照
/var/log/boot.log 和 /var/log/messages 只作辅助验证
这些文本日志是传统 SysVinit 遗留机制，现在多数发行版已不主动写入它们——除非你手动启用了 rsyslog 转发或禁用了 journald。它们的价值在于交叉验证：比如 journalctl -b 显示某服务启动超时，而 /var/log/messages 里同一时间点有 “SELinux denied” 记录，那问题大概率不在服务本身。
-
/var/log/boot.log在 CentOS/RHEL 系统中可能有内容，但在 Ubuntu/Debian 上常为空或仅含 minimal 初始化信息；别把它当主依据 -
/var/log/messages（RHEL 系）或/var/log/syslog（Debian 系）是 syslog 守护进程汇总的日志，但 systemd 下很多消息根本不会走这路，尤其 early boot 阶段 - 用
tail -n 50 /var/log/messages快速瞄一眼没问题，但若发现关键报错不在里面，别怀疑自己漏看了——很可能它压根就没被 syslog 接收 - 如果
journalctl和dmesg都没线索，再检查/var/log/journal/目录是否存在、是否可读；若为空，确认Storage=persistent是否在/etc/systemd/journald.conf中启用
查历史启动（比如上一次成功/失败）必须用 -b -1，不能靠文件修改时间
系统重启后，/var/log/ 下的文本日志文件不会自动按启动会话切分，而 journal 会为每次 boot 分配唯一 ID。所以想对比“这次崩了 vs 上次好好的”，journalctl -b -1 是唯一可靠方式。
-
journalctl -b -1查上一次；journalctl -b -2查上上次……最多支持到-b -10左右，具体取决于SystemMaxUse配置 - 别用
ls -lt /var/log/看messages文件时间戳来判断“上次启动”——日志轮转（logrotate）会改时间，且多会话下文件内容是混在一起的 - 如果
journalctl -b -1报错 “No such boot ID”，说明该次启动日志未持久化保存，要么 journald 没配置持久化，要么那次启动时磁盘已满或 journal 目录权限异常 - 需要导出某次启动日志做离线分析？用
journalctl -b -1 --all --no-pager > boot-previous.log；--all确保不丢二进制字段（如堆栈），--no-pager避免分页器污染输出
真正卡住的时候，90% 的人会反复刷 journalctl -b 却忽略 dmesg -l err,warn 里的硬件报错，或者把空的 /var/log/boot.log 当成证据。启动日志不是“看全了就行”，而是要分层：内核层（dmesg）、初始化层（journalctl -b）、服务层（journalctl -u xxx），每层失效点不同，工具也不同。
