本地启动多个微服务时端口冲突应避免硬编码，改用环境变量（如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热重载会卡死
调试时看不到跨服务的请求链路
没有分布式追踪，你只能靠日志拼时间戳，基本靠猜哪条请求触发了下游错误。
立即学习“go语言免费学习笔记（深入）”；
- 本地最小化接入
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 没透传——这三个点，本地调试时八成问题都出在这儿。
