FailureAnalyzer仅生成人类可读诊断报告，不自动修复；其analyze()方法对不匹配异常类型必须返回null以保障链式匹配；PortInUseFailureAnalyzer通过BindException提取端口与地址并结合配置精准定位；自定义Analyzer需避开日志初始化失败陷阱且仅作用于上下文刷新阶段异常。
FailureAnalyzer 不会、也不能自动修复问题，它只负责把启动失败的原始异常“翻译”成人类可读的诊断报告。所谓“自动修复提示”，其实是明确的操作建议，不是代码级自动执行。
为什么 FailureAnalyzer 的 analyze() 方法常返回 null
这是最常被忽略的设计前提：每个 FailureAnalyzer 实例只处理自己关心的异常类型。如果 analyze(Throwable failure) 无法识别当前异常（比如你写的自定义分析器只匹配 IllegalArgumentException，但实际抛出的是 BeanCreationException），就必须返回 null —— 否则会阻断后续其他 Analyzer 的匹配机会。
常见误操作包括：
- 在
analyze()里没做instanceof判断就直接强转，导致 NPE 或 ClassCastException - 捕获了嵌套异常（
getCause()）但没递归检查，错过根因（例如BeanCreationException套着SQLException） - 用
contains检查异常消息字符串，而不是靠类型判断，结果匹配过宽或过窄
PortInUseFailureAnalyzer 为什么能准确定位端口和进程
它不依赖日志文本解析，而是从原始 BindException 中提取关键信息：getAddress() 和 getPort()。Spring Boot 3.2+ 还会尝试调用 DiagnosticContext.getEnvironment() 获取当前生效的 server.port 配置值，确保提示的端口号与你配置的一致，而不是异常里硬编码的默认值。
真正起作用的是它对异常上下文的利用方式：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 不只看
BindException，还检查其getCause()是否为SocketException，覆盖更多底层网络异常场景 - 在
getAction()返回的建议里，明确写出命令示例：lsof -i :8080（macOS/Linux）或netstat -ano | findstr :8080（Windows） - 不会建议“重启电脑”这种无效操作，所有建议都可立即验证、有明确预期结果
自定义 FailureAnalyzer 必须绕开 LoggingFailureAnalyzer 的陷阱
如果你的自定义 Analyzer 在日志系统初始化失败时触发（比如 logback-spring.xml 语法错误），它大概率会失效——因为 LoggingFailureAnalyzer 本身需要日志系统支撑，而此时 LoggerContext 已损坏。你会看到类似 NullPointerException at LoggingFailureAnalyzer.analyze(...) 的二次报错，掩盖真实问题。
排查真实根因要换思路：
- 启动时加 JVM 参数：
-Dorg.springframework.boot.logging.loggingsystem=none -Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener，跳过 Spring Boot 日志抽象层，直连 Logback 状态监听器 - 检查 JAR 包内
BOOT-INF/classes/下是否存在logback-spring.xml或logging.config指向的文件路径是否拼写错误 - 不要在自定义 Analyzer 的
analyze()里调用log.info()或任何依赖 SLF4J 的操作，避免触发日志系统再次初始化
最易被忽略的一点：FailureAnalyzer 只在应用上下文刷新（refreshContext()）阶段生效，对 @PostConstruct、CommandLineRunner 或 Bean 初始化后抛出的异常完全无感。这类问题得靠 @EventListener 或 AOP 拦截，别指望 FailureAnalyzer 覆盖全部场景。
