包名与目录名应保持一致，这是go社区的工程实践共识，关乎可读性、工具链支持和协作效率；例外仅限main包和历史遗留场景。
包名与目录名保持一致，不是语法强制要求，而是Go社区长期形成的工程实践共识——它直接关系到代码可读性、工具链支持和团队协作效率。
避免导入路径与使用方式脱节
Go的导入路径是基于模块根（go.mod 中定义）加目录路径组成的，而调用时用的是包名。如果目录叫 auth，但包声明为 authentication，就会出现：
- 导入写 import "myproject/auth"
- 实际调用却要写 authentication.Login()
这种不一致会增加认知负担，尤其对新成员或代码审查者。保持同名后，auth.Login() 一目了然。
工具链默认按目录推断包名
go fmt、go vet、gopls 等官方工具，以及 VS Code、GoLand 等编辑器，在解析、跳转、补全时，都默认假设包名 = 目录名。若手动打破这一约定：
- 自动补全可能失效
- 重构操作（如重命名包）容易出错
- 静态分析工具可能误报“未使用包”或“包冲突”
多人协作与项目演进更可控
一个中大型项目常涉及多个子包，比如 internal/db、internal/cache、internal/metrics。当所有目录与包名统一为小写单字词时：
- 新人能快速建立“路径即包名”的直觉
- CI/CD 脚本、文档生成工具、依赖图谱工具更容易准确识别结构
- 未来拆分模块或提取为独立库时，导入路径天然兼容（如从 myapp/internal/db 拆成 github.com/myorg/db）
例外情况极少，且有明确边界
Go 允许包名与目录名不同，但现实中几乎只在两类场景下被动接受：
- main 包：目录可以叫 cmd/api-server，但包名必须是 main（因为可执行入口强制）
- 第三方 fork 或历史遗留：比如目录叫 third_party（含下划线），包内仍可声明 package thirdparty，但这是妥协，不是推荐
基本上就这些。不复杂但容易忽略——保持目录、包名、导入路径三者一致，是 Go 项目最值得坚持的底层习惯之一。
