GoLand Import Resolution Failures: A Diagnostic Guide When the CLI Build Works

The split-brain symptom

GoLand underlines imports in red and reports "Cannot find package" or "unresolved reference", yet running go build ./... in the terminal succeeds. This divergence is the signal: the compiler and the IDE are looking at different toolchains, module graphs, or caches. The useful takeaway is that when the command line works, the defect is almost always in the IDE's model of the project, not in the Go code itself.

What the IDE is actually telling you

GoLand resolves imports through its own index of the Go SDK and the module graph. When that index is stale, misconfigured, or pointing at the wrong GOROOT, the editor cannot map an import path to a source directory. The terminal, by contrast, invokes the real go tool every time and always sees the current state of go.mod and the local module cache.

Diagnostic table: where the views diverge

Observed in GoLand	Check in terminal / project	Likely bucket
Standard library imports unresolved	go env GOROOT differs from the SDK path in Settings > Go > GOROOT	SDK / GOROOT mismatch
Third-party imports unresolved, stdlib fine	go.mod missing or go mod tidy reports changes	Module metadata
All imports unresolved after adding a dependency	vendor/modules.txt exists but vendoring is disabled in IDE	Vendoring
Random or intermittent unresolved symbols	Event Log shows indexing errors after project open	Stale IDE cache

Ordered checks

1. Confirm the terminal build passes. In the project root, run go build ./.... If this fails, the problem is in the code or module metadata, not the IDE.
2. Compare the toolchain environment. Run go env GOROOT GOPATH GOFLAGS GOMOD GOPROXY. Open Settings > Go > GOROOT and Settings > Go > GOPATH in GoLand. The GOROOT path must match the SDK selected in the IDE. GOFLAGS should not contain -mod=vendor unless a vendor directory is present and intended.
3. Verify module mode and metadata. Ensure go.mod exists in the root and that the module path matches the import prefix used in the code. Run go mod verify to confirm the local cache matches the checksums in go.sum.
4. Check vendoring state. If vendor/ exists, look for vendor/modules.txt. When vendoring is active, GoLand must have vendoring mode enabled in Settings > Go > Go Modules; otherwise the IDE will not index the vendored sources.
5. Force a module graph sync. Click Sync in the go.mod banner, or run go mod download in the terminal. This rebuilds the IDE's view of the dependency graph.
6. Invalidate caches and restart. Use File > Invalidate Caches / Restart... and choose Invalidate and Restart. This clears the IDE's internal indices without touching the module cache on disk.

Fixes tied to findings

SDK / GOROOT mismatch

If go env GOROOT reports a path that differs from the SDK selected in the IDE, select the correct SDK in Settings > Go > GOROOT. Use the Local option and browse to the exact directory reported by go env GOROOT. After changing the SDK, choose File > Reload All from Disk so the project re-indexes against the new toolchain.

Incomplete module graph

When go mod tidy reports that it added or removed requirements, the module graph was incomplete. Run go mod tidy in the terminal, then go mod download. Return to GoLand and sync the project from the go.mod banner. Avoid hand-editing go.mod while the IDE is indexing; the IDE may not notice the change until a manual reload.

Vendoring inconsistency

If vendor/modules.txt exists but imports are unresolved, either enable vendoring in the IDE settings or remove the vendor directory if it is stale. To regenerate a consistent vendor tree, run go mod vendor in the terminal. Be aware that enabling vendoring while GOPROXY points to an unreachable proxy can hide network errors until the next sync, because the IDE will read from vendor/ instead of the proxy.

Stale IDE cache

If only GoLand is wrong after the checks above, File > Invalidate Caches / Restart... is the targeted fix. This operation only affects the IDE's local indices; it does not modify go.mod, go.sum, or the shared module cache. After restart, run go build ./... and go vet ./... in the terminal, then confirm GoLand shows no unresolved imports.

Environment alignment

GoLand does not always inherit the shell environment. If the terminal uses a custom GOPROXY or GOFLAGS, set the same values in Settings > Go > Go Modules or in the IDE's environment variables. A common mismatch is a terminal configured with GOFLAGS=-mod=mod while the IDE defaults to -mod=readonly, causing the IDE to ignore changes that the terminal accepts.

Escalation criteria

Stop debugging the IDE and fix the project when go build ./... fails in the terminal. That means the defect is in source code or module metadata.

Escalate to a vendor issue only when the terminal build succeeds but GoLand still fails after you have corrected the SDK, synced the module graph, aligned the environment, and invalidated caches. Before filing a report, reproduce the issue deterministically: close the project, delete the .idea directory, and reopen the folder. If the error returns only in GoLand, collect the IDE logs via Help > Collect Logs and Diagnostic Data, note the GoLand build from Help > About, record the Go toolchain version from go version, and attach the output of go env plus a minimal project that triggers the failure.

Version sensitivity and limitations

GoLand supports a bounded range of Go toolchain versions per release train. A very new Go release may require a newer GoLand before the IDE can parse its module metadata. Conversely, older projects that predate module mode may need explicit configuration. Confirm compatibility before deep debugging: compare the Go version reported by go version with the supported range in the GoLand release notes.

Do not run go clean -modcache on shared machines or CI runners. It deletes every downloaded module and forces a full re-download, which can break concurrent builds and mask the original problem. If you suspect a corrupted local cache, test in an isolated GOPATH first by setting GOPATH=/tmp/isolated-gopath in the terminal and running go mod download there.

Practical verification

After any fix, run go build ./... and go vet ./... in the terminal. In GoLand, choose File > Reload All from Disk and confirm that red underlines disappear from imports. Open Settings > Go and verify that the configured SDK path matches go env GOROOT. If all three agree and the editor is clean, the divergence is resolved.