在 OpenFeature + flagd 的全链路场景下，给一个需要前后端共享语义的新 flag 做灰度发布，应该先升级后端还是先升级前端？本文通过实际案例对比两种升级路径的风险，论证为什么先 backend 兼容升级、再升级 frontend 是更稳妥的策略。
Posts for: #openfeature
Spring Boot 3.5 + Java 25 + React：在 K8s 里跑通一套跨链路 OpenFeature flag
记录一次 SB3.5 + Java 25 + kind 环境下的方案试验：不用 Spring Cloud Config Server / Netflix 套件，做出一套 Gateway + 微服务 + React 的 OpenFeature demo，并复盘 flagd、OFREP、热加载和部署过程里遇到的几个坑。
没有 Service Mesh，用 API Gateway 做用户级灰度
没有 Istio/Linkerd 的环境下，Shop Platform 用 Spring Cloud Gateway MVC 的自定义 Predicate + Redis Set + Caffeine 本地缓存，实现按 buyerId 的用户级灰度路由；并讨论配合 OpenFeature 做下游代码路径灰度的演进路径。
Spring Boot 微服务中的 Feature Toggle 实战：OpenFeature Property Provider + K8s ConfigMap 热更新
在微服务中引入 Feature Toggle 能力，通过 OpenFeature SDK 实现供应商无关的特性开关。本文结合 shop 项目的实际实现，讲解 OpenFeature Property Provider 如何从 Spring Config 读取 flag、K8s ConfigMap 挂载 + Configuration Watcher 触发热更新的链路，以及从静态 YAML 到生产级动态管理的演进路径。