go微服务本身不处理反向代理或负载均衡，必须由nginx承担；upstream需定义在http块顶层，proxy_pass斜杠规则决定路径重写，go应监听内网端口并禁用0.0.0.0绑定，专注业务逻辑。
Go 微服务本身不处理反向代理或负载均衡，这部分必须由 Nginx 承担；直接在 Go 代码里“实现负载均衡”是常见误解，真正生效的配置只在 nginx.conf 里。
为什么不能靠 Go 自己做反向代理入口
Go 的 http.ServeMux 或第三方路由库（如 Gin、Echo）只负责单机请求分发，不具备跨机器调度、健康检查、连接复用、SSL 终结等能力。Nginx 是专为这些场景设计的边缘网关，Go 服务应专注业务逻辑，而非网络调度。
- Go 启动多个实例（如
./service-a --port=8001、./service-a --port=8002）后，它们只是普通 HTTP 服务，彼此无感知 - 若前端直接调用
http://host:8001/api/users，就绕过了 Nginx，失去统一入口、证书管理、缓存、限流等能力 - 所有跨服务调用（如 service-a 调 service-b）也应走内网 DNS 或固定 IP，不经过外层 Nginx
upstream 块必须显式定义，且不能写在 location 内
这是最常踩的坑：把 upstream 放进 server 或 location 块里会导致 Nginx 启动失败，报错 invalid number of arguments in "upstream" directive 或直接忽略该块。
-
upstream是 http 级指令，只能出现在http { ... }块顶层，和server并列 - 示例正确结构：
http {
upstream go_auth {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
server {
listen 443 ssl;
server_name auth.example.com;
location / {
proxy_pass http://go_auth;
}
}
}
- 别用
localhost—— 容器或多机部署时，Nginx 和 Go 服务不在同一台机器，localhost指向 Nginx 自身，不是你的 Go 进程 - 权重、健康检查需配合
proxy_next_upstream使用，否则挂掉一台，请求仍会打过去
proxy_pass 末尾斜杠决定路径重写行为
Go 服务通常注册路径如 /api/v1/users，但 Nginx 配置稍有不慎就会导致 404 —— 根源几乎总是 proxy_pass 尾部斜杠缺失或多余。
-
location /auth/ { proxy_pass http://go_auth; }→ 请求/auth/login会转发为http://go_auth/auth/login（错误，Go 服务没这个前缀） -
location /auth/ { proxy_pass http://go_auth/; }→ 请求/auth/login转发为http://go_auth/login（正确） -
location / { proxy_pass http://go_auth; }→ 请求/api/users转发为http://go_auth/api/users（若 Go 服务根路径就是/api，则没问题）
简单记法：只要 location 路径带后缀（如 /auth/），proxy_pass 必须以 / 结尾；若 location 是 /，则 proxy_pass 末尾加不加 / 效果一致。
Go 服务启动时别绑定 0.0.0.0:80 或 :443
Nginx 需要独占 80/443 端口作为入口，Go 服务应监听内网端口（如 :8080、:9000），并确保防火墙放行该端口供 Nginx 访问。
- Go 启动命令示例：
./user-service -addr=:8081，而非-addr=:80 - 容器部署时，在
docker-compose.yml中暴露端口仅用于内部通信，不要ports:映射到宿主机 80 - 如果 Go 服务用了
net/http默认 TLS 配置，会干扰 Nginx 的 SSL 终结，应关闭 HTTPS，让 Nginx 处理证书
路径重写、健康探测、连接超时这些细节，全靠 Nginx 配置驱动；Go 只需保证自己能被 Nginx 稳定访问，其余交给 upstream 和 proxy_* 指令组合控制。
