go-sentinel 不支持动态配置限流规则，因其纯内存运行且无内置配置中心集成，所有规则须通过 flow.loadrules 显式加载，该操作为全量覆盖、无监听机制、需手动处理并发与错误。
Go-Sentinel 不支持动态配置限流规则——它本身是纯内存运行、无内置配置中心集成的轻量库，所有规则必须在启动时或运行时通过代码显式调用 flow.LoadRules 加载，且不监听外部变更。
为什么 flow.LoadRules 不等于“动态配置”
很多开发者误以为只要调用一次 flow.LoadRules 就算“动态”，但实际中：
• 规则加载是全量覆盖式，不是增量更新，旧规则会彻底丢失；
• 没有内置监听机制（如 etcd watch、Nacos 长轮询），无法感知配置变化；
• 若手动轮询配置源再调用 flow.LoadRules，需自行处理并发安全、加载失败回滚、规则语法校验等逻辑；
• flow.LoadRules 是同步阻塞操作，高频调用可能引发限流器短暂不可用。
如何模拟“动态配置”：手动对接 Nacos / Apollo / etcd
以 Nacos 为例，你需要自己实现监听 + 规则转换 + 安全加载：
• 使用 nacos-sdk-go 的 config_client.ListenConfig 订阅配置项（如 sentinel-flow-rules）；
• 配置内容必须是合法 JSON 数组，结构严格匹配 flow.FlowRule 字段（如 Resource、Count、ControlBehavior）；
• 在回调函数中解析 JSON，构造 []*flow.FlowRule，再传给 flow.LoadRules；
• 必须加锁（如 sync.RWMutex）防止多线程并发调用 flow.LoadRules 导致 panic；
• 建议添加日志和错误告警：若 JSON 解析失败或 LoadRules 返回 error，应保留旧规则并打印完整错误信息（err.Error()）。
常见踩坑点：规则格式、资源名、热更新失效
• Resource 字段必须与业务代码中 entry 的资源名**完全一致**（包括大小写、空格、下划线），否则规则不生效；
• Go-Sentinel 默认不开启 hotspot 或 system 规则，若用了 flow.LoadRules 却没生效，先检查是否漏掉 flow.Init 和 flow.RegisterProcessor；
• 修改 Nacos 配置后，首次回调可能延迟 1–3 秒（取决于 Nacos 长轮询间隔），不要误判为“没更新”；
• 如果使用微服务框架（如 Kitex、gRPC），确保限流逻辑在中间件中注册，且 entry 调用发生在请求入口（如 handler 开头），而非异步 goroutine 内；
• LoadRules 不校验 Resource 是否已存在，无效资源名只会静默忽略——建议配合 flow.GetRules() 打印当前生效规则做验证。
真正稳定的动态能力需要你补全监听、序列化、并发控制、错误恢复这一整条链路，Go-Sentinel 只提供最底层的规则引擎，其余全是你的责任。
