PATH未生效导致go run报错，需确认go路径并添加至shell配置后source；WSL中go mod init不可用/mnt/c/路径，须改用原生路径；go get -d仅下载不编译，-u强制更新依赖。
Go 环境搭建不是“装完 go version 能跑就行”，真正卡住人的，是 PATH 没生效、模块初始化路径错、跨系统路径权限异常这三类问题。尤其在 WSL 或 macOS 上，go mod init 用 Windows 路径或 /mnt/c/ 开头的目录会直接失败。
go version 能输出但 go run 报 command not found 怎么办
这是典型的 PATH 未正确加载。安装 Go 后解压到 /usr/local/go，但 shell 并不知道这个路径要加入可执行搜索范围。
- 确认
go二进制实际位置：ls -l /usr/local/go/bin/go - 检查
~/.bashrc或~/.zshrc是否包含：export PATH=$PATH:/usr/local/go/bin - 修改后必须执行：
source ~/.bashrc（或source ~/.zshrc），仅重启终端不够 - 验证：
echo $PATH输出里要有/usr/local/go/bin，否则which go仍为空
go mod init 在 /mnt/c/ 下失败的根源
WSL 中访问 Windows 文件系统（如 /mnt/c/Users/xxx/project）时，Go 的模块系统会因文件权限和路径语义不一致报错，常见错误：go: modules disabled by GO111MODULE=off 或 permission denied。
- 项目必须放在 WSL 原生路径下，例如：
~/projects/myapp -
go mod init myapp必须在该目录内执行，不能带绝对路径或 Windows 风格路径 - Windows 侧通过
\wsl$Ubuntu-22.04homeusernameprojects访问，而非/mnt/c/ - VS Code 连接 WSL 时，务必用 “Open Folder in WSL” 而非 “Open Folder”，否则工作区路径仍走 Windows 层
go build 和 go run 的行为差异与陷阱
两者都编译源码，但生命周期和产物处理完全不同，选错会导致调试困难或部署失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
go run main.go：编译后立即执行，临时二进制不落地，适合快速验证逻辑 -
go build（无参数）：生成与当前目录同名的可执行文件，比如在myapp/下运行，产出myapp -
go build -o ./bin/app：明确指定输出路径，避免污染项目根目录 - 交叉编译必须关 CGO：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app-linux，否则可能链接 Windows 动态库失败
go get 的 -u 和 -d 参数到底影响什么
很多人以为 go get 就是“装包”，其实它同时承担下载、编译、安装三件事，参数控制粒度很细。
-
go get github.com/gin-gonic/gin：下载 + 编译 + 安装（即把包放进$GOPATH/bin） -
go get -d github.com/gin-gonic/gin：只下载源码，不编译也不安装，适合你只想看代码或手动构建 -
go get -u github.com/gin-gonic/gin：强制更新已有包及其所有依赖，但可能破坏兼容性——除非你明确需要新版本，否则别加-u - Go 1.16+ 默认启用模块模式，
go get会写入go.mod，所以执行前确保已在模块根目录
环境变量、路径语义、命令副作用这三点，比语法本身更常导致“明明按教程做了却不行”。每次新建项目，先 pwd 看清当前路径，再 go env GOPATH 和 go env GOMOD 确认上下文，能避开八成配置类问题。
