Gin服务在容器中无法被其他容器访问，核心原因是默认监听127.0.0.1而非0.0.0.0，且Consul注册地址错误；必须将router.Run(":8080")或显式设为"0.0.0.0:8080"，并注册为容器可解析的服务名（如api），确保两者一致。
服务在容器里跑着，其他容器却连不上——不是网络没通，而是 Gin 默认只绑 127.0.0.1，Consul 注册的地址也可能是错的，两者叠加直接导致服务“隐身”。
确认 Gin 是否监听 0.0.0.0 而非 127.0.0.1
这是最常被跳过的一步。本地开发时 router.Run("127.0.0.1:8080") 没问题，但放进容器后，其他容器发请求到你的服务 IP，内核根本不会把包交给绑定在 127.0.0.1 的进程。
-
router.Run(":8080")是安全写法，等价于"0.0.0.0:8080"，显式写成router.Run("0.0.0.0:8080")也行 - 进容器执行
netstat -tuln | grep :8080，看到的是0.0.0.0:8080才算生效；若显示127.0.0.1:8080，改完代码必须重启容器 - Docker 启动时加
-p 8080:8080只影响宿主机端口映射，不解决容器间通信问题
Consul 注册地址必须是容器可路由的 IP 或服务名
Consul 的健康检查和下游服务发现，依赖你注册进去的 Address 字段。填 127.0.0.1 或宿主机 IP（如 192.168.1.100）会导致其他容器解析失败或连不通。
- 在 Docker Compose 中，用
consul.service.consul这类 DNS 名注册不现实；应注册为本容器在自定义网络中的可解析名，例如api（前提是它属于同一network） - 更通用的做法：让 Gin 服务启动时读取环境变量
HOSTNAME或CONSUL_SERVICE_ADDRESS，注册时填这个值；避免硬编码 - Consul UI 中检查服务详情页的
Address字段，它应该能被其他容器ping通或curl -v http://<address>:<port>/health成功
Gin + Consul 集成时避免手动调用 router.Run()
如果你同时用 Kratos、Go-Micro 或自建服务治理逻辑，别让 router.Run() 和 Consul 的服务注册/心跳逻辑并行启动——它们会抢同一个端口，或者导致服务注册成功但实际 HTTP server 没起来。
- Consul 客户端（如
hashicorp/consul/api）应作为独立 goroutine 启动，负责注册、心跳、注销；Gin 的http.Server应由你自己控制生命周期 - 不要在
main()里直接写router.Run()，改用：http.ListenAndServe(":8080", router)，这样你能捕获 panic、做优雅关闭，并与 Consul 的Deregister同步 - Consul 健康检查路径（如
/health）建议用 Gin 的GET路由实现，返回200 OK即可，别依赖外部探针
CORS 中间件在跨容器+前端混合场景下的陷阱
当 Gin 服务既被其他容器调用（如 API 网关），又被浏览器直连（如管理后台），CORS 配置容易误伤内部通信。
- 别对所有请求都加
Access-Control-Allow-Origin: "*"，尤其当启用Access-Control-Allow-Credentials: "true"时，*会被浏览器拒绝 - 用中间件区分来源：检查
c.Request.Header.Get("Origin")，只对来自前端域名（如https://admin.example.com）的请求写 CORS 头；对来自nginx、gateway等内部服务的请求跳过 - 预检请求（
OPTIONS）必须返回204 No Content，不是200 OK；否则某些容器内的 curl 或前端 fetch 会静默失败
真正卡住人的地方，往往不是 Consul 配置多复杂，而是 Gin 绑定地址和 Consul 注册地址这两处看似微小的字符串——一个写错，整个服务就退网了。
