spring boot 项目连 sentinel 控制台需引入 sentinel-spring-cloud-starter-alibaba 依赖，配置 spring.cloud.sentinel.transport.dashboard 地址，并确保应用能访问控制台且已触发受保护接口；规则重启丢失因默认内存存储，需通过 nacos 等数据源持久化并正确初始化。
Spring Boot 项目怎么连上 Sentinel 控制台
Sentinel 控制台默认不自动发现你的应用，得让应用主动“报到”。关键不是改控制台，而是改你自己的服务——加依赖、配参数、确保网络通。
- 必须引入
sentinel-spring-cloud-starter-alibaba（注意版本要和 Spring Cloud Alibaba 对齐，比如 2022.x 对应 Sentinel 1.8.6+） - 在
application.yml里加配置：spring.cloud.sentinel.transport.dashboard: localhost:8080（端口别写错，默认是 8080） - 确保你的服务能
telnet localhost 8080通——很多问题其实卡在防火墙、Docker 网络或控制台没启动 - 首次访问控制台时，你的服务得已触发过至少一个被
@SentinelResource或 Web 接口（如 Spring MVC 的 Controller）保护的请求，否则不会出现在“簇点链路”里
规则为什么一重启就消失
Sentinel 默认规则存在内存里，进程停了自然清空。持久化不是开个开关就行，得选对存储方式并替换掉默认的 InMemoryRuleRepository。
- 最常用的是 Nacos：加
sentinel-datasource-nacos依赖，再配spring.cloud.sentinel.datasource.ds.nacos信息，规则类型设为FLOW（限流）、Degrade（降级）等 - 别漏掉
@PostConstruct或InitFunc初始化数据源，否则规则加载时机不对，控制台可能显示“无规则”，但日志里报No DataSource found - 用 Apollo 或 ZooKeeper 也行，但要注意它们的
RuleManager.loadRules()调用时机——不能早于FlowRuleManager初始化完成 - 本地文件模式（
FileRefreshableDataSource）只适合测试，生产环境别用，因为规则变更要靠定时轮询，延迟高还容易丢事件
控制台推送规则失败的典型错误
常见现象是控制台点了“新增”或“编辑”，提示“保存成功”，但应用日志没打印 Receive rule change，接口也没生效。
- 检查控制台日志是否有
Failed to push rule to target machine—— 大概率是应用没开http://localhost:8719这个内置端点（Sentinel 的 transport server），确认spring.cloud.sentinel.transport.port没被设为 0 或冲突 - 如果用了 Nacos，看 Nacos 控制台对应
dataId下的规则内容是否符合 JSON 格式，比如flow规则必须有resource、grade、count字段，少一个字段整个规则就不会加载 - Spring Boot 3+ 用户注意：Sentinel 1.8.x 不完全兼容 Jakarta EE 9+，
sentinel-web-servlet可能不生效，得换sentinel-spring-webmvc-adapter并手动注册WebMvcConfigurer
流控规则里 grade=1 和 grade=2 到底啥区别
这个参数决定限流维度，不是“级别高低”，选错会导致规则完全不触发。
-
grade = 1是 QPS 限流（每秒请求数），按进入 Sentinel 的请求计数，适用于突发流量防护 -
grade = 0是线程数限流（并发线程数），只统计当前正在执行的线程，适合防止慢调用拖垮线程池 -
grade = 2是关联流控，需要配合refResource使用——当关联资源达到阈值时，才对当前资源限流，常用于 A 接口强依赖 B 接口的场景 - 误把
grade=2当成“更高级的 QPS”是高频错误，实际它根本不会自己触发，必须另一个资源先被打满
load rule from datasource，再调接口看 ClusterNode.totalQps() 是否真被拦住——眼见为实，别信控制台那句“保存成功”。Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
