GoLand
代码能跳转，仍可能不属于当前 module
GoLand 打开一个 Go 仓库后，常能立刻识别类型并跳转。真正运行 go test ./... 时却可能从另一个 module 根开始，使用错误的 go.work，或从开发者私有的 replace 路径读取依赖。编辑体验看起来完整，构建结果却无法交给 CI。此时清索引不会修复项目边界，因为索引只是把错误输入分析得更快。
Go 项目的执行事实来自 Go SDK、go.mod、可能存在的 go.work、环境变量和源码。GoLand 在这些输入上建立 module 模型、代码分析、运行配置与调试会话。GOROOT 指向工具链，GOPATH 主要承载安装产物与 module/sumdb 缓存；现代 module 项目不要求业务源码住在 GOPATH。把这几个对象混在一起，是团队最常见的旧经验回流。
安装与许可不能沿用“有免费社区版”的假设
个人开发机可以通过 JetBrains Toolbox 安装稳定版 GoLand，并为升级试点并存一个新实例。组织已有终端分发时，可用官方 standalone 包固定来源和卸载责任；隔离环境还要准备 Go 工具链、module proxy 或批准的离线依赖，而不是只搬入 IDE 安装包。
安装后从 Help | About 记录产品 build、IDE runtime、OS 与 CPU 架构，再检查账号许可、代理、企业 CA 和插件。GoLand 官方 FAQ 说明它没有 Community Edition；试用、教育、开源计划和个人用途许可也不能自动转化为商业团队的席位策略。动态条款回到 GoLand FAQ 与注册入口复核，工单和截图不保留激活信息。
升级时把 IDE 与 Go 工具链拆成两次变更。代表仓库先在旧 GoLand 和目标 GoLand 中分别完成 module 加载、生成、测试、断点与停止，再决定推广。Toolbox 保留旧实例会占空间，却提供直接回退；删除上一实例后，不应把清缓存误称为版本回滚。
先用 Go 命令打印项目指纹
打开仓库前，在外部终端保留下面这组输出：
go version
go env GOROOT GOPATH GOMOD GOWORK GOENV GOPROXY GOPRIVATE GONOSUMDB
go list -m -json
go list -m all
go test ./...这些命令分别说明实际 toolchain、module 根、workspace 文件、持久环境覆盖、依赖来源和测试结果。敏感的私有模块路径、代理地址与用户名在共享证据中脱敏。GoLand 的 Go SDK 应对应 go env GOROOT 所代表的受支持工具链，内置终端与运行配置也要能解释差异。
GOROOT 与 GOPATH 官方说明仍会展示 GOPATH 的全局、项目与 module 范围配置，但 module 模式下不应靠把业务源码塞进 GOPATH 修复导入。GOMOD 指向 /dev/null 或空值时，先确认当前目录是否真的在 module 内；随意把目录标成 source root，只会让 IDE 与 Go 命令进一步分叉。
Go 的 toolchain 选择还可能受 go 指令、toolchain 指令和 GOTOOLCHAIN 影响。团队要明确是否允许 auto 下载满足项目声明的工具链，还是在受控环境使用 local 禁止切换。IDE 下拉框显示某个 SDK 名称不够，测试进程的 go version 才是最终证据。
go.mod 与 go.work 处理的是不同范围
go.mod 定义一个 module 的路径、Go 版本、依赖与 replace；go.work 在本地或 monorepo 场景组合多个 module。团队若把个人临时 go.work 留在仓库上级，GoLand 与终端可能自动进入 workspace，而 CI 只构建单个 module。相反，仓库正式维护 go.work 时只打开某个子 module，又会失去跨 module 的统一视图。
先执行 go env GOWORK，再决定 GoLand 打开哪一层。正式 workspace 文件应进入评审，use 的目录必须在干净 clone 中存在；只服务个人实验的 workspace 放在明确忽略位置，并在运行前关闭或显式指定。replace ../local-copy 同样要解释：它若只在作者磁盘存在，就不是可交付依赖。
下面的实验用两个 module 证明 workspace 会改变解析结果：
$lab = Join-Path $env:TEMP "goland-workspace-lab"
Remove-Item -Recurse -Force $lab -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path (Join-Path $lab "app") -Force | Out-Null
New-Item -ItemType Directory -Path (Join-Path $lab "lib") -Force | Out-Null
@'
module example.com/lib
go 1.23
'@ | Set-Content -Encoding utf8 (Join-Path $lab "lib\go.mod")
@'
package lib
func Message() string { return "workspace-ok" }
'@ | Set-Content -Encoding utf8 (Join-Path $lab "lib\lib.go")
@'
module example.com/app
go 1.23
require example.com/lib v0.0.0
'@ | Set-Content -Encoding utf8 (Join-Path $lab "app\go.mod")
@'
package main
import ("fmt"; "example.com/lib")
func main() { fmt.Println(lib.Message()) }
'@ | Set-Content -Encoding utf8 (Join-Path $lab "app\main.go")
Push-Location $lab
go work init .\app .\lib
go run .\app
Remove-Item .\go.work
go run .\app
$negativeExit = $LASTEXITCODE
Pop-Location
"negative_exit=$negativeExit"
Remove-Item -Recurse -Force $lab存在 go.work 时正例输出 workspace-ok；删除 workspace 后，app 无法从本地找到未发布的 lib，返回非零退出码。在 GoLand 中打开实验根目录应识别两个 module；若只打开 app，IDE 仍通过缓存跳转到 lib，就要重新加载 module 并核对 GOWORK，不能把旧索引当作当前解析结果。
示例的 go 1.23 是 Go 语言版本声明，不是文章日期。实际项目使用自己的受支持版本。实验结束会删除临时目录，不修改全局 go env -w 状态。
私有 module 的四层配置不能塞进 .idea
私有依赖通常同时涉及 GOPRIVATE/GONOSUMDB、GOPROXY、Git 凭证和企业 TLS 信任。GOPRIVATE 决定哪些 module 不走公共 proxy/sumdb 的默认行为，但它不提供仓库认证；GOPROXY 可配置直连或内部代理，却不会替 Git 修复 SSH/HTTPS 身份。浏览器能打开仓库也不证明 go mod download 能成功。
诊断时先运行 go env 和 go mod download -x，记录脱敏后的目标、使用协议、错误类别与退出码。凭证进入系统凭证管理、SSH agent 或受控 secret 工具；真实 token、用户名、内部 module 路径和 CA 文件位置不提交 .idea 或 Run Configuration。关闭 GOSUMDB、跳过 TLS 或把所有域名放进 GONOSUMDB 都会扩大供应链盲区。
离线构建要验证完整 module graph、zip/mod/info 元数据、校验策略与撤销。只把 $GOMODCACHE 从某台开发机打包，会混入平台无关但来源不明的历史内容，也无法说明哪些版本被批准。更稳的是受控 proxy 或按 go mod download 解析出的依赖清单归档，并用干净缓存复验。
测试、生成与调试应共享同一个 module 世界
GoLand 的运行配置不应复制一套与仓库不同的 build flags。先从外部终端运行 go test ./...，需要 tags、race、cover 或 integration 环境时，把入口固化为脚本或任务。IDE 测试窗口再调用同一 package 与参数。只有 IDE 里点击通过、CI 不知道参数的配置不是团队资产。
go generate、protobuf、mock 或 stringer 产物也要区分项目事实与派生状态。仓库若提交生成代码，就验证生成后 Git diff 可解释；若不提交，就在 bootstrap/build 前生成并把工具版本锁定。GoLand 的代码分析不能替生成命令，手工把缺失目录标为 generated source 也不会产生文件。
最小调试应在测试或 main 入口设置断点，确认目标二进制由预期 Go toolchain 构建，调用栈对应当前 clone，环境变量与工作目录正确。停止后目标进程退出。远程、容器或 WSL 场景还要明确 Delve、源码和目标进程的位置；生产环境开放调试端口不属于日常开发捷径。
调试器或 -race 与当前 Go 发行线、架构可能有兼容边界。升级 GoLand 后断点失效时，比较 Go、Delve、目标架构与优化参数，不要先删整个 module cache。使用 -gcflags=all=-N -l 等参数会改变性能和产物，只在受控调试配置中使用。
索引、module cache 与构建缓存有不同 owner
GoLand project analysis 是可重建派生状态；$GOMODCACHE 保存下载 module，Go build cache 保存编译结果，IDE system 目录保存索引与 Local History。它们都占磁盘，但恢复代价和供应链意义不同。通用“清理 GoLand”脚本若同时删除三层，会把索引故障升级为大规模重新下载，隔离环境甚至无法恢复。
遇到编辑器红线而 go test 成功，先 Reload Go Modules，检查 GOMOD、GOWORK、GOROOT、build tags 与生成源码。输入一致后才重建索引。构建缓存可用 Go 官方命令查看和清理；module cache 只有在来源可重新取得、没有离线保留需求时才处理。Local History 不是版本控制，清 IDE system 目录前把未提交修改保存到 Git 或其他恢复点。
卸载 GoLand 也要分别处理 IDE 实例、配置、system/cache、Go SDK、module cache 与项目源码。取消席位不意味着删除 Go 工具链；开发者离职时则要撤销 JetBrains 账号、私有仓库凭证、插件源访问和本地 secret，而不是只卸载应用。
失败现象要回到 module、toolchain 或进程
“cannot find package” 首先检查当前目录、GOMOD、GOWORK 和 go list -m all。如果 CLI 失败，修复 module/workspace 或依赖；如果 CLI 成功而 IDE 失败，再重载模型和索引。
私有依赖卡住时比较 proxy、Git 协议、凭证和 CA 链。GoLand 插件登录成功与 go mod download 无关。修复后使用干净 module cache 下载并运行测试，避免旧缓存替错误配置兜底。
测试在 IDE 通过、CI 失败时，查本地 replace、未提交 go.work、全局 go env -w、build tags 和生成物。把必要输入移回仓库或 CI Secret，清除个人全局覆盖，再从干净 clone 复验。
断点空心或变量异常时，确认实际 PID、二进制、编译参数、Delve 与架构。应用已经被热重启或测试缓存复用时，调试器可能连着旧进程；正常停止并重新启动，比重复点击 Attach 更容易恢复可解释状态。
团队选型要算工具链一致性与退出成本
一份可支持的 GoLand 基线应证明：安装与商业许可可追溯，Go SDK 和 toolchain 策略明确，module/workspace 在干净 clone 可解析，私有依赖不依赖个人凭证，测试与生成入口和 CI 一致，调试能命中并退出，批准插件可重建，上一 IDE 实例可回退。
大型仓库还要测量 module 数量、项目分析时间、内存、文件 watcher 与缓存磁盘。优化先从正确 workspace、生成目录、vendor 和工具链入手；把 module 排除或关闭 inspection 能降低负载，也可能破坏跨 module 重构与引用分析。
GoLand 的价值通常来自 Go 专用项目模型、重构、测试和调试的整合。如果团队已有 IntelliJ IDEA 订阅并通过 Go 插件满足代表仓库，或更偏好 VS Code/命令行组合，应比较席位、插件治理和升级成本。无论选择哪款 IDE，退出条件不变：仓库没有 GoLand 仍能下载依赖、生成、构建、测试和发布；.idea 不能成为唯一工程说明。