Spring Cloud Config 配合 Git Webhook 实现自动刷新的核心路径是“Git 变更 → Webhook 通知 → Config Server 广播 → 所有 Client 拉取新配置”，需确保三环闭环：服务端接收 Webhook（指向 /actuator/bus-refresh）、Spring Cloud Bus 正确配置并启用、客户端使用 @RefreshScope 且命名匹配（如 order-prod.yml）。
Spring Cloud Config 配合 Git Webhook 实现自动刷新，本质是“Git 变更 → Webhook 通知 → Config Server 广播 → 所有 Client 拉取新配置”。它不是一配就通，关键在三环闭环：服务端能接收 Webhook、消息总线能转发、客户端能响应刷新。
Webhook 必须发给 /actuator/bus-refresh（不是 /refresh）
很多人误把 Webhook 地址设成 /actuator/refresh，这是单个客户端的手动刷新端点，无法广播。自动刷新必须指向 Config Server 的 /actuator/bus-refresh（Spring Cloud Bus 提供）。例如：
- Gitee/GitHub Webhook URL 填：
http://config-server:8888/actuator/bus-refresh - 确保 Config Server 已暴露该端点：
management.endpoints.web.exposure.include=bus-refresh,health,info - 注意：请求方法必须是 POST，且默认不校验 Body 内容 —— 但 Gitee/GitLab 会自带 payload，可能触发 400 错误（见下条）
处理 Gitee/GitLab 的默认 payload 导致 400 错误
Gitee 或 GitLab 发送 Webhook 时，会在请求 Body 中附带大量 JSON 数据（如 push 详情），而 /actuator/bus-refresh 默认只接受空 Body 或简单表单。直接调用会报 400 Bad Request。
解决办法是加一个轻量 Filter，在请求到达 Spring MVC 前清空 Body：
立即学习“Java免费学习笔记（深入）”；
- 写一个
Filter，仅拦截/actuator/bus-refresh路径 - 用
HttpServletRequestWrapper包装原始 request，重写getInputStream()和getReader()，返回空内容 - 无需解析 payload，也不需额外依赖，几行代码即可绕过校验
Config Server 和 Client 都要接入 Spring Cloud Bus
Bus 是广播的“神经中枢”，缺一不可：
-
Server 端：引入
spring-cloud-starter-bus-amqp（RabbitMQ）或spring-cloud-starter-bus-kafka，并配置 RabbitMQ 连接信息（host/port/vhost/credentials） -
Client 端：同样引入 Bus 依赖，并确保
@RefreshScope标记了需要动态更新的 Bean - 两者都要启用 Actuator，并暴露
bus-refresh端点；Client 不需要自己监听 Webhook，只负责订阅 Bus 消息
Git 仓库配置文件命名要严格匹配
Config Server 从 Git 拉取配置，靠的是 {application}-{profile}.yml（或 .properties）这个约定。Webhook 触发后，Server 会根据请求中隐含的 application 和 profile 去找对应文件：
- Client 的
bootstrap.yml中必须明确指定：spring.application.name=order、spring.profiles.active=prod - Git 仓库里就得有
order-prod.yml，否则即使 Webhook 成功，Client 也拉不到变更内容 - 分支名（
label）也要对齐，比如label: main就要去main分支下找文件
