journalctl 查不到 Java 服务日志，是因为服务未由 systemd 管理、service 文件未重载或启用、进程被 fork 导致 systemd 失控、或 StandardOutput/StandardError 被错误配置为 null 或文件重定向。
journalctl 查不到 Java 服务日志？先确认服务是否由 systemd 管理
只有用 systemd 启动的 Java 服务（比如通过 your-app.service 文件注册的），journalctl 才能捕获其标准输出/错误。如果你是直接在终端执行 java -jar app.jar，日志默认不会进 journal，此时 journalctl -u your-app 必然查不到任何内容。
常见误判点：
- 服务文件没重载：修改
/etc/systemd/system/your-app.service后，漏掉sudo systemctl daemon-reload - 服务没真正启用：只写了 service 文件，但没运行
sudo systemctl enable your-app和sudo systemctl start your-app - Java 进程被 fork 掉了：比如脚本里用了
&后台启动、或nohup，systemd 就会“丢失”主进程，日志断连
service 文件必须配置 StandardOutput 和 StandardError
默认情况下，systemd 会把服务的标准输出和错误重定向到 journal，但前提是没被显式覆盖。如果你在 service 文件里写了 StandardOutput=null 或重定向到文件（如 StandardOutput=/var/log/app.log），journalctl 就看不到日志了。
正确写法（推荐保留 journal 集成）：
立即学习“Java免费学习笔记（深入）”；
StandardOutput=journal StandardError=journal
如果确实要同时落盘+进 journal，可用：
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
StandardOutput=journal+file:/var/log/your-app/stdout.log StandardError=journal+file:/var/log/your-app/stderr.log
注意：journal+file: 是 systemd 240+ 版本才支持，麒麟 V10 SP3（基于 kernel 4.19 + systemd 239）可能不支持，建议先查版本：systemctl --version
journalctl 常用排查命令和过滤技巧
查不到日志时，别只盯着 -u，先确认服务名拼写、单位类型、时间范围：
- 服务名是否带
.service后缀？journalctl -u your-app.service比journalctl -u your-app更稳妥 - 服务是否启动失败？加
--since "2 minutes ago"缩小范围：journalctl -u your-app.service --since "1 hour ago" | grep -i "exception\|error\|failed" - Java 启动慢，日志可能在启动初期就刷过去了：用
-n 200多取几行，或加--no-pager防止截断 - 想看完整启动上下文（含内核、systemd 初始化日志）：去掉
-u，用journalctl _SYSTEMD_UNIT=your-app.service—— 这个匹配更底层，有时比-u更准
Java 应用自身日志和 journal 的关系容易混淆
journalctl 只管你进程 stdout/stderr 输出的内容；而像 Spring Boot 的 application.log、Tomcat 的 catalina.out 是应用自己写的文件，不在 journal 范围内。两者不是替代关系，而是并存关系。
典型混合场景：
- Spring Boot 默认把 INFO 及以上日志打到 stdout → 进 journal
- 但如果你在
application.properties里配了logging.file.name=/var/log/app/app.log，那这部分日志就只写文件，不进 journal - 所以看到
journalctl有启动成功信息，但application.log里没记录 HTTP 请求——说明日志框架被重定向了
真正难缠的是日志“分裂”：一部分在 journal，一部分在文件，还有一部分被 Logback 的 SiftingAppender 分到不同路径。这种时候，得回到应用日志配置本身，而不是只盯 journalctl。
