actuator 可以与业务共用端口，也可以通过单独管理端口运行。单独端口能隔离外部流量并统一指标路径，但会引入独立的内嵌 Web 服务与线程池；探针若未配置回主端口可能出现健康误报，采集端口也需在 Service 与 ServiceMonitor 中对齐。

同一份 Spring MVC + 虚拟线程的 SSE 代码，4 核 8 GB 容器里 Tomcat 每条连接占 112.3 KB 存活堆（移到堆外后 98 KB），5.2 万条撞堆墙；换 Jetty 是 18.3 KB，WebFlux 每连接 RSS 最低。

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 通常少踩一些坑。