不能直接用 go run main.go，因它仅用于调试、依赖Go编译器且不生成可执行文件；必须用 go build -o 编译静态二进制，配合 CGO_ENABLED=0 和 -ldflags="-s -w" 适配 Alpine 镜像。
Go 微服务构建镜像时为什么不能直接用 go run main.go？
因为 go run 仅用于开发调试，它会启动临时编译环境、生成中间文件、不控制二进制输出路径，且容器里没装 Go 编译器——运行时直接报 command not found: go。
- 必须用
go build -o编译出静态可执行文件，再 COPY 进轻量基础镜像（如alpine:latest） - 加
-ldflags="-s -w"可减小二进制体积（去掉符号表和调试信息） - 显式设置
CGO_ENABLED=0确保纯静态链接，避免 Alpine 镜像中缺 libc 动态库
Dockerfile 中如何正确设置 Go 微服务的 WORKDIR 和 ENTRYPOINT？
常见错误是把源码目录当运行目录，或用 sh -c 包裹启动命令导致 PID 1 不是你的服务进程，收不到 SIGTERM 信号。
-
WORKDIR应设为二进制所在路径（如/app），不是/src或/go/src -
ENTRYPOINT用数组形式：ENTRYPOINT ["/app/my-service"]，确保进程直接作为 PID 1 运行 - 不要写
CMD ["./my-service"]单独启动——它会被 shell 封装，中断信号无法透传
多阶段构建中 go mod vendor 是必须的吗？
不是必须，但推荐。尤其当私有模块仓库不可达、或 CI/CD 网络受限时，go mod vendor 能锁定依赖快照，让构建更稳定。
- 第一阶段（builder）：
go mod vendor+go build，生成二进制 - 第二阶段（runtime）：只 COPY 二进制和必要配置（如
config.yaml），不带任何 Go 工具链或源码 - 注意：若用了
//go:embed，vendor 不影响嵌入行为；但go build -mod=vendor必须显式加参数才启用
容器内 Go 微服务怎么读取环境变量并热加载配置？
Go 标准库不支持自动热重载，os.Getenv 只在启动时读一次。真正要“动态”，得靠外部触发或轮询。
立即学习“go语言免费学习笔记（深入）”；
- 启动时用
os.Getenv("PORT")或viper.AutomaticEnv()读取容器环境变量 - 配置中心（如 Nacos、Consul）需集成客户端，监听变更事件后手动更新结构体字段
- 别依赖挂载的
config.yaml文件自动刷新——文件系统 inotify 在容器中行为不稳定，尤其是 overlay2 存储驱动
log.Printf 写到 stdout 是 OK 的，但一旦套了 logrus 并启用了异步写入或文件滚动，就可能丢日志或阻塞退出。务必确认日志库 flush 逻辑是否兼容容器生命周期。 
