不能直接用 go run 启动容器里的 Go 程序，因为生产镜像（如 alpine:latest 或 scratch）不含 go 命令，仅构建镜像（如 golang:alpine）才包含；且 go run 依赖源码和 Go 工具链，不符合容器最小化、不可变原则。
为什么不能直接用 go run 启动容器里的 Go 程序
Go 程序在容器中运行失败，常见原因是开发机编译的二进制文件依赖本地 libc 或调试符号，而 Alpine 镜像（Docker 默认轻量镜像）没有这些。更关键的是：go run main.go 在容器里会失败——因为 go 命令本身不在生产镜像里，只存在于 golang:alpine 这类构建镜像中。
正确做法是：先编译出静态链接的可执行文件，再 COPY 到精简镜像（如 alpine:latest 或 scratch）中运行。
- 用
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o app .编译静态二进制 - 避免使用
golang:alpine作为最终运行镜像，它体积大、含多余工具、不安全 - 若项目依赖 cgo（如 SQLite、某些 crypto 库），必须保留
CGO_ENABLED=1，并选用含 musl-gcc 的基础镜像（如golang:alpine构建 +alpine:latest运行）
docker-compose.yml 中如何正确分层构建与运行
单阶段构建会导致镜像臃肿且暴露源码和构建工具；不加 build.args 会让环境变量无法透传；不指定 working_dir 可能导致相对路径出错。
version: '3.8'
services:
api:
build:
context: .
dockerfile: Dockerfile
args:
- GO_ENV=production
ports:
- "8080:8080"
environment:
- GIN_MODE=release
- PORT=8080
restart: unless-stopped
working_dir: /app
-
args仅在构建时生效，用于控制Dockerfile中的ARG，比如切换依赖源或启用调试模式 -
environment是容器运行时注入的环境变量，Go 程序用os.Getenv("PORT")读取 -
working_dir必须与COPY目标路径一致，否则./config.yaml这类相对路径会找不到文件
本地开发时如何让 Go 代码修改后自动热重载
Docker Compose 默认不会监听宿主机文件变化，go run 也不支持跨容器文件监控。要实现保存即重启，得靠外部工具介入容器内进程管理。
Pilot Digital Twin Setup
下载
部署一个包含 4 个智能体（agent）的数字孪生平台。在以下情况下使用该技能： 1. 用户希望为物理资产监控与预测性维护等场景搭建数字孪生系统……
立即学习“go语言免费学习笔记（深入）”；
- 开发阶段使用
golang:alpine镜像，并安装air：go install github.com/cosmtrek/air@latest - 挂载源码目录：
volumes: ["./:/app:cached"]（macOS/Linux）或["./:/app:delegated"]（Docker Desktop for Mac） - 覆盖默认命令：
command: sh -c "cd /app && air --cfg .air.toml" - 务必在项目根目录放
.air.toml，配置root = "./"和tmp_dir = "tmp"，避免写入只读层
数据库连接、日志和配置怎么在容器间可靠传递
硬编码 localhost:5432 在容器里永远连不上 PostgreSQL；log.Printf 输出被 Docker 捕获但格式混乱；.env 文件默认不会被 docker-compose 自动加载到容器环境。
- 数据库地址必须用服务名：
postgres://user:pass@db:5432/myapp（db是 compose 中 service 名） - 用
logging.driver: "json-file"+logging.options.max-size: "10m"统一收集日志，避免fmt.Println冲突 - 敏感配置走
secrets或env_file：env_file: .env.local，但注意.env（顶层）会被 Compose 自动读取，无需显式声明 - Go 程序启动前加健康检查脚本（如
wait-for-it.sh db:5432 -- ./app），防止因依赖未就绪而崩溃退出
Go 容器化真正难的不是写几行 YAML，而是搞清「哪部分该在构建时决定、哪部分必须运行时注入、哪些路径在 bind mount 后实际指向哪里」——这三个边界模糊了，docker-compose up 就会变成猜谜游戏。
