GoLand打开老GOPATH项目import报错，需启用GOPATH模式：勾选Settings→Go→GOPATH，确保路径指向$GOPATH，项目位于$GOPATH/src下，删除go.mod，重启IDE即可识别短路径import。
GoLand 里打开老 GOPATH 项目时 import 报错怎么办
GoLand 默认启用 Go Modules，但老项目没 go.mod、路径写成 "utils" 或 "server/handler" 这类短路径，就会直接报 cannot find package。这不是 GoLand 的 bug，是 Go 构建工具链在 Modules 模式下拒绝 fallback 到 GOPATH 解析。
解决办法不是关掉 Modules，而是让 GoLand 知道：这个项目得走 GOPATH 模式。
- 打开 Settings → Go → GOPATH，勾选 Enable GOPATH mode
- 确保
GOPATH路径指向你存放老项目的根目录（比如/home/user/go），且项目实际在$GOPATH/src/github.com/xxx/oldproj下 - 检查项目根目录下没有
go.mod文件——如果有，删掉或重命名，否则 GoLand 会优先走 Modules - 重启 GoLand，再打开项目，
import "utils"这类写法就能被识别了
为什么不能直接用 go mod init 迁移老项目
能 init，但 init 后不改 import 路径就编译不过。GoLand 会提示 unresolved reference，因为 go mod init oldproj 生成的模块名是 oldproj，而老代码里写的 import "utils" 并不等于 oldproj/utils —— Go 不会自动把当前模块名拼上去。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 必须手动把所有
import "utils"改成import "oldproj/utils"（前提是utils/在项目根目录下） - 如果老项目结构是
$GOPATH/src/company/app，那模块名就得设成company/app，否则import "app/utils"依然失败 -
go list -f '{{.Dir}}' oldproj/utils可验证路径是否被模块系统识别；如果报错，说明 import 路径和模块声明不匹配
GoLand 中混用 GOPATH 和 Modules 的风险点
同一个 GoLand 工作区里，既有带 go.mod 的新模块，又有纯 GOPATH 老项目，很容易出现构建行为不一致：一个文件能跑，另一个报错，调试时符号跳转失效。
- GoLand 的 Project SDK 设置里，Go 版本要统一（建议 ≥1.16，避免
GO111MODULE=auto行为差异） - 不要在 GOPATH 模式项目里留
go.work文件，它会强制激活 workspace 模式，干扰 GOPATH 解析 - 老项目若用了
vendor/，Modules 模式下默认忽略它；但 GOPATH 模式下又依赖它——这种混合状态会让依赖来源变得不可控 - 最稳的做法：老项目单独开一个 GoLand 窗口，禁用 Modules；新项目另开窗口，启用 Modules
导入路径写错时 GoLand 的典型错误提示
不是所有报错都一样，得看具体信息才能对症处理：
-
can't load package: local import "./utils" in non-local package→ 你在 Modules 模式下写了相对路径，立刻删掉点号，改成完整模块路径 -
could not import utils (can't find import: "utils")→ GoLand 正在 Modules 模式找utils这个远程模块，说明没启用 GOPATH mode，也没配对的go.mod -
Unresolved reference 'NewClient'→ 包导入成功，但函数首字母小写（newClient），Go 不导出，GoLand 无法跳转，和路径无关 -
Import path doesn't match module path→go.mod里写的是github.com/x/y，但代码里 import 了x/y，必须统一
路径问题从来不是“换个写法就行”，而是模块声明、目录结构、GoLand 模式三者必须咬合。漏掉任意一环，GoLand 就只能猜，猜错了就标红。
