灰度开关应存于redis或带版本号的数据库配置表，而非硬编码或环境变量；判断需基于上下文策略对象而非简单布尔函数；关闭时须触发幂等清理动作并确保实时性。
灰度开关该存在哪里，而不是“写在哪”
灰度开关不是配置项，是运行时决策点。硬编码在 if 里、塞进 settings.py 或丢进环境变量，都会让它的生命周期失控——上线后改不了、回滚时漏掉、A/B 测试跑着突然失效。
真正可控的存放位置只有两个：Redis（高频读+需热更新）或数据库带版本号的配置表（需审计+回溯）。前者响应快但无变更记录；后者可查谁在什么时候关了 feature_x，但每次判断要多一次 DB 查询。
-
Redis键建议用gray:feature:user_id这类带作用域的命名，避免全量开关和用户级开关互相污染 - 数据库方案必须带
生效时间和过期时间字段，否则凌晨三点发现开关没按计划关闭，只能手动连库UPDATE - 绝对不要用
os.environ.get('ENABLE_FOO')做灰度判断——容器重启就固化，根本不算“灰度”
判断逻辑别绕开「上下文」直接返回布尔值
灰度不是非黑即白的 True/False，它依赖用户 ID、设备类型、请求路径甚至当前时间。写成 is_feature_enabled(user_id) 看似简洁，实则埋雷：下次要按地域灰度，就得改函数签名、调用方全量适配。
正确做法是把判断权交给策略对象，比如 GrayChecker(feature_name, context={'user_id': 123, 'ua': 'iOS/17.4'})，内部根据规则引擎匹配，外部只管传上下文。
立即学习“Python免费学习笔记（深入）”；
- 常见错误：在中间件里直接
if settings.GRAY_USER_IDS and user.id in settings.GRAY_USER_IDS—— 这种写法等于把灰度规则写死在代码分支里 - context 字典字段名必须全局统一，比如用户标识固定用
user_id，别一会儿用uid一会儿用account_id - 时间相关判断（如“仅工作日早 9 点开放”）务必用 UTC 时间做比对，否则部署在不同时区服务器上行为不一致
开关关闭后，资源清理常被忽略
灰度开关关了，不代表后端服务、缓存、定时任务就自动停了。常见现象是开关已关，但旧版接口还在被调用，日志里持续报错 KeyError: 'new_field'，因为下游还没切走。
真正的生命周期闭环，必须包含“关闭触发动作”。比如关掉 payment_v2 开关时，自动执行：cache.delete_pattern('payment:v2:*')、向消息队列发 gray_switch_off 事件、停止对应 Celery task 的 apply_async 调度。
- 不要在开关判断外层包一层
try/except消错——那是掩盖问题，不是管理生命周期 - 清理动作本身要幂等，重复执行不能出错，例如
cache.delete失败应静默，不能抛异常中断主流程 - 如果灰度涉及第三方 API 调用，关开关前得确认对方是否也同步下线了回调地址，否则会收到一堆 404 日志
测试阶段最容易漏掉的边界：开关状态变更的时机差
本地测 ENABLE_FEATURE=True 没问题，一上预发就失效，往往不是代码问题，而是开关状态加载时机不对。Django 启动时从 Redis 读一次，之后再变也不感知；Flask 的 g 对象里缓存了结果，但请求间不刷新。
必须让开关值在每次关键判断前“新鲜”获取，或至少设置合理 TTL（比如 30 秒），不能依赖进程启动时的快照。
- Django 用户注意：
@cached_property修饰的开关方法，在 request 生命周期内只算一次，但若一个请求里多次调用不同灰度功能，可能拿到过期状态 - 用
threading.local()缓存开关值？小心 gunicorn 多 worker 下缓存错乱，local是线程级，不是请求级 - 最稳的方式：每次调用都走一次
redis.get('gray:xxx')，加个fallback参数应对 Redis 不可用，别省这点网络开销
灰度开关的麻烦不在“怎么开”，而在“怎么让它在该关的时候真关掉、该清的资源清干净、该通知的地方不遗漏”。这些细节藏在每次状态变更的毫秒间隙里，而不是文档开头那行 if is_gray_enabled(): 里。
