前端平台能力如何灰度发布与回滚

平台能力一旦被多个业务线复用，发布风险就不能再按普通页面处理。我的原则是：底层能力默认要可灰度、可观测、可降级、可回滚。

第一步是版本分层。核心引擎、插件、业务应用、SDK 要有清楚的版本边界。比如低代码平台里 Core Engine 不能和某个业务插件绑死；埋点 SDK 也不能要求所有业务同一天升级。

第二步是兼容策略。Schema、动作模板、埋点协议、AST 结构这类协议型数据，一旦上线就要考虑向后兼容。新增字段可以默认忽略，废弃字段要有迁移窗口，破坏性改动要配套版本判断。

第三步是灰度入口。可以按租户、业务线、用户比例、页面范围或功能开关逐步放量。平台能力尤其适合先在内部业务或低风险租户验证，再扩大到核心客户。

第四步是运行时降级。SDK 可以远程关闭某些采集能力；低代码插件加载失败时可以降级为空状态或只读状态；HATEOAS 动作缺失时 UI 要区分不可用、加载失败和无权限；Agent Gate 异常时要能回退到人工 Review。

第五步是回滚和观测。发布前要定义回滚条件，比如错误率、白屏率、接口失败率、插件加载失败率、关键埋点丢失率。回滚不能只依赖重新发版，最好有配置开关、版本固定和缓存失效策略。

如果用一句话总结，平台发布不是把代码推上去就结束，而是要让新能力在真实业务里逐步被消费，并且在出问题时能快速缩小影响面。