Spring Boot 的 Maven 插件不写 Dockerfile 也能出镜像，代价是 JRE 版本、堆大小、镜像里装不装 shell 全由 buildpack 替你定，512MB 的容器会直接起不来。

同一句 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）反模式，按问题整理我目前更倾向采用的做法：从 changelog 怎么组织、changeSet 怎么命名，到大表 DDL、K8s 下的锁和回滚，最后是 CI 里怎么把这些挡住。

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