Cloudflare 这次补的不是新模型，也不是完整实验平台，而是一个工程团队每天都会碰到的东西：Flagship，feature flag 服务。
它解决的问题很朴素：代码不用重新部署，也能控制某个功能对谁可见、放给多少用户、下发什么配置。上线之后有刹车，比上线本身更值钱。
对已经在用 Workers 的团队，这不是多一个菜单。它意味着灰度、配置、边缘运行时开始被拧到同一条发布链路上。省事是真的，粘性也是真的。
Flagship 做的是发布控制，不是实验分析
按 Cloudflare 文档，Flagship 现在能覆盖几类基础能力。
| 能力 | 文档里能看到的做法 | 对团队的意义 |
|---|---|---|
| Feature flag | 控制功能可见性 | 不重新部署，也能开关功能 |
| Targeting rules | 按用户属性下发不同值，支持比较操作、AND/OR、顺序评估 | 做分群灰度，不必全量硬上 |
| Percentage rollouts | 按百分比逐步放量，使用一致性哈希 | 同一用户稳定拿到同一结果 |
| Multi-type variations | 支持 boolean、string、number、JSON object | 不只开关，也能下发配置块 |
它和 Workers 绑得很近。开发者可以通过原生 Workers binding，在 Worker 里直接评估 flag。文档也强调了类型安全方法，以及默认 fallback。
它也兼容 CNCF OpenFeature。通过 @cloudflare/flagship SDK，flag 评估可以跑在 Workers、Node.js 或浏览器里。Cloudflare 的说法是，切换 provider 只需要改配置。
底层分发用的是 Cloudflare KV 基础设施。管理侧则通过 Cloudflare dashboard 创建、更新、删除 flag，并把 flag 组织进 app，对应项目或服务。
边界也要说清。
目前材料能证明的是 feature flag、定向、百分比 rollout、多类型 variation 和配置分发。它不能被直接写成完整 A/B 测试分析产品。实验统计、指标归因、商业分析，这些信息现在看不到。
这也不是行业首创。Feature flag 是成熟赛道。Cloudflare 的新意在位置：它把这件事放到边缘运行时和开发者平台里。
谁受影响：Workers 团队最先动，灰度团队要重新算账
最直接受影响的是两类人。
一类是 Cloudflare Workers 开发者。如果服务已经跑在 Workers 上，Flagship 会让灰度发布和配置下发更顺手。请求进边缘节点时就能评估 flag，少接一套外部系统，少维护一段调用链。
这类团队可以做的动作很具体：新功能灰度、地区策略、用户分群、轻量配置下发，可以先放到 Flagship 里试。尤其是前端、轻后端、边缘 API，收益更直接。
另一类是负责灰度发布和配置管理的工程团队。对他们来说，问题不是“要不要 feature flag”。问题是发布控制应该放在哪里。
| 路线 | 好处 | 现实约束 |
|---|---|---|
| 用 Cloudflare Flagship | 和 Workers、KV、dashboard 更贴近，边缘场景更顺 | 更依赖 Cloudflare 的运行时、管理界面和发布流程 |
| 继续用独立 feature flag 服务 | 平台中立性更强，跨云、跨运行时更自然 | 需要维护额外集成，边缘链路可能更绕 |
| 自建配置/灰度系统 | 控制权更完整 | 运维、权限、审计、稳定性都要自己扛 |
所以，已经重度使用 Workers 的团队，可以更积极地评估 Flagship。它补的是发布基础设施。
还在选型的团队，最好先慢一点。不是因为 Flagship 不好，而是要把迁移成本算完整：运行时、配置数据、权限体系、dashboard 操作习惯、发布流程，都会变成后续成本。
负责采购或平台选型的人，至少该延后“一刀切迁移”的决定。可以先把低风险项目放进去，看团队使用成本和治理边界，再决定要不要扩大。
真正的看点：OpenFeature 降焦虑，平台集成造粘性
我更在意的不是 Cloudflare 又补了一个开发者工具，而是它把“发布”这件事继续平台化。
过去很多团队的发布控制分散在几处：代码仓库、CI/CD、配置中心、灰度系统、监控告警。Cloudflare 的路线更直接：运行时、数据面、配置分发、灰度评估，尽量压到同一个边缘平台。
对开发者，这是少接几套系统。对平台，这是多拿住一段关键链路。
方便当然是真的。
如果你的服务本来就在 Workers 上，flag 评估离用户更近，工程体验会变好。灰度发布、地区策略、用户分群、配置块下发，都能在同一套 Cloudflare 体系里完成。
但别把 OpenFeature 误读成完全自由。
OpenFeature 解决的是代码接口层的可迁移性。业务代码不必写死在某一家 feature flag 厂商 API 上，这是好事。
真正的迁移成本不只在 SDK。它还在运行时、KV 分发、权限模型、dashboard、团队流程，以及事故处理习惯里。
“天下熙熙，皆为利来。”放到云平台里，就是开发者要效率，平台要控制面。双方都合理，问题是别只看效率，不看控制权。
这件事像早期云厂商把数据库、日志、队列、函数计算一层层做进平台。不完全一样，但逻辑相近：每一个基础设施都在降低开发成本，也在增加离开的摩擦。
Flagship 的分水岭不在“有没有 feature flag”。大家都有。分水岭在于，谁能把发布控制放到最靠近用户、最靠近运行时的位置。
接下来最该观察的不是口号，而是几个硬变量：价格怎么定，权限和审计怎么做，大规模配置分发的限制是什么，和现有 feature flag 服务相比迁移成本有多高。
这些没看清之前，Flagship 更适合被当成 Workers 平台能力来评估，而不是替代所有灰度系统的答案。
Cloudflare 这次做对了一件很实用的事。只是越实用的基础设施，越容易变成路径依赖。工具最有力的时候，往往不是让你惊叹，而是让你懒得离开。