H5 应用容器和奖池活动条由 Cloudflare Workers 上的容器页、overlay 和 EKS 里四个 Spring Boot 服务组成，结构由同源入口、一张凭证两处验签、钱只走交易平台、推送层不存状态和 overlay 固定入口发版五条决策定下。

官方 starter 只管 SDK 和 OTLP 日志 exporter：traces、metrics 还在 micrometer 的两个模块下，Logback appender 仍要手工装三步，profiles 整段落在应用之外。

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 一并回答。