不用 Spring Cloud Config Server 也能把 feature flag 做出来：Gateway、微服务和 React 三个角色共用同一个 flagd，热加载方案选型和 OFREP 跨栈一致性都在 kind 环境里验证过。

BFF 调用多个下游 microservice 时，连接池要不要按服务隔离？connectTimeout / readTimeout 怎么 per-service 配置？Spring Boot 3.5 内部服务用 h2c 要避哪些坑？把这三个常见问题理清楚。

Spring Boot 3.5 + Java 25 微服务下，记录我如何用一个共享 starter 统一出站 HTTP 客户端的身份传播、错误语义、可观测性和弹性。

从现有 Spring Boot 项目抽象出 Maven Archetype 的一段流程记录，包括 Velocity 转义、.gitignore 被过滤、post-generate 钩子、git-commit-id 插件等真实踩坑点。

数据库通常是微服务里比较关键的依赖之一，这套仓库在它身上花的心思集中在 HikariCP 连接池调优、open-in-view: false、@EntityGraph 防 N+1、@Transactional 传播行为、Testcontainers @ServiceConnection 和 Flyway 进阶实践。

Redis 在 Shop Platform 里同时承担缓存、限流、分布式锁、Bloom Filter 和 Lua 原子操作，对应要配的是 Lettuce 连接池、序列化策略、Redisson 锁、Bloom Filter 自动配置和 Lua 脚本加载方式。

Spring Boot 3.5 加 Spring Kafka 3.3 把 Kafka 该配的基本都配得起来，这套仓库落地的是消费者并发模型、生产者的 acks 与 retries、序列化选型、offset 提交策略、死信处理和 @RetryableTopic。

应用层 Metrics 埋点的边界：自动埋点覆盖到哪、@Observed 怎么用、高低基数字段怎么分、手动 Observation API 什么时候上，以及和 Prometheus、OTel 的关系。埋点 API 是 Micrometer 的抽象层。

开关语义和供应商解耦之后，剩下的问题是 flag 从哪儿读、改完怎么不重启就生效。shop 项目这一版把这两件事分别交给 Spring Config 和 Configuration Watcher。

Spring Boot 3.5 + Java 25 下的 OpenTelemetry 接入：尽量让自动配置去做，启用虚拟线程，用 JFR 补上 profiles，把 Traces / Metrics / Logs / Profiles 串起来。