go.mod文件必须位于Docker构建上下文根目录且路径与模块声明严格一致，否则go build报错；WORKDIR和COPY需匹配模块路径，go.sum须一同COPY，CGO_ENABLED=0下仍校验go.sum但忽略vendor，ConfigMap挂载go.mod无效。
go.mod 文件路径必须与 GOPATH 和容器内 WORKDIR 严格对齐
Go Modules 的解析依赖于模块路径（module github.com/yourorg/yourapp）与磁盘实际路径的一致性。Kubernetes 部署时，Docker 构建阶段若 WORKDIR 或 COPY 路径错位，会导致 go build 报错 cannot find module providing package。
-
go.mod必须放在构建上下文根目录（即Docker build .的.所指位置），否则go mod download会失败 - 多阶段构建中，
COPY . .前必须WORKDIR /app，且项目源码需以该路径为基准组织——不能把go.mod放在子目录再COPY ./src/ . - 若模块路径是
github.com/example/api，则容器内源码必须位于/app（对应模块根），而非/app/src或/app/internal
CGO_ENABLED=0 下 go.sum 校验仍生效，但 vendor 目录被忽略
启用 CGO_ENABLED=0 不影响模块校验逻辑，go build 仍会读取 go.sum 并验证 checksum。但此时 vendor 目录完全不参与构建——即使存在也不会被加载，所有依赖均从 go.mod 指向的远程模块拉取。
- 常见错误：本地开发启用了
go mod vendor，却在 Dockerfile 中漏掉RUN go mod download，导致构建阶段网络不通时直接失败 - 生产镜像应显式执行
RUN go mod download && go mod verify，避免运行时首次加载依赖引发延迟或失败 -
go.sum文件必须随go.mod一起COPY，否则go build会报missing go.sum entry
Kubernetes 中 ConfigMap 挂载的 go.mod 无法被 go toolchain 识别
有人试图把 go.mod 通过 ConfigMap 挂载进 Pod 用于运行时动态依赖管理——这是无效的。go 工具链只在构建期读取 go.mod，运行时二进制文件已不含模块信息，挂载的 go.mod 对已编译程序毫无作用。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 挂载
ConfigMap只适用于配置文件（如config.yaml）、证书、模板等运行时资源 - 若需“热更新”依赖逻辑，必须重新构建镜像、发布新版本 Deployment，而非尝试运行时改模块定义
- 误挂载
go.mod还可能因权限问题（如只读挂载）导致应用启动时尝试写入失败
跨平台构建时 GOOS/GOARCH 与 Kubernetes 节点架构不匹配会导致 CrashLoopBackOff
本地用 GOOS=darwin GOARCH=arm64 go build 编译出的二进制，在 Linux amd64 节点上运行会直接报 exec format error，Pod 状态变成 CrashLoopBackOff，且日志里看不到 Go 应用输出——因为根本没执行到 main 函数。
立即学习“go语言免费学习笔记（深入）”；
- Dockerfile 中必须显式设置
GOOS=linux，无论宿主机是什么系统 - 若集群混合了 arm64 和 amd64 节点，需构建多架构镜像，并在
Deployment中通过nodeSelector或tolerations控制调度 - 检查镜像架构：运行
docker inspect <image> | jq '.[0].Architecture'，确保与目标节点一致
Docker build 阶段就决定能否成功生成二进制的关键前提。一旦构建完成，Kubernetes 里跑的只是个静态文件，和 go.mod 再无任何关系——这点最容易被当成运行时配置来折腾。 
