Go包导入路径必须以go.mod中module声明为前缀，如github.com/yourname/myapp/utils；internal目录受编译器强制校验，仅父级或同级代码可导入；标准库用"fmt"等，第三方及自发布模块需完整路径如"github.com/yourname/myapp/v2/utils"。
Go 包导入路径不是文件系统路径，也不是相对路径，而是逻辑模块路径；写错会导致 import "xxx" 编译失败、go get 拉不到代码、他人无法复现构建，甚至发布后无法被下游正确引用。
怎么写本地项目的 import 路径？
必须以 go.mod 中的 module 声明为前缀，不能用 ./utils 或 myapp/utils 这类“看起来对”的路径。
- 项目根目录运行
go mod init github.com/yourname/myapp，则所有子包导入路径都得是github.com/yourname/myapp/xxx -
utils/目录下写package utils，那它的导入路径就是github.com/yourname/myapp/utils，不是myapp/utils，更不是./utils - 如果误写成
import "myapp/utils"，会报错：cannot find module providing package myapp/utils
internal 目录怎么用才真正私有？
internal/ 不是命名约定，而是 Go 编译器强制校验的访问控制机制：只有其父级或同级目录下的代码能导入它，外部项目哪怕路径拼对了也会被拒绝。
- 结构示例：
myapp/ ├── go.mod # module github.com/yourname/myapp ├── main.go # 可 import "github.com/yourname/myapp/internal/db" └── internal/ └── db/ └── conn.go # package db -
main.go中写import "github.com/yourname/myapp/internal/db"✅ 正常 - 另一个项目写同样这行 import ❌ 编译失败，提示：
use of internal package not allowed - 注意：
internal必须是模块路径中的一级目录，比如github.com/yourname/myapp/internal/db合法，但github.com/yourname/myapp/core/internal/db就不生效
第三方包和标准库路径有什么区别？
三者路径规则完全不同，混用会直接编译失败：
- 标准库：直接写包名，如
"fmt"、"net/http"—— Go 安装时自带，无域名 - 第三方包：必须带完整远程路径，如
"github.com/go-sql-driver/mysql"、"golang.org/x/text/unicode/norm"——go build时自动从对应 Git 地址拉取 - 你自己的模块（已发布）：也走第三方规则，比如别人引用你，就得写
"github.com/yourname/myapp/utils"，哪怕你本地没推送到 GitHub，只要go.mod里声明了这个路径，就按此解析 - 常见错误：
import "mysql"或import "text"—— 都会报cannot find package
v2+ 版本包路径怎么改才不破坏兼容性？
语义化版本 v2 起，必须把版本号显式加进模块路径末尾，否则 Go 认为还是 v0/v1，go get 无法区分。
- v1 模块：
module github.com/yourname/myapp - v2 模块：
module github.com/yourname/myapp/v2（注意末尾/v2） - 用户升级时需同步改导入路径：
import "github.com/yourname/myapp/v2/utils" - 不能只改
go.mod里的版本号（如require github.com/yourname/myapp v2.0.0），而不改模块路径本身 —— 这样go build仍会去找v1路径，导致找不到包 - 别名迁移可临时缓解，但长期仍要更新路径，例如：
import ( v1 "github.com/yourname/myapp" v2 "github.com/yourname/myapp/v2" )
最易被忽略的一点：路径一旦被外部项目依赖，就几乎无法安全修改。与其后期补救，不如初始化时就定好 module github.com/xxx/yyy —— 即使项目还在本地，也要按将来会开源的路径来设计。
