答案：服务 B 有多个实例，IP 和端口会变（扩容、宕机、重启）。不引入注册中心，A 就得把 B 的地址硬编码，B 一变 A 就得改代码重新部署。注册中心让所有服务启动时报到，调用方按服务名问注册中心拿可用地址，自动感知上下线。解析：这就是"服务发现"的本质——把"地址"从代码里抽出来，交给中间件管。

答案：Spring Boot 3.2.x 对应 Spring Cloud 2023.0.x（Leyton），再配 Spring Cloud Alibaba 2023.0.1.x。解析：Spring Cloud 的 starter 内部依赖了 Spring Boot 的具体 API（比如配置加载方式、Actuator 端点）。版本不匹配时，老 starter 调用了新 Spring Boot 里已经改名/删除的方法，启动直接 NoSuchMethodError。去官方 Wiki 的 Release Train 对照表查，别靠猜。

答案：最可能是 Feign 默认超时太短（老版本 read timeout 默认 1 秒），而用户服务的接口（比如查数据库 + 远程调用）响应超过了这个时间。解决：在 application.yml 里显式配置 feign.client.config.default.connect-timeout 和 read-timeout，调到合理值（比如 5000ms）。同时确认是不是用户服务本身真的慢，慢的话要先优化下游。

参考答案：扣库存用 Feign 同步——下单必须立刻知道库存够不够，不够要马上失败。发优惠券和发短信用 MQ 异步——下单接口不等它们做完，发个消息出去就返回，它们后台慢慢处理。解析：这就是"同步 vs 异步"的判断标准：调用结果是否影响当前请求的返回值。影响就同步，不影响就异步解耦。

答案：关闭（Closed，正常通过）→ 打开（Open，直接走降级，不真调下游）→ 半开（Half-Open，放一个请求试探）。触发打开：错误率或慢调用比例超过阈值。半开：过一段时间放一个请求过去，如果成功就关闭熔断器恢复正常，如果失败就继续打开。解析：这套状态机就是保险丝逻辑——别硬顶着故障打下游，先断开，过会儿探一下。

答案：九成是版本没对上。排查：① 看 dependency:tree 里 spring-cloud-dependencies 和 spring-cloud-alibaba-dependencies 实际版本；② 对照官方 Release Train 表，确认 Boot 3.2.5 该配 2023.0.x、Alibaba 该配 2023.0.1.x；③ 把三者统一在 dependencyManagement 里，删掉子模块写死的版本号；④ 清本地仓库重新拉。

参考答案：用 RequestRateLimiter 过滤器，自定义一个 KeyResolver，从 JWT 里解析出 userId 作为限流 key（而不是默认的 IP）。Redis 按 userId 分别计数，这样每个用户独立令牌桶，互不影响。

参考答案：普通电商选 AT——无侵入、开发快，@GlobalTransactional 一贴就行。如果是资金类、对性能和一致性要求极高、且 AT 的全局锁成为瓶颈，才上 TCC。前提是团队愿意承担写三套接口的成本。

答案：控制台规则默认存内存，重启即丢。根治是把规则持久化到 Nacos：业务服务从 Nacos 读规则数据源，控制台改规则时同步写 Nacos，形成"控制台 ↔ Nacos ↔ 各服务"的闭环，重启不丢、多实例一致。

参考答案：注册主流程只做"写用户"这一件强一致的事，然后发一条"用户已注册"的 MQ 消息。邮件、积分、BI 各自订阅这个 Topic 异步消费，互不阻塞、互不影响、新增需求只加消费者。这就是"同步写核心、异步广播周边"。