OpenFeature 加 flagd 的全链路场景下，一个前后端共享语义的新 flag 要灰度，先升级后端还是先升级前端？两条路径的风险对比下来，先让 backend 兼容、再升级 frontend 通常少踩一些坑。

Pete Hodgson 在 KubeCon NA 2025 讲《Feature Flags Suck!》：加开关的代价大多在水下，清理要靠元数据和激励对齐，更根本的是从源头少加，标准那一层交给 OpenFeature。

没有 Istio/Linkerd 的环境下，Shop Platform 用 Spring Cloud Gateway MVC 的自定义 Predicate + Redis Set + Caffeine 本地缓存，实现按 buyerId 的用户级灰度路由；并讨论配合 OpenFeature 做下游代码路径灰度的演进路径。

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

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