ci中go test ./失败主因是工作目录、模块路径与go111module未对齐，需显式cd项目根、设go111module=on、用go test ./并确保go.mod声明与import路径一致。
CI里go test ./失败，90%不是代码问题，而是环境没对齐。本地能过、CI报import path not found或cannot find package，根本原因是工作目录、模块路径、GO111MODULE三者没同步。下面直说怎么调、为什么这么调、哪里容易翻车。
确保go test在项目根目录执行
GitHub Actions 默认在仓库根目录，但 Jenkins 或自建 GitLab Runner 常默认在 workspace 根，而非你期望的 module 根。一旦go.mod不在当前目录，go test ./就会递归扫描到无关子目录，甚至误加载其他go.mod。
- 显式
cd $PROJECT_ROOT（Jenkins/GitLab CI 必加）；GitHub Actions 若用actions/checkout@v4则通常已就位，但建议仍加run: pwd && ls -la确认 - 避免用
go test .：它只测当前包，漏掉子包；也别用go test ./...：它会跨 module 扫描，可能触发错误 import - 坚持用
go test ./——前提是当前目录有go.mod且module声明与导入路径一致（例如module github.com/org/service，所有import必须以该前缀开头）
强制启用 Go Modules 模式
旧版 CI 环境可能残留 GOPATH 模式痕迹，go test会退化为 GOPATH 查找逻辑，直接忽略go.mod。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 显式设置
GO111MODULE=on：GitHub Actions 默认开启，但 Jenkins/GitLab CI 必须在 step 开头export GO111MODULE=on - 不要依赖
go env -w GO111MODULE=on：它写入用户级配置，在无状态 CI 容器中无效 - 验证是否生效：
go env GO111MODULE输出应为on，不是auto或空
构建二进制时裁剪体积但保留调试能力
微服务镜像大小直接影响部署延迟和安全面。默认go build产物含完整符号表和 DWARF 信息，20MB+ 很常见，但其中 60%~70% 可安全移除。
- 必加
-ldflags="-s -w"：-s删符号表，-w删 DWARF 调试信息；两者合用不破坏runtime.Caller或pprof功能 - 慎用
-trimpath：它让runtime.Caller返回 clean 路径（如main.go:12），但某些日志框架依赖绝对路径做 trace 关联，建议仅在 release 镜像启用 - 验证结果：
file myservice应显示statically linked；ls -lh myservice应≤ 12MB（禁用 CGO 时）
静态检查只开阻断型 linter
全量启用golangci-lint会让 CI 变慢、误报多，尤其gosimple和staticcheck对泛型支持尚不稳定。
- 必启：
govet（标准库静态分析）、errcheck（忽略 error 的硬伤）、ineffassign（无用赋值）、nilness（空指针推断） - 建议关闭：
golint（已废弃）、stylecheck（命名风格争议大）、dupl（模板生成代码易误报） - 加
run.timeout: 3m到.golangci.yml，防大项目卡死；CI 步骤里用golangci-lint run --timeout 5m兜底
最常被跳过的其实是go.mod声明与实际 import 路径的一致性——改了 module 名但忘了同步所有import语句，CI 就会静默失败。每次重构路径后，务必跑一遍go list -m all和go mod graph | grep "missing"扫一眼。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
