自定义注解布尔属性不可直接写死，应通过字符串标识符（如@grayfeature("pay-v2")）绑定配置中心动态值，由aop切面实时拉取并支持降级；统一收口灰度决策，避免业务耦合，配套可追溯的开关管理机制。

直接用自定义注解的布尔属性当灰度开关，看似简单，但容易踩坑。它适合做“全开/全关”的硬性控制，不适合做动态分流或用户级灰度。关键在于：这个布尔值必须能实时刷新，且不能写死在代码里。

注解定义要支持运行时可变

布尔属性本身是编译期常量，所以不能直接写 @MyToggle(enabled = true) 这种字面量——那改一次就得重新编译。正确做法是让注解只声明开关名，把实际值交给外部配置：

• 定义注解时用字符串标识符，例如 @GrayFeature("pay-v2")
• 不暴露 enabled = true/false 字段，避免误导开发者以为这是静态开关
• 如果非要保留布尔字段，必须标注 @AliasFor 并绑定到配置中心的 key，否则无意义

运行时读取逻辑必须脱离 classpath

注解里的值只是元数据，真正起作用的是 AOP 切面中对配置的实时拉取。比如：

• 切面拦截到 @GrayFeature("pay-v2") 后，立即查 Nacos 或 Apollo 中 feature.pay-v2.enabled 的值
• 不能缓存太久，建议设置 1~5 秒本地缓存 + 长轮询监听变更
• 若配置中心不可用，要有降级策略（如默认关闭、或 fallback 到上一次有效值）

避免把开关逻辑和业务耦合

不要在业务方法里手动判断 if (config.get("pay-v2.enabled")) { ... } —— 这违背“零侵入”原则，也容易漏判。应该统一收口：

• 所有灰度方法都加注解，由切面统一决策是否执行
• 未命中灰度时，自动调用 @FallbackMethod 指定的兼容逻辑（比如走老支付通道）
• 开关关闭期间，新逻辑完全不加载、不初始化，减少资源消耗

线上操作要可控、可追溯

布尔开关不是“开关灯”，而是生产环境的阀门。上线后需配套机制：

• 提供管理界面或内部 API，供产品/测试人员一键开启/关闭，避免直连配置中心误操作
• 每次开关变更记录操作人、时间、原因，写入审计日志
• 开关生效后自动触发探针检查：确认对应功能模块是否真实响应变化