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 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 确认上下文，能避开八成配置类问题。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！