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

基于 Kubernetes 1.35 官方文档和实操验证，梳理 VPA 的 InPlaceOrRecreate 模式、原地调容的工作链路，以及落地时最容易踩的坑。

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

给 mirrord OSS 做一套按 namespace 授权的开发者接入 demo：kubeconfig 走 Kubernetes CSR API 签发，ClusterRole 集中审查能力，授权和撤销都落在 RoleBinding 这一层。

Java 25 跑在 Kubernetes 上，默认堆只用了 25%，CPU 节流的影响也比预期大，这几组实验数据和值得优先验证的配置项放在一起。

通过一个 Spring Boot + MySQL + kind 的 Demo，记录如何用 mirrord 让本地进程「假装」自己是 K8s 里的 Pod，无需重新打镜像就能接入集群资源进行调试。

本地用 Kind 跑 Spring Boot 微服务，工具按问题挑：镜像循环慢就上模块级增量构建，改完代码快速验证交给 Tilt，IDE 打断点用 mirrord，GitOps 演练单独拉一个 ArgoCD。