必须在main启动早期同步初始化ffclient并紧邻defer关闭，用户上下文需动态构造唯一key，BoolVariation默认值仅为fallback而非灰度主逻辑，配置变更存在3秒延迟且YAML键名须与代码严格一致。
直接用 go-feature-flag 就行，别自己造轮子；但配置加载时机、用户上下文构造、默认值语义这三点不搞清，上线后 flag 会失效或返回错值。
初始化 ffclient 必须在 main 启动早期完成，且不能被 defer 干扰
ffclient.Init() 是同步阻塞调用，它会立即读取配置文件（或远程源）并构建内存中的规则树。如果放在某个 handler 里懒加载，第一次请求时才初始化，会导致：首次评估必然 fallback 到默认值、并发请求可能触发重复初始化、panic 无法被捕获到主流程。
- 必须在
main()函数开头、http.ListenAndServe或 gRPC server 启动前完成 -
defer ffclient.Close()要紧挨着Init()放，避免因 panic 提前退出导致资源泄漏 - 若使用 Kubernetes ConfigMap 挂载 YAML，确保容器启动时该文件已存在——否则
Init()直接返回 error，程序应明确处理并退出，而不是静默 fallback
用户上下文（ffcontext）必须带唯一 key，且不能复用全局变量
ffcontext.NewEvaluationContext("user-unique-key") 中的 key 是路由决策依据。用固定字符串（如 "default"）、空字符串或硬编码 ID，会让所有请求命中同一 bucket，彻底破坏百分比分流逻辑。
- HTTP 场景：从
r.Header.Get("X-User-ID")或 JWT claim 中提取，fallback 到r.RemoteAddr（仅限调试） - gRPC 场景：从
metadata.FromIncomingContext(ctx)取"user-id"，严禁用ctx.Value()里未校验的值 - 绝对不要在中间件外提前构造一个全局
ctx变量反复传入——不同请求的 user-id 不同，复用会导致分流结果污染
BoolVariation 等评估函数的默认值不是兜底逻辑，而是 fallback 值
ffclient.BoolVariation("my-flag", user, false) 中的 false 仅在以下任一情况生效：配置不存在、flag 名拼写错误、user 无法匹配任何 rule、网络拉取失败且无本地缓存。它不参与百分比计算，也不替代 defaultRule。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- YAML 中的
defaultRule才是流量分配主逻辑，BoolVariation的第三个参数只是“最后保底” - 若误把业务逻辑默认行为（如“老版支付流程”）塞进这个参数，而 YAML 里又漏配
defaultRule，就会出现 100% 用户走老逻辑，完全绕过灰度控制 - 建议始终显式写
BoolVariation("flag", ctx, false)，而非BoolVariation("flag", ctx, nil)—— Go 不支持 nil bool，编译不过
配置热更新有延迟，别指望实时秒级生效
go-feature-flag 默认每 3 秒轮询一次文件（或 HTTP/S3 源），变更从磁盘/网络落到内存需经历：读取 → 解析 → 校验 → 替换旧规则树。期间新请求仍用旧规则，旧请求不受影响。
- 若用
fileretriever，确保文件系统支持 inotify（Linux）或 kqueue（macOS），否则轮询靠 sleep，实际延迟 =PollingInterval + 解析耗时 - 线上禁用
PollingInterval: 0（即禁用轮询）——除非你用的是 webhook retriever 并自行保证推送可靠性 - 做金丝雀发布时，别依赖“改完 YAML 立刻切 5%”，要预留至少 5 秒观察窗口，再检查日志中
ffclient是否打出configuration reloaded
最易被忽略的是：YAML 配置里的 variation key 名称，必须和代码里 BoolVariation 的第一个参数严格一致（包括大小写和连字符），且不能含空格或特殊符号——go-feature-flag 不做 normalize，错一个字符就 fallback 到默认值，还不会报错。
