go 的 flag 包仅支持启动时解析，不适用于运行时功能开关；应选用 unleash/launchdarkly 等支持状态同步的 sdk，或用 atomic.bool/sync.map 手写轻量方案，同时重视评估上下文（如用户 id）对灰度精度的关键影响。
Go 里用 flag 包做功能开关太容易误用
Go 标准库的 flag 包不是为运行时动态开关设计的，它只在程序启动时解析一次命令行参数，之后值就固定了。你改环境变量、发信号、写配置文件，它都看不到——除非你手动重载逻辑。
- 常见错误现象：
flag.Parse()后再调用flag.Set("feature-x", "true")不会触发类型校验或更新已绑定变量，flag.Lookup("feature-x").Value.String()看起来变了，但通过flag.BoolVar(&x, ...)绑定的变量仍保持旧值 - 使用场景：适合启动时决定行为（比如
./app -mode=prod），不适合灰度发布、AB 测试、线上热切开关 - 参数差异：
flag.String()返回 *string，flag.StringVar()直接写入已有变量，后者更常见但更难“重置” - 性能影响：无 runtime 开销，但缺乏线程安全封装；并发读取同一
flag.Value需自行加锁
真正支持运行时切换的 Feature Flag 库怎么选
别自己造轮子，直接用 launchdarkly/go-server-sdk 或轻量级的 unleash-org/unleash-client-go。它们的核心区别不在 API 多漂亮，而在「状态同步机制」是否可靠。
- 常见错误现象：本地 mock 开关一直 true，上线后发现没连上 Unleash server，所有
unleash.IsEnabled("feat-xx")默认返回 false，业务逻辑静默降级 - 使用场景：
unleash.IsEnabled("payment-v2", ctx)必须传入 context，否则超时控制失效；launchdarkly.EvalFlag(ctx, "feat-xx", user, false)的user结构体必须含Key string字段，否则分流失效 - 兼容性影响：
unleash-client-gov4 要求 Go 1.20+，v3 的unleash.NewClient不支持自定义 HTTP client timeout，容易卡住初始化 - 性能影响：首次初始化可能阻塞几秒（拉取 toggles），建议在
main()启动 goroutine 异步加载，同时 fallback 到内存默认值
自己实现简易开关时，sync.Map 和 atomic.Bool 怎么选
如果只是几个内部开关、不依赖外部服务，手写也行，但别用全局 map + mutex —— 写少读多场景下，atomic.Bool 更轻量、更安全。
- 常见错误现象：用
map[string]bool存开关状态，多个 goroutine 并发读写 panic:fatal error: concurrent map read and map write - 使用场景：
atomic.Bool适合单个布尔开关（如isDebugMode）；sync.Map适合键值对较多且需按 name 查询（如features["search-suggestions"]） - 参数差异：
atomic.Bool.Store(true)是覆盖写，没有 CAS 接口；想实现「仅当当前为 false 才设为 true」得自己包一层CompareAndSwap逻辑 - 性能影响：
atomic.Bool比sync.RWMutex快 3–5 倍（基准测试数据），但不支持遍历或删除操作
环境变量 + os.Getenv 不能当 Feature Flag 用
环境变量读取是快，但它无法响应变更。容器里改了 FEATURE_NEW_UI=true，你的 Go 进程不会自动 reload，除非你每轮请求都重新调用 os.Getenv —— 但这样既没缓存又没类型转换，还容易拼错 key。
- 常见错误现象：
os.Getenv("FEAT_NEW_UI") == "true"返回 false，因为实际值是"True"或"1"，没人统一约定格式 - 使用场景：只适合进程生命周期内不变的配置，比如部署环境标识
ENV=staging；功能开关必须带类型解析和默认兜底 - 性能影响：每次
os.Getenv是系统调用，比内存查表慢两个数量级；高频路径中反复调用会拖慢 QPS - 正确做法：启动时用
os.Getenv初始化一个atomic.Bool，后续只读该原子变量；或者用viper.AutomaticEnv()+viper.GetBool("feature.new_ui")做一次解析
最常被忽略的一点：Feature Flag 的「评估上下文」比开关本身更重要。比如 unleash.IsEnabled("feat-xx", ctx) 里的 ctx 如果没带用户 ID 或租户信息，服务端就只能按随机比例放量，根本做不到按用户维度灰度。这个细节不写进代码注释，三个月后谁都想不起。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
