该用但需严格规范：仅限短期灰度且逻辑简单的场景；必须集中管理、封装调用、禁止动态拼接；按需选型unleash或轻量方案；严禁混用debug；下线需全局清理并保留映射。
feature flag 该不该用 if 硬写
硬写 if flag_enabled: 是最直接的实现，但很快会失控。不是不能用，而是得先划清边界：只在业务逻辑分支少、生命周期短（比如灰度两周就下线）的场景里临时这么干。
常见错误现象是多个地方散落相同 flag 判断，后来改名或清理时漏掉一两处，导致行为不一致；更隐蔽的是 flag 值来源混杂——有的从环境变量读，有的从配置文件读，还有的写死在代码里。
- 统一用一个模块（比如
features.py）集中管理所有 flag 名和默认值 - 所有判断必须调用封装函数，比如
is_feature_enabled("payment_v2")，而不是直接读os.getenv - 禁止在
if里拼接字符串做 flag 名，比如f"user_{role}_beta"—— 这类动态 flag 必须走专门的解析逻辑，否则无法审计
用 unleash-client-python 还是自己轮子
如果你需要服务端实时开关、用户分群、渐进式放量、指标上报，unleash-client-python 是目前最稳的选择；但如果你只是想本地控制几个开关、不连后端、也不需要 AB 测试能力，引入它反而增加部署复杂度和启动延迟。
性能影响很实际：Unleash 客户端默认每 10 秒拉一次全量 flag 配置，首次初始化可能阻塞主线程（尤其在 FastAPI 启动时），且每次 is_enabled() 调用都要查内存缓存+做规则匹配。
立即学习“Python免费学习笔记（深入）”；
- 确认是否真需要「实时生效」：如果发布后重启才生效，
python-decouple+ 环境变量足够 - 用
unleash-client-python时务必设置cache_directory，否则每次启动都重拉配置，冷启慢 - 避免在热路径（如 API 内层循环）里高频调用
is_enabled("expensive_flag")，提前缓存结果或降级为静态判断
settings.DEBUG 不能当 feature flag 用
把开发/测试逻辑绑在 DEBUG=True 上，上线后容易翻车。Django 的 DEBUG 控制模板错误页、SQL 日志等底层行为，不是业务功能开关；Flask 的 debug 更是只影响重载和调试器，跟功能无关。
典型翻车场景：某支付回调逻辑写了 if settings.DEBUG: mock_response()，上线后忘记删，结果生产环境真返回了 mock 数据；或者反过来，误以为 DEBUG=False 就自动关掉了某个实验功能，其实根本没生效。
- 所有业务功能开关必须有独立命名空间，比如
FEATURE_PAYMENT_REFACTOR，和框架 debug 设置完全隔离 - 环境变量命名加前缀（如
FF_PAYMENT_REFACTOR），避免和数据库配置、密钥等撞名 - CI 流水线里跑测试时，显式传入
FF_*变量，而不是依赖DEBUG的值来决定是否执行某段测试逻辑
flag 下线比上线更难，怎么安全清理
flag 下线不是删代码那么简单。真实情况是：代码删了，但数据库迁移脚本里还留着旧字段；或者前端 JS 里还引用着已废弃的 flag 名，导致控制台报错；甚至监控告警规则还在盯那个 flag 的启用率。
最容易被忽略的是「条件残留」：比如 if is_enabled("new_checkout") else legacy_flow() 被删了，但 legacy_flow() 本身没删，成了无主函数，后续重构时没人敢动。
- 下线前先全局搜索 flag 名，包括前端代码、SQL 脚本、文档、监控配置、日志埋点关键字
- 删代码时同步删掉对应的所有测试用例、mock 行为、AB 实验配置（比如 Unleash 上的 strategy）
- 保留至少一个发布周期的旧 flag 名映射（比如日志里仍记录
"old_flag_name" → "replaced_by_new_flag"），方便回溯
flag 名一旦进过生产环境，就别指望彻底消失。能做的，是让它的存在感归零：不被读、不被写、不被提、不被监控到。
