sentinel.init 必须在 main() 开头显式调用，否则规则静默失效；需检查 error 并 panic 或 log.fatal，确保配置就绪且无阻塞操作。
熔断器初始化失败，Sentinel.Init 报错怎么办？
Go 版 Sentinel（github.com/alibaba/sentinel-golang）启动时必须显式调用 Sentinel.Init，否则所有规则注册和流量控制都会静默失效。常见错误是忘记初始化、或在 goroutine 中异步调用导致主流程已开始打点但熔断器未就绪。
- 确保在
main()函数最开始、任何业务逻辑或 HTTP server 启动前调用Sentinel.Init - 检查返回的
error，非 nil 时应直接 panic 或 log.Fatal —— 它通常意味着配置路径错误、JSON 解析失败或 metrics reporter 初始化异常 - 若使用自定义配置（如从 etcd 加载），需确保
Init前配置已就绪；不要在Init内部做阻塞操作（比如同步拉取远程配置）
定义熔断规则时，RecoveryTimeout 和 MinRequestAmount 怎么设才合理？
Go 的 sentinel.Rule 熔断策略依赖两个关键参数：触发熔断的最小请求数（MinRequestAmount）和熔断后恢复等待时间（RecoveryTimeout）。设得太激进会导致频繁误熔断，太保守则起不到保护作用。
-
MinRequestAmount建议不低于 20 —— 小于该值时统计样本不足，熔断判断易受噪声干扰；对低频接口可适当调低，但不建议低于 5 -
RecoveryTimeout单位是毫秒，典型值为 60000（1 分钟）；若下游恢复较快（如 DB 连接池自动重建），可设为 30000；但切忌设为0或负数，会导致熔断状态无法退出 - 注意：
StatIntervalInMs（统计窗口，默认 1000ms）必须能整除RecoveryTimeout，否则实际恢复行为不可预期
HTTP handler 中如何正确嵌入 sentinel.Entry 实现降级？
在 Gin/echo/fasthttp 等框架中，不能只靠 Entry 拦截请求，还必须显式处理 BlockError 并返回降级响应，否则熔断触发时会 panic 或返回 500。
- 调用
sentinel.Entry后，必须用if err != nil && errors.Is(err, sentinel.ErrBlocked)判断是否被熔断，而不是用err == nil简单分支 - 降级逻辑建议封装成函数复用，例如返回缓存数据、空 JSON 或预设错误码（如
{"code":503,"msg":"service unavailable"}） - 务必在
defer entry.Exit()前完成业务逻辑执行 —— 若业务 panic，Exit()不会被调用，导致计数器泄漏；建议用recover()+Exit()组合兜底
为什么熔断生效了，但 Prometheus 指标里看不到 sentinel_circuit_breaker_state？
Go 版 Sentinel 默认不开启指标暴露，即使启用了 prometheus reporter，也需要手动注册并启动 HTTP handler，且指标名与 Java 版不同。
- 导入
github.com/alibaba/sentinel-golang/ext/datasource/file和github.com/alibaba/sentinel-golang/exporter/prometheus后，需显式调用prometheus.Initialize() - Prometheus metrics path 默认是
/metrics，不是/actuator/prometheus；且核心指标名为sentinel_circuit_breaker_status（注意是status而非state） - 确认
sentinel.WithMetricExportInterval(1000)已设置（单位毫秒），否则指标不会定时刷新；低于 500ms 可能影响性能，高于 5000ms 则监控延迟明显
真实线上环境里，最容易被忽略的是熔断器状态变更的「滞后性」：一个请求触发熔断后，后续请求立刻被拦截，但指标更新可能延迟 1~2 个统计周期。观察指标时得结合日志里的 onStateChange 回调输出交叉验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
