同一句 Class.forName 在 IDE 里跑得好好的，打成 fat jar 就报找不到类：看打包形态给的是哪个 application class loader，也看这条线程的 TCCL 是继承创建者的还是被 ThreadFactory 设过。

两张明细表只共享半个唯一键，同层 JOIN 之后才聚合，分页接口那 40 秒慢查询就出在中间被 DISTINCT 压回去的那些行上；拆成三步后这组参数下结果逐行一致。

同一个 JVM 里只有走 Confluent 序列化器的 topic 发不出去：它的配置类在静态初始化时按 TCCL 解析默认值的类名，而 fat jar 下那个 TCCL 看不见 BOOT-INF/lib；之后这个类不会再重新初始化，实例只能换掉。

Java 25 加 Spring Boot 3.5 的微服务上 Kubernetes，我给自己定了一份运行时基线，覆盖镜像、探针、优雅停机、滚动与回滚、可观测性，每块都同时写现状和差距。

OpenFeature 加 flagd 的全链路场景下，一个前后端共享语义的新 flag 要灰度，先升级后端还是先升级前端？两条路径的风险对比下来，先让 backend 兼容、再升级 frontend 通常少踩一些坑。

结合最近五年的官方文档、工程资料与技术文章，整理 Spring Boot 3.5 + Java 25 微服务中 Resilience4j 在 HTTP、Redis、Kafka、DB 外部调用上的使用边界与实践建议。

软件供应链的最小基线按问答展开：CycloneDX 生成 SBOM、cosign keyless 给镜像签名、再把 SBOM 作为 attestation 绑到镜像上，为什么这么做和绕不开的 tradeoff 一并回答。

围绕真实项目里常见的 Liquibase（XML）反模式，按问题整理我目前更倾向采用的一些做法：schema 归属、master changelog 组织、changeSet ID 命名、XSD 版本、初始化策略、expand-and-contract、大表 DDL、K8s lock、回滚 / tag、context / labels、Testcontainers 验证与 CI 检查。

四种常见的 REST API 版本管理策略各有代价，Spring Boot 4 的原生支持进来之后，跟历史实现方案怎么取舍、哪些坑容易踩到，得重新对一遍。

Step-by-step 指南，按这套步骤通常可以在 Spring Boot 3.5 BFF 工程里跑起第一个 @HttpExchange 出站客户端。