go模块中import "./path"会出问题，因其违反“导入路径=模块路径”原则，导致依赖解析失败、ci行为不一致及ide跳转失效；合规写法是统一使用go.mod中声明的完整模块路径。
为什么 import "./some/path" 在 Go 模块中会出问题
Go 模块（go.mod）的设计前提就是「导入路径 = 模块路径」，而相对路径（如 ./internal/utils）不满足这个约定。它会让 go build 误判模块根目录，导致依赖解析失败、go list 报错，甚至在 CI 中因工作目录不同而行为不一致。
常见错误现象：go: inconsistent definition of package xxx、cannot find module providing package ./xxx、本地能跑但 go run . 在子目录下失败。
- 相对路径只在
go get未启用模块模式（即GO111MODULE=off）时被容忍，但该模式早已弃用 - 即使当前项目没发布，也应使用真实模块路径（如
example.com/myapp/internal/utils），而非靠./绕过 - IDE（如 VS Code + gopls）会基于模块路径做符号跳转，相对路径直接让跳转失效
如何把 ./cmd 这类本地导入改成合规写法
核心原则：模块路径必须全局唯一、可解析、与代码仓库地址对齐。不是“怎么让它编译过去”，而是“怎么让模块系统能正确定位它”。
假设你的项目托管在 github.com/user/project，且 go.mod 第一行是 module github.com/user/project：
立即学习“go语言免费学习笔记（深入）”；
-
import "./cmd/server"→ 改为import "github.com/user/project/cmd/server" - 所有子包（
internal/、pkg/、cmd/）都按此规则，路径前缀统一为模块名 - 如果模块路径尚未注册（比如还在本地开发），只要
go.mod写对了，go build就能识别——不需要go get或网络拉取
注意：go mod tidy 不会帮你改导入路径，它只管依赖声明；路径修正必须手动或借助 gofmt -r / gomodifytags 等工具批量处理。
replace 能否用于“临时”指向本地相对路径
可以，但仅限调试，且必须配合绝对路径或 Git 仓库 URL，不能用 ./。
错误写法：replace example.com/lib => ./local-fork（go 命令会报 invalid replace directive）
正确做法（两种）：
- 用绝对路径：
replace example.com/lib => /home/user/local-fork（仅限单机调试，不可提交） - 用本地 Git 仓库：
replace example.com/lib => ../local-fork（前提是../local-fork是个含go.mod的 Git 仓库，且有 commit）
关键点：replace 的右侧必须是「可识别的模块根目录」，不是任意文件夹。相对路径（../）只在它指向一个合法 Git 仓库时才被接受，且该仓库的 module 声明必须与 replace 左侧一致。
CI/CD 和多模块协作中最容易忽略的一点
很多人以为只要本地 go build 成功就万事大吉，但 CI 流水线通常从空目录 git clone 开始，没有“当前项目上下文”。这时任何依赖相对路径的导入都会立刻失败。
更隐蔽的问题是：当项目拆分成多个 go.mod（例如 api/ 和 cli/ 各自为模块），它们之间的导入必须走完整模块路径，且版本需显式管理。此时若某个子模块仍用 ./ 导入同仓库其他部分，go mod vendor 或 go install 会静默忽略那些路径，导致运行时报 package not found。
真正安全的做法只有一个：每个 import 语句开头，都应该是你 go.mod 文件里 module 行声明的那个字符串，不多也不少。
