直接用 rate.Limiter 包裹 GORM 查询存在三大问题：共用限流桶无法区分语义、不联动熔断加剧连接池压力、绕过 Sentinel 滑动窗口导致监控缺失；需按 DAO 方法粒度埋点精确资源名，配合错误率熔断与负载匹配的限流规则。
为什么不能直接用 rate.Limiter 包裹 GORM 查询
直接在 db.First() 前加 limiter.Wait(ctx) 看似能限流，但会带来三个硬伤：一是所有数据库操作共用一个桶，无法区分「用户查询」和「订单写入」这类语义差异；二是没联动熔断——哪怕 PostgreSQL 已连续 5 次超时，限流器仍放行请求，徒增连接池压力；三是绕过 Sentinel 的滑动窗口统计，监控里看不到 SQL 级别的 QPS、慢调用比例等关键指标。
sentinel.Entry 必须按 DAO 层方法粒度埋点
资源名不是 "db" 或 "postgres" 这种泛化名，而要精确到具体操作：
-
sentinel.Entry("user-dao:find-by-email")—— 对应UserDAO.FindByEmail() -
sentinel.Entry("order-dao:create")—— 对应OrderDAO.Create() - 资源名一旦上线就不能改，否则旧规则失效、监控断层
埋点位置必须紧贴 GORM 调用前，且 e.Exit() 必须 defer 在函数末尾（即使 panic 也要执行）；错误处理不能只看 err != nil，得检查 sentinel.BlockError 类型来区分是被限流还是 DB 真出错。
熔断策略选 ErrorRatioStrategy 而非 SlowRatioStrategy
数据库场景下，慢查询波动大（例如索引失效导致某次查询从 50ms 涨到 800ms），用慢调用比例容易误熔；而真实故障往往是连接拒绝、事务超时、唯一键冲突等明确错误，更适合用错误率驱动熔断：
-
ErrorCount≥ 5（避免单次网络抖动触发） -
MaxAllowedRtMs设为 0（不参与慢调用统计） -
StatIntervalInMs设为 60000（1 分钟窗口，防抖动） -
RecoveryTimeoutMs至少 30000（30 秒，给 DB 故障恢复留时间）
注意：CircuitBreaker.Rule() 加载后不会自动生效，必须确保 sentinel.InitDefault() 已成功调用，且无 error 返回。
限流规则必须匹配实际负载特征
GORM 查询的 QPS 和响应时间分布差异极大，不能统一设成「每秒 100 次」：
- 高频低耗操作（如
SELECT COUNT(*) FROM user WHERE status=1）可设Qps: 200 - 低频高耗操作（如带 JOIN 的报表导出）应设
Qps: 5+ControlBehavior: flow.Reject（拒绝而非排队，防长尾） - 所有规则必须显式调用
flow.LoadRules()加载，Sentinel Go 不会自动扫描或热加载未注册的规则
最容易被忽略的是：GORM 的 Preload 关联查询会触发多个 SQL，但 sentinel.Entry 只埋点一次——这意味着你看到的“QPS”其实是 DAO 方法调用频次，不是真实 SQL 数。若需精确控 SQL 级别流量，得拆到更细粒度（比如单独为 user.Preload("Orders") 定义资源名）。
