必须一致——Go虽未强制要求，但工具链、标准库和IDE均依赖包名与目录名一致；不一致会导致导入混乱、go list失败、IDE跳转错乱及测试遗漏；仅main包例外，其目录名可不同但包声明必须为main。
不必须，但强烈建议一致——Go语言规范没有强制要求，但所有主流工具链、标准库、社区项目和 IDE 都默认依赖这种一致性；不一致会直接导致导入路径混乱、go list 识别失败、IDE 跳转错乱，甚至单元测试无法发现包。
为什么 Go 工具链「默认信任」目录名 = 包名
Go 的模块系统（go.mod）通过导入路径定位包，而导入路径是相对于模块根的目录路径。例如模块路径为 github.com/user/app，目录 auth/ 下的包被期望声明为 package auth，这样其他代码才能用 import "github.com/user/app/auth" 并自然调用 auth.Login()。
- 如果目录是
auth/，但包名写成package authentication，导入后调用变成authentication.Login()，语义冗余且破坏直觉 -
go build和go test仍能运行，但go list ./...会把该包归类为authentication，与目录结构脱节，CI/CD 中依赖分析或覆盖率工具容易漏报 - VS Code 或 GoLand 默认按目录结构索引包，包名不一致时「Go to Definition」可能跳转到错误文件或失效
哪些情况看似“可以不同”，其实代价很高
有人尝试用不同包名来“消歧义”，比如两个 utils/ 目录分别命名为 utils_v1 和 utils_v2，或者用 userutils 避免和第三方 utils 冲突——这反而暴露了设计问题。
- 目录名本身已是命名空间：应通过重构目录层级解决冲突，例如
internal/utils/和pkg/validation/utils/，而非靠包名“打补丁” - 包名含下划线（如
user_utils）或驼峰（如userAuth）会导致go fmt报警，且不符合标准库惯例（fmt、net/http、encoding/json全是单小写词） - 命令行工具生成的代码（如
protoc-gen-go）严格按目录推导包名，手动改package声明会导致生成失败或 import 循环
实操建议：三步对齐包名与目录名
新建或重构包时，用这三步避免后续踩坑：
立即学习“go语言免费学习笔记（深入）”；
- 先创建目录，名字用单数、小写、无符号（如
cache，不是caches或cache_layer） - 在该目录下所有
.go文件顶部统一写package cache（注意：不能有的写cache，有的写cacheutil） - 检查导入路径是否与模块根匹配：运行
go list -f '{{.ImportPath}}' ./cache，输出应为类似github.com/user/app/cache，而非github.com/user/app/cache/cacheutil
最常被忽略的一点：main 包是个例外——它必须叫 main，但目录名可以是 cmd/myapp 或 internal/main；此时导入路径仍是 github.com/user/app/cmd/myapp，但包声明固定为 package main。这种“名实分离”是 Go 明确允许的唯一常见例外，其余所有非 main 包，都该老老实实让包名和目录名站在一起。
