goland不识别go.work的根本原因是未手动重载项目且goroot、goflags、工作目录未对齐；须右键根目录“reload project”、goroot指向go安装根并重启、goflags设-mod=mod、run configuration工作目录设为$projectfiledir$。
GoLand 里跑不起来 go work 工作区？不是配置错了，是它根本没加载 go.work 文件——IDE 默认不自动识别工作区，必须手动触发重载，且路径、GOROOT、GOFLAGS 全得对齐。
GoLand 不识别 go.work 的典型表现
新建或修改了 go.work，但 import 依然标红、右上角运行按钮灰掉、go run 报 “module not found” 或 “main module does not contain package”。这不是代码问题，而是 GoLand 没把当前目录当 workspace 根来处理。
- 检查
go.work是否真在你打开的项目根目录下（不是子文件夹，也不是父级） - 确认 GoLand 当前 Project 视图的根路径和
go.work所在路径完全一致 - 运行
go work edit -print，如果报no work file found，说明 IDE 进程压根没读到它 - 别依赖 “Sync” 或 “Reload cache”，必须右键项目根目录 → “Reload project”
GOROOT 和 GOFLAGS 必须显式对齐
GoLand 启动时会缓存 Go 环境变量，GOWORK 和 -mod=readonly 这类设置一旦错位，workspace 就彻底失效。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
Settings → Go → GOROOT必须指向 Go 安装根目录（如/usr/local/go），不是/bin/go；改完必须重启 IDE - 进
Settings → Go → Go Modules，确保 Proxy 填的是https://goproxy.cn,direct（缺direct会导致私有模块 fallback 失败） - 检查
GOFLAGS：如果设了-mod=readonly，go work use添加模块后不会自动更新go.work，导致后续命令找不到路径 - 终端里执行
go env GOWORK，应返回具体路径（如/path/to/my-monorepo/go.work），若为空或off，说明 Go 版本低于 1.18 或环境未生效
Run Configuration 必须用对工作目录
GoLand 默认按单模块逻辑启动 go run，若没指定上下文，它不会主动加载 workspace。哪怕 go.work 存在，go run main.go 仍可能去拉远程版本。
- 编辑 Run Configuration → Working directory 改为
$ProjectFileDir$（即go.work所在目录） - Program arguments 填
./cmd/myapp或./service-a，不要填main.go—— 后者绕过 module 解析，无法触发 workspace 路径映射 - 别勾选 “Add content root to classpath” 或 “Use classpath of module”，Go 项目不走 Java 那套
- 验证方式：在 Run Configuration 中点 “Modify options → Show command line afterwards”，看实际执行的是否是
go run ./service-a且当前路径确实是 workspace 根
CI/CD 和 Git 提交前最容易被忽略的三件事
workspace 是纯本地开发上下文，上线构建、CI 流水线、甚至同事拉代码后首次打开 IDE，都默认不启用它。
-
go.work文件建议提交，但要在 README 明确写清：“仅用于本地开发，CI 构建禁用” - 各子模块的
go.mod中，删掉所有replace行——它们和go.work冲突，且上线时没意义 - CI 脚本里统一用
go build -mod=mod或go mod vendor，别调go work命令；否则流水线会失败 - 团队协作时，
go.work里的路径必须是相对路径（如./service-a），不能带../或绝对路径，否则别人 clone 后直接失效
