feature flag 比 git 分支更适合渐进式发布，因其将功能可见性与代码提交解耦，实现运行时开关控制；推荐使用 launchdarkly 或 flagsmith 等成熟平台，规范命名、避免嵌套逻辑、分步清理废弃 flag，并与 ci/cd 集成实现自动灰度。

Feature Flag 为什么比 git 分支更适合渐进式发布

物理分支（比如 feature/login-v2）在长期并行开发中会带来合并冲突、测试覆盖不全、环境漂移等问题；而 Feature Flag 把“代码是否生效”的控制权从 Git 历史转移到运行时，让同一份主干代码能按需开启/关闭功能。这不是替代 Git 分支的协作方式，而是把“功能可见性”和“代码提交”解耦——上线前不用等分支合入，灰度时不用反复切环境。

关键区别在于：分支是代码隔离机制，Flag 是行为隔离机制。你依然要用 main 分支交付，但通过 Flag 控制新逻辑是否执行。

用 LaunchDarkly 或 Flagsmith 实现运行时开关的最小可行配置

自建 Flag 系统容易陷入权限、审计、降级逻辑等陷阱，建议初期直接接入成熟 SaaS（如 LaunchDarkly 或开源可自托管的 Flagsmith）。它们提供 SDK、Web 控制台、变更审计和 kill-switch 能力，比手写 if (process.env.FEATURE_LOGIN_V2 === 'true') 可靠得多。

openclaw-gitcode-pr-monitor

监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。

下载

• SDK 初始化必须早于任何业务逻辑，通常放在应用入口（如 main.ts 或 index.js），且需处理初始化失败的 fallback（例如默认关闭）
• Flag key 命名要带业务域前缀，避免冲突：login.v2.enable 比 v2 更易维护
• 不要在 Flag 判断里嵌套复杂逻辑——只做开关，不放状态机或路由跳转决策
• 客户端 SDK 默认有缓存，但服务端 SDK（如 Node.js）建议配合 context（用户 ID、团队 ID）做细粒度评估，否则灰度比例可能失真

如何安全地清理已下线的 Flag 和对应代码

Flag 不是永久开关，长期保留会导致代码腐化、判断链变长、排查成本上升。清理必须分两步：先删逻辑，再删 Flag 配置。

• 确认 Flag 已全局关闭至少两个发布周期，并且监控中无相关埋点上报，才开始清理
• 删除代码前，用 IDE 全局搜索 login.v2.enable 和所有相关变量（如 isLoginV2Enabled），确保无残留调用
• Flag 平台侧删除前，检查审计日志是否有近期评估记录，防止误删仍在使用的开关
• CI 流程中加入静态扫描规则，例如用 ESLint 规则检测未注册的 Flag key 字面量，避免硬编码漏管

Flag + CI/CD 如何配合实现自动灰度发布

单纯靠人工在 Flag 平台点开关，无法支撑高频发布节奏。要把 Flag 状态纳入部署流水线，实现“发版即灰度”。

• 在 CD 阶段（如 GitHub Actions 的 deploy-to-staging job）调用 Flagsmith/LaunchDarkly API，将新 Flag 设置为 off；上线后触发一个独立 job，按预设策略（如 5% 用户）打开
• 避免在部署脚本里写死 Flag 值，应通过环境变量注入（FLAG_KEY=login.v2.enable FLAG_VALUE=true），方便不同环境差异化控制
• 如果使用 Argo Rollouts 或 Flagger，可将 Flag 状态作为 rollout success condition 的一部分：只有当 login.v2.enable 在 10% 流量下错误率
• 注意 Flag 评估延迟：某些 SDK 默认 30 秒拉取一次配置，对秒级灰度不友好，需调大 pollInterval 或启用 streaming 模式（如 LaunchDarkly 的 LDClient.stream）

最常被忽略的是 Flag 的上下文污染——比如用请求 IP 做灰度依据，但在 CDN 或负载均衡后拿到的全是内网地址；或者用用户登录态字段，却没考虑未登录游客场景。这类细节不提前验证，灰度就变成随机开关。