必须将Go SDK、Goland和GOPATH分别迁至短路径盘符（如D:Go、D:JetBrainsGoland、D:g），启用模块模式避免GOPATH/src冗余，CI/Docker中显式设置短WORKDIR，并修正所有硬编码长路径。
Go安装路径和GOPATH不能都堆在C盘
默认全塞C盘是路径冗余的根源。Go SDK、Goland、GOPATH三者默认位置加起来可能占掉2GB以上，且路径层级深（如C:UsersAlicegosrcgithub.comorg
epo...deep
ested），直接导致go build在Windows上因命令行参数超长失败，或os.Open报no such file or directory——不是文件不存在，是路径被系统截断了。
必须把三者拆开，优先挪到短路径盘符下：
-
Go SDK重装到D:Go（而非C:Go） -
Goland自定义安装路径为D:JetBrainsGoland -
GOPATH设为D:g（不是D:UsersAlicego这种嵌套结构）
改完后执行go env -w GOPATH=D:g，并确认go env GOPATH输出已更新。别依赖IDE自动继承环境变量，手动验证。
模块模式下GOPATH只是后备，不是主路径
Go 1.11+ 默认启用模块（module）模式，go.mod所在目录才是项目根，GOPATH只在没go.mod时兜底。大量冗余路径其实是旧式$GOPATH/src组织方式残留。
立即学习“go语言免费学习笔记（深入）”；
新项目一律用go mod init example.com/myapp初始化，之后所有依赖存于go.sum和本地pkg/mod缓存，不再写入GOPATH/src。已有项目可直接删掉$GOPATH/src下对应目录，只要go.mod存在，go build仍能正常解析导入路径。
检查是否真走模块：运行go list -m，若输出含mod字段且非std，说明已在模块模式；否则补go mod init。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
CI/CD和Docker里路径要硬编码WORKDIR
本地开发路径短不代表CI环境也短。GitHub Actions或GitLab CI默认工作目录可能是/home/runner/work/repo/repo，Docker构建中WORKDIR /home/user/go/src/github.com/...会瞬间让路径爆炸。
必须显式缩短：
- GitHub Actions：用
env: GOPATH: /tmp/g+run: go env -w GOPATH=/tmp/g - Dockerfile：写
WORKDIR /app，而不是沿用宿主机深层路径；复制代码用COPY . .而非COPY $HOME/go/src/... /app - 避免
mklink或符号链接指向深层路径——go build不解析它们，反而会让内部路径展开后翻倍
构建失败时先看日志里exec: "gcc": executable file not found这类错误——它常是路径过长导致exec.Command传参失败的伪装，不是真缺gcc。
filepath.Join不能修复已存在的冗余路径
filepath.Join只负责拼接时安全，对历史遗留的长路径无能为力。比如os.Open("C:\Users\A\go\src\x\y\z\...\file.txt")即使传给filepath.Join也救不回来。
真正要动的是源头：
- 所有配置文件里的路径字段（如
log_dir: "/home/user/go/src/..."）必须人工替换成相对短路径，或用filepath.Join(os.Getenv("APP_ROOT"), "logs")动态生成 - 脚本中硬编码的
"../.."向上跳转，改成filepath.Dir(filepath.Dir(os.Executable()))获取二进制所在目录，再向下拼 - 用户输入路径必须先
filepath.Abs再filepath.Clean，但长度超限（Windows >260）时Abs本身就会失败——这时得提前截断或改用"\\?\C:\..."UNC前缀
路径冗余不是拼错的问题，是工程组织问题。修一次Join调用没用，得从安装、模块、CI、配置四层一起压平。
