摘要： Kubernetes中Pod频繁重启且陷入CrashLoopBackOff状态是常见难题，本文提供一套完整排查方案。首先通过kubectl get pod和kubectl describe pod确认重启次数及事件日志，重点关注OOMKilled等关键字。其次使用kubectl logs --previous查看崩溃日志，分析应用层错误如配置、依赖或代码异常。退出码137通常表示OOM，需

本文记录了一次Java线上服务内存泄漏故障的全链路排查过程。故障表现为订单服务接口响应时间飙升、吞吐量骤降，服务器CPU持续高负载，监控显示每分钟FullGC达8-12次且回收效率低下。通过标准化排查流程：先用jstat区分内存泄漏与大对象问题，分析GC日志确认FullGC类型；再结合线程快照锁定定时任务线程，使用MAT分析堆转储文件发现静态HashMap缓存占用了82%堆内存；最终定位到定时任务

先交代下背景。过去一年，我带着团队做了个基于大模型的RAG项目，日均API调用量2万+，累计调用超过100万次。从最开始的天天被坑，到现在基本稳定，中间踩过的坑没有八十也有一百。这些坑里，有些是文档里写了但你不会认真看的，有些是文档里压根不会告诉你的。我把最常遇到的几个拎出来，希望能帮你省点时间，也省点钱。这些坑看着都不大，但每一个我都真实踩过，而且不止一次。不确定性是内生的。你不能用“输入X必然

Spring Boot 3.x 搭 MyBatis-Plus 3.5.5 报，本质上就是 MyBatis 的 mappedStatement 注册环节出了问题。排查时不要浮于表面去反复改配置，直接从三个方面打桩：确认 XML 文件是否进 classpath，target 里找得到不。确认初始化时到底读了哪些 mapper，有没有被原生 MyBatis 劫持。确认接口全限定名与 XML namesp