Go语言禁止import相对路径，必须改用绝对模块路径：先执行go mod init example.com/legacy，再将import "./xxx"改为import "example.com/legacy/xxx"，并确保子目录package声明正确。
GoLand 里打开老项目，import "./xxx" 报错怎么办
GoLand 默认启用 gopls 和模块模式，而早期 Go 项目（尤其是 Go 1.10 及之前）常依赖 ./utils 这类相对导入写法。这类代码在现代 Go 环境下会直接报 can't load package: local import "./utils" in non-local package —— 不是 IDE bug，是 Go 工具链主动拦截。
解决思路不是“绕过限制”，而是让项目快速适配模块机制：
- 在项目根目录（含
main.go的地方）运行go mod init example.com/legacy（模块名可任意，但必须非空、不含点号以外的特殊字符） - 把所有
import "./utils"改成import "example.com/legacy/utils"（路径 = 模块名 + 目录名） - 确认
utils/下每个.go文件开头是package utils，且没有func main() - 删掉旧的
GOPATH相关配置：GoLand → Settings → Go → GOPATH 留空，关闭 “Use GOPATH that contains checked out sources”
不改源码时临时让 GoLand 识别老结构
如果不能动代码（比如只读维护、客户交付包），可强制 GoLand 以 GOPATH 模式加载，但需满足三个硬性条件：
- 项目必须放在
$GOPATH/src/下某子路径，例如$GOPATH/src/mycompany/oldapp - GoLand 打开的根目录必须是
$GOPATH/src/mycompany/oldapp（不是它的父目录） - 手动设置环境变量：
GO111MODULE=off（GoLand → Settings → Go → Environment → 添加）
注意：GO111MODULE=off 仅对当前项目生效，且 go build、go test 命令行仍需同步设置该变量，否则 CLI 和 IDE 行为不一致。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
replace 无法解决老项目本地包问题？原因在这
replace 是用来替换远程模块为本地路径的，它不适用于“本项目内子目录”这种场景。你看到的 replace github.com/x/y => ./local 写法，目标必须是另一个独立模块（即含自己 go.mod 的目录）。对老项目中 ./model 这种无模块的同项目子目录，replace 完全无效。
常见误操作：
- 在
go.mod里写replace ./model => ./model—— 语法错误，replace左侧必须是合法模块路径（含域名或 vendor 形式） - 执行
go mod tidy后发现没变化 —— 因为require行里根本没声明这个路径，replace失去作用对象 - 以为加了
replace就能保留import "./model"—— 不可能，导入语句本身已被 Go 编译器拒绝，根本到不了replace解析阶段
最易被忽略的细节：package main 不能被 import
老项目常把工具函数和逻辑全塞进 main.go，然后试图在其他文件里 import "." 或 import "./common"。这会失败，因为：
-
package main是可执行入口，Go 明确禁止被其他包 import - 即使你把
main.go改成package common，若目录下还有另一个main.go（同级），Go 会报multiple packages错误 - 真正可行的解法是：把复用逻辑拆出新目录（如
lib/），声明package lib，再用import "example.com/legacy/lib"引入
别指望 IDE 自动修复 package 声明 —— GoLand 不会重写 package 行，它只校验一致性。改完 import 路径后，必须手动检查并统一所有 .go 文件的 package 名称。
