端口冲突应通过配置项（命令行参数或环境变量）解决，而非硬编码；本地调用失败多因网络隔离或监听地址不当；重试应封装策略客户端并注意幂等性；vendor 不生效时可用 -mod=vendor 或 replace。
本地启动多个 Go 微服务时端口冲突怎么办
直接改 main.go 里的监听端口最省事，但一换环境就得手动改，容易漏、容易错。真正靠谱的做法是把端口抽成配置项，用命令行参数或环境变量控制。
常见错误现象：listen tcp :8080: bind: address already in use —— 不是因为代码写错了，而是两个服务都硬编码了 :8080。
- 用
flag.String("port", "8080", "HTTP server port")在main()里解析，启动时加-port=8081 - 更推荐环境变量：
os.Getenv("PORT")，配合docker-compose.yml或本地.env统一管理 - 别在
http.ListenAndServe里拼接字符串，用fmt.Sprintf(":%s", port)更安全，避免空值 panic
Go 微服务之间调用 localhost 失败的典型原因
本地联调时，A 服务调用 B 服务的 http://localhost:8081/api 失败，90% 是网络隔离或地址误用导致的，不是代码 bug。
使用场景：你用 VS Code 启动 A，终端启动 B，两者都是本地进程，但 Docker 容器里跑的服务无法用 localhost 访问宿主机。
立即学习“go语言免费学习笔记（深入）”；
- Docker 容器内调用宿主机服务，得用
host.docker.internal:8081（Mac/Win），Linux 需额外加--add-host=host.docker.internal:host-gateway - 纯本地进程间调用，确保 B 服务监听的是
:8081而非127.0.0.1:8081—— 后者会拒绝 IPv6 连接，某些 Go 版本下触发超时 - 检查
http.DefaultClient.Timeout，微服务本地联调建议设为5 * time.Second，避免因 DNS 解析慢或中间件延迟误判失败
如何让 Go 微服务自动重试失败的下游请求
本地联调时服务启停频繁，上游经常遇到 connection refused，硬编码重试逻辑既难测又污染业务。标准解法是封装一层带策略的 HTTP 客户端。
性能影响：默认 http.Client 不带重试，每次失败就返回；加了指数退避后，首次失败延迟约 100ms，第三次才到 400ms，对本地调试足够友好。
- 用
github.com/hashicorp/go-retryablehttp，它复用原生http.Client，兼容所有中间件 - 关键配置：
RetryMax: 3、RetryWaitMin: 100 * time.Millisecond、RetryHTTPMethods: []string{"GET", "POST"} - 注意：不要对
POST无条件重试 —— 若下游已处理但响应丢失，重复提交会出问题；建议只对幂等接口开重试
Go mod vendor 后本地依赖更新不生效
你在本地改了公共工具库 utils，也执行了 go mod vendor，但微服务编译后还是旧逻辑 —— 因为 vendor 目录不会自动同步未提交的修改。
容易踩的坑：以为 go build 会优先读 vendor/，其实 Go 1.14+ 默认启用 GO111MODULE=on，它先查 go.mod 声明的版本，再 fallback 到 vendor。
- 确认是否真在用 vendor：
go build -v看输出里有没有vendor/路径；没有就说明没生效 - 强制走 vendor：加
-mod=vendor参数，即go build -mod=vendor -v - 本地开发更推荐
replace：在主项目的go.mod里加replace example.com/utils => ../utils，改完立刻生效，不用反复 vendor
本地联调真正的复杂点不在语法或框架，而在每个服务的启动边界、网络可达性和依赖快照的一致性。这些地方一旦错位，日志里看不到明显报错，只会表现为“调不通”“偶尔失败”“改了没反应”——得一个个去验环境假设，而不是盯代码。
