go import路径必须是基于模块路径的绝对路径，如“example.com/myapp/config”，不支持“./utils”等相对路径；模块路径可自定义，需全项目统一，vendor和go.work不改变import写法本质。
Go import 路径必须是绝对路径，相对路径会直接报错
Go 的 import 语句不支持类似 "./utils" 或 "../models" 这样的相对路径写法。编译器看到这类路径会立刻报 import "./utils": invalid relative path。这不是环境配置问题，而是 Go 语言设计强制要求——所有导入路径必须以模块路径（module path）为根的绝对路径。
常见错误现象：在 VS Code 里右键“Go: Add Import”，结果自动补出 "./config"，一保存就红标报错；或者从其他语言转过来，下意识写 import "src/handler"，同样失败。
- 正确做法是：先确认当前项目已初始化模块（
go mod init example.com/myapp），然后所有import都基于该模块路径展开，比如"example.com/myapp/config" - 如果只是想复用本地包但不想发布，模块路径可以是任意合法域名（甚至
local/myproject），只要全项目统一即可 - 不要试图用
GO111MODULE=off回退到 GOPATH 模式来绕过——那只会让路径逻辑更混乱，且 Go 1.20+ 已默认启用 module 模式
vendor 目录不影响 import 路径写法，只影响依赖来源
启用 go mod vendor 后，依赖代码被复制进 vendor/ 目录，但你的 import 语句完全不用改。它依然写 "golang.org/x/net/http2"，而不是 "vendor/golang.org/x/net/http2"。Go 编译器会自动优先从 vendor/ 加载，前提是 go build -mod=vendor 或环境变量 GOFLAGS="-mod=vendor"。
容易踩的坑：有人手动把第三方包拷进 vendor/ 后，又去改 import 路径指向 vendor/xxx，结果编译失败——因为 Go 不识别这种前缀，vendor 是构建时的“覆盖层”，不是命名空间。
立即学习“go语言免费学习笔记（深入）”；
基于ThinkPhp6+ swoole4+uniapp 开发的一套CRMEB新零售多商户商城系统。如果不会搭建请到 查看搭建说明系统环境推荐 使用 宝塔配置环境centos PHP7.3 mysql5.6新增功能： 01·新增支持销售虚拟产品自动发货 02.支持销售链接与卡密可导入导出 03.自定义后台路径对后台进行保护 04.新增支持商家缴纳保证金功能 05·违法或侵权商品一键举报功能 06·仲
-
go list -f '{{.Dir}}' "golang.org/x/net/http2"可查当前实际加载路径（可能是vendor/下，也可能是$GOPATH/pkg/mod/） - CI 环境若用
-mod=vendor，请确保vendor/已提交 Git，否则构建会因找不到依赖而中断
同一模块内子包 import 写法：用模块路径 + 子目录，不是文件系统路径
假设模块名是 gitlab.example.com/team/app，你有个文件在 internal/auth/jwt.go，另一个在 cmd/server/main.go，那么后者要导入 jwt 包，写的是 "gitlab.example.com/team/app/internal/auth"，而不是 "../internal/auth" 或 "internal/auth"。
为什么这样？因为 Go 的 import 路径本质是“包标识符”，不是文件路径。它需要全局唯一、可解析、可版本化。省略模块前缀（如只写 "internal/auth"）会导致编译器无法定位——它不知道这是哪个模块的 internal/auth。
- IDE（如 GoLand）自动生成 import 时通常能填对模块前缀，但 VS Code 的某些插件可能漏掉，需手动检查
- 重构包位置（如从
pkg/db移到internal/db）时，只需改文件物理位置，import语句不变，只要模块路径没变 -
internal/和private/这类目录名只影响可见性（外部模块不可导入），不改变 import 路径写法
go.work 多模块工作区下 import 路径仍以各模块自身路径为准
当你用 go work init 建立多模块工作区（比如同时开发 app 和 shared 两个模块），app 想导入 shared 里的包，仍然要写 shared 模块定义的路径，比如 "github.com/me/shared/utils"，而不是 "../shared/utils" 或 "shared/utils"。
关键点在于：go.work 只解决“多个模块如何一起 build/test”，不改变每个模块内部的 import 解析规则。它只是让 Go 命令知道：当遇到 "github.com/me/shared/utils" 时，别去拉远程 tag，而是去本地 ../shared 找。
- 如果
shared模块的go.mod里写的是module github.com/me/shared，那 import 就必须严格匹配这个字符串 - 工作区里模块路径冲突（比如两个模块都声明
module example.com/lib）会导致 import 解析失败，错误信息通常是ambiguous import: found ... in multiple modules -
go work use ./shared后，记得go mod tidy在app模块下运行，否则依赖不会写入其go.mod
最常被忽略的一点：import 路径和文件系统路径解耦后，go list 和 go build 报的“cannot find package”错误，往往不是路径写错了，而是模块未正确初始化、go.mod 缺失、或工作区未激活。先跑 go list -m all 看模块是否被识别，比反复改 import 字符串更有效。
