本地启动多个微服务时端口冲突应避免硬编码，改用环境变量（如PORT）或自动探测可用端口（开发环境）；服务间调用需统一网络地址（如host.docker.internal或127.0.0.1）并设置合理超时；推荐使用air热重载、OpenTelemetry接入Jaeger实现链路追踪，关键注意环境变量、端口、context透传。

本地启动多个微服务时端口冲突怎么办

直接硬编码 8080、8081 这类固定端口，服务一多就容易撞车，尤其当你改了代码又忘了改端口，listen tcp :8080: bind: address already in use 会反复出现。

• 用环境变量控制端口：在 main.go 中读取 os.Getenv("PORT")，默认 fallback 到 "8080"
• 启动时统一用 PORT=8082 go run main.go，避免硬编码
• 更稳妥的做法是让服务启动时自动探测可用端口（比如从 8080 开始试到 8099），但仅限开发环境——生产必须显式指定

服务间调用在本地始终超时或连不上

常见原因是用了 localhost 或 127.0.0.1 做服务发现地址。Docker 容器里跑的服务无法通过 localhost 访问宿主机上的其他 Go 服务，反之亦然。

• 本地调试全部走宿主机网络：所有服务都用 0.0.0.0:PORT 监听，调用方用 http://host.docker.internal:8082（macOS/Windows Docker Desktop）或 http://172.17.0.1:8082（Linux Docker）
• 如果不用 Docker，纯本地多进程调试，统一用 127.0.0.1（别用 localhost，某些系统下解析慢或走 IPv6）
• 检查 http.Client 的 Timeout，本地调试建议设为 5 * time.Second，避免因日志延迟或断点卡住误判为网络失败

如何快速重启某个服务而不影响其他服务

手动 Ctrl+C + go run 效率低，且容易漏掉 go mod tidy 或环境变量重载。

• 用 air（go install github.com/cosmtrek/air@latest）：它监听文件变化，自动 rebuild 并 kill 旧进程，支持自定义 .air.toml 配置构建命令和环境变量
• 每个服务单独开一个终端窗口，不要把多个 go run 塞进一个 shell 脚本里——出错时难以定位是哪个服务崩了
• 避免在 init() 里做阻塞操作（如连接数据库、HTTP 健康检查），否则 air 热重载会卡死

调试时看不到跨服务的请求链路

没有分布式追踪，你只能靠日志拼时间戳，基本靠猜哪条请求触发了下游错误。

• 本地最小化接入 OpenTelemetry：用 otelhttp.NewHandler 包裹 HTTP handler，用 otelhttp.NewClient 包裹调用客户端
• 导出到 jaeger 本地实例：

  docker run -d --name jaeger -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 -p 5775:5775/udp -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778 -p 16686:16686 -p 14250:14250 -p 14268:14268 -p 14269:14269 -p 9411:9411 jaegertracing/all-in-one:1.45

• 关键：所有服务启动时传入相同 service.name，且确保 context 透传（req = req.WithContext(ctx)），否则 trace 会断

环境变量没加载、端口没放开、context 没透传——这三个点，本地调试时八成问题都出在这儿。