kratos 集成 sentinel 的核心难点在于资源粒度绑定、规则生效时机与降级逻辑执行位置；需手动注册资源、统一异常映射并严格匹配 blockhandler/fallback 签名与调用上下文。
Kratos 框架集成 Sentinel 做流控，核心难点不在接入本身，而在于资源粒度绑定、规则生效时机和降级逻辑的执行位置——Sentinel 默认不感知 Kratos 的 transport 层抽象，必须手动注册资源；服务降级失效，90% 是因为 fallback 函数签名不匹配或未被 @SentinelResource 显式引用。
如何让 Kratos 接口真正被 Sentinel 管控
默认情况下，Kratos 的 HTTP/gRPC Server 启动后，Sentinel 不会自动拦截任何请求。它不像 Spring Cloud Alibaba 那样有自动埋点机制，必须显式将业务逻辑包装成 Sentinel 资源。
- 在 Controller 或 Service 方法里用
SphU.entry("resourceName")手动包裹关键逻辑，try-catch BlockException并返回统一错误码（如 429），这是最轻量也最可控的方式 - 若使用 Kratos 的
middleware，可在中间件中统一提取ctx.Request().URL.Path或grpc.Method()作为资源名，调用SphU.entry()，但要注意 gRPC 的Method格式是/package.Service/Method，需清洗后使用 - 避免把整个 HTTP handler 函数直接包成一个资源——这样无法区分不同接口；也不要为每个 RPC 请求新建资源名（如拼入用户 ID），否则热点参数限流无法生效
- 务必在
finally块中调用entry.exit()，否则统计计数会持续累积，导致后续所有规则误判
blockHandler 和 fallback 失效的常见原因
这两个函数看似相似，但触发条件和签名要求完全不同，混用就会静默失败。
-
blockHandler只响应 Sentinel 主动拦截（如 QPS 超限、熔断打开），必须是static方法，且参数列表必须与原方法一致 + 最后一个参数为BlockException，返回类型也必须完全相同 -
fallback响应的是业务异常（比如下游 RPC 报错、DB 抛出sql.ErrNoRows），不要求static，但必须和原方法签名兼容（参数可少，不能多；返回类型需能赋值给原返回类型） - 如果用了
@SentinelResource(blockHandler = "xxx", fallback = "yyy")，但xxx或yyy方法不在同一个类里，或访问权限不是public，Sentinel 会直接忽略，不报错也不调用 - Kratos 中常犯的错：在
fallback里又调用了另一个可能触发 Sentinel 的方法，形成嵌套资源，容易引发死循环或统计混乱
熔断规则配置后不触发？先查这三个地方
熔断不是“配完就生效”，它依赖准确的调用结果统计，而 Kratos 的 error 分类和 Sentinel 的异常识别逻辑需要对齐。
- 确认你的业务方法抛出的异常是否被 Sentinel 认定为“业务异常”——默认只把
RuntimeException和Error当作可统计异常；如果你用的是自定义错误（如errors.New("timeout")），需通过DegradeRule.setExceptionPredicate()显式声明哪些错误参与熔断判断 - 检查熔断策略类型：
DEGRADE_GRADE_RT（慢调用）要求平均响应时间超过阈值且请求数达标；DEGRADE_GRADE_EXCEPTION_RATIO（异常比例）要求每秒请求数 ≥minRequestAmount（默认 5），否则永远不计算比例 - Kratos 的 gRPC Server 默认把所有 error 都转成
status.Error()并返回codes.Unknown，这会导致 Sentinel 统计不到真实异常类型；建议在 middleware 中统一将业务错误映射为特定codes（如codes.Unavailable），再配合ExceptionPredicate过滤
真正难的不是写对一行 @SentinelResource，而是理解 Kratos 的调用链路在哪一层交出控制权、Sentinel 的统计窗口从哪一刻开始计数、以及 fallback 返回的数据结构能否被 Kratos 的 encoder 正确序列化。这些细节没对齐，规则再漂亮也没用。
