go语言强制禁止import相对路径，所有import必须使用以go.mod中module声明开头的绝对模块路径，如github.com/user/project/pkg/db，而非./pkg/db或../internal/log。
Go 语言不支持 import 相对路径，任何类似 import "./utils" 或 import "../internal/log" 的写法都会直接报错，这不是环境配置问题，而是语言设计强制限制。
为什么 import "./xxx" 会报错：import path contains '..'
Go 编译器在解析 import 语句时，会严格校验路径字符串。只要出现 .. 或以 . 开头，就立刻拒绝并报错：import "../utils": import path contains '..'。这不是 GOPATH 模式残留或 IDE 缓存导致的假象，是 go tool 链（go build、go list）在词法层就拦截的硬性规则。
常见翻车点：
- 误以为和 Python/JS 一样能用
./表示同级目录 —— Go 没有这种机制 - 在 VS Code 里看到“可跳转”，但
go build失败 —— IDE 可能基于文件系统推测，而编译器只认模块路径 - 把
go.mod放错位置（比如放在子目录），导致模块上下文断裂，进一步放大路径误判
本地包必须用绝对模块路径导入
所谓“绝对”，是指与 go.mod 中声明的 module 名拼接后的完整路径。例如：
module github.com/user/project
那么你项目中 pkg/db 目录对应的合法 import 路径只能是：github.com/user/project/pkg/db，而不是 ./pkg/db 或 project/pkg/db。
实操要点：
- 确保
main.go和go.mod在同一目录（或其子目录），否则模块根无法识别 - 所有本地子包的 import 语句，都必须以
go.mod中的module值开头 - 如果项目尚未初始化模块，先运行
go mod init github.com/user/project，再调整 import - 改完 import 后，务必运行
go mod tidy，让工具自动修正依赖图
想引用同仓库下另一个模块？用 replace 指令
当你要在项目 A 中引用本地路径上的模块 B（比如 B 尚未发布，或正在协同开发），不能靠相对路径，而要用 go.mod 的 replace：
module github.com/user/project-a<br>go 1.21<br><br>require (<br> github.com/user/project-b v0.0.0<br>)<br><br>replace github.com/user/project-b => ../project-b
注意：
-
replace右侧的../project-b是文件系统相对路径（从当前go.mod所在目录算起），但它只用于构建时重定向，不影响 import 语句本身 - 你的代码里仍要写
import "github.com/user/project-b/utils"，不能写import "../project-b/utils" -
replace不会改变模块名，只是告诉go工具：“当遇到这个 module 名时，请去这个本地路径找” - 上线前需移除
replace并发布正式版本，否则 CI 构建会失败
internal 包不是“相对路径解法”，而是访问控制边界
有人试图把 internal 当作“相对路径替代方案”，这是典型误解。github.com/user/project/internal/db 能被 github.com/user/project/cmd/api 导入，靠的不是路径近，而是前缀匹配规则：后者路径必须以 github.com/user/project/ 开头，且 internal 必须出现在模块路径的固定位置。
容易踩的坑：
- 在
cmd/下单独go mod init，会让cmd变成独立模块，彻底失去对internal的访问权 - 把
internal放在vendor/或third_party/下 —— Go 不认，直接不可见 - 测试需要访问 internal？别从外部
import，用同包测试（xxx_test.go与xxx.go同目录）或//go:build ignore辅助文件
真正难处理的从来不是语法，而是模块边界的划分时机——等 go build 报错才去调 go list -m 看当前模块上下文，往往已绕进多层嵌套里出不来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
