GoLand的“Build”仅执行语法检查、类型分析和依赖解析（调用go list -json和gopls），不生成二进制，也不触发go mod download；要编译可执行文件须手动运行go build或配置Run Configuration为“Go Build”。
GoLand 里点“Build”到底干了什么
GoLand 的 Build 操作默认不调用 go build 编译可执行文件，而是只做语法检查 + 类型分析 + 依赖解析 —— 本质是触发 go list -json 和 gopls 的静态分析流程。它不会生成二进制，也不会运行 go mod download（除非你开了自动同步）。很多人误以为点了 Build 就等于编译成功，结果一运行就报 command not found 或 undefined: xxx，根源就在这。
- 真正要生成可执行文件，得手动执行
go build或配置 Run Configuration 为 “Go Build” - 如果项目有
main.go但没被 GoLand 识别为入口（比如放在非main包或路径含特殊符号），Build会静默跳过构建逻辑 - 关闭
Settings > Go > Build Tags中的 “Use build tags from environment” 可避免因 tag 不匹配导致的误报未定义符号
Run Configuration 怎么配才不踩坑
GoLand 的运行配置决定你最终跑的是源码、测试还是二进制。默认的 Go Application 类型会尝试找 main 函数，但失败时不报错，只显示 “Process finished with exit code 0” —— 实际啥也没运行。
- 务必检查
Run kind：选Package（推荐）比Directory更可靠，尤其多模块项目 -
Working directory必须设为模块根目录（即含go.mod的路径），否则go run会找不到依赖或读错.env - 若用
go:generate，勾选Run go generate before run；但注意它只在 Run 时触发，Build 不触发 - 环境变量写在
Environment variables栏，不要塞进Program arguments，否则会被当命令行参数传给main()
为什么改了代码，Build 没反应？
常见现象：改完 main.go，点 Build 没提示错误，但运行还是旧行为。根本原因不是缓存，而是 GoLand 默认不监听 .go 文件变更后自动重构建 —— 它只对编辑器内实时语义高亮和跳转做响应，Build 是手动触发动作。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 开启自动构建需手动启用：
Settings > Tools > File Watchers > + > Go > go build，并设置Scope为 Project Files - 但更稳妥的做法是绑定快捷键（如
Ctrl+Shift+B）直接运行go build -o ./bin/app .，避免依赖 IDE 内建逻辑 - 如果用了
//go:build注释控制构建，确保Settings > Go > Build Tags里填了对应 tag，否则 Build 阶段直接忽略该文件
Go modules 依赖不下载？Build 不报错但运行失败
GoLand 不会主动执行 go mod download 或 go mod tidy，即使 go.mod 明显缺失依赖。它只读取已缓存的 module 信息，所以你可能看到 “Import XXX not resolved”，却没红色波浪线，Build 也通过。
立即学习“go语言免费学习笔记（深入）”；
- 首次打开项目后，右键
go.mod→Reload project才会触发go mod download - 如果
GOROOT或GOPATH被 IDE 错误覆盖（比如用了系统旧版 Go），会在Event Log里报go list failed，但 Build 界面不显示 - 检查
Settings > Go > GOPATH是否为空：现代 Go 项目应留空，交由go mod管理，填了反而干扰
最常被忽略的一点：GoLand 的 Build 和 Run 是两套独立机制，前者不保证后者能运行，后者也不依赖前者产物。调试时别只盯着 Build 成功，得确认 go list -f '{{.Name}}' . 能正确输出 main，且 go build -v 在终端里能干净完成。
