在大型go项目中，应避免同名包分散在不同目录导致导入混乱；推荐采用“功能域+角色”命名法（如userctrl、usermodel），或按业务边界划分包，确保每个包名全局唯一且语义清晰。
在大型go项目中，应避免同名包分散在不同目录导致导入混乱；推荐采用“功能域+角色”命名法（如userctrl、usermodel），或按业务边界划分包，确保每个包名全局唯一且语义清晰。
当项目规模增长至数万行代码时，单纯依赖目录层级（如 controllers/user/ 和 models/user/）并统一使用 package user 会引发严重问题：Go 要求同一模块内包名全局唯一，即使物理路径不同，重复的 package user 会导致编译错误（duplicate package "user"）。这并非设计缺陷，而是 Go 包模型的核心约束——包名是导入和作用域的标识符，而非路径别名。
✅ 正确做法是：包名应反映其职责与抽象层级，而非目录路径。以下是经过生产验证的三种推荐方案：
-
语义化短名 + 角色后缀（推荐初/中级项目）
controllers/ ├── userctrl/ # package userctrl │ ├── routes.go │ └── profile.go └── orderctrl/ # package orderctrl models/ ├── usermodel/ # package usermodel └── ordermodel/ # package ordermodel
导入时清晰无歧义：
import ( "myapp/controllers/userctrl" "myapp/models/usermodel" ) -
按业务域聚合（推荐中大型项目）
彻底打破 MVC 目录隔离，以领域为中心组织：user/ # package user ├── handler.go # HTTP handlers ├── service.go # business logic ├── model.go # domain structs & methods └── repository.go # data access order/ # package order
优势：高内聚、低耦合，符合 DDD 思想；
user.Handler、user.Service等调用自然流畅。 -
接口抽象 + 显式导入别名（仅限特殊场景）
若必须保留controllers/user/和models/user/结构，则禁止使用package user，改用描述性名称：// controllers/user/routes.go package userroutes // not "user" // models/user/profile.go package userprofile // not "user"
导入时可简化：
import ( userroutes "myapp/controllers/user" userprofile "myapp/models/user" )
⚠️ 注意事项：
- ❌ 绝对避免
controllers_user或user_controllers类似下划线命名（违反 Go 命名惯例）； - ❌ 不要依赖
"controllers/user"这样的路径作为包名——Go 不支持路径式包名； - ✅ 所有包名须为小写、简短、可读（如
httpapi,postgres,cache），长度建议 ≤12 字符； - ✅ 使用
go list ./...验证全项目包名唯一性。
最后，请务必精读 Rakyll 的 Go 包风格指南 —— 它强调：“A package’s name should be short, concise, and evocative. It should reflect the package’s purpose, not its location.”（包名应简短、凝练、富有表现力，体现其目的，而非位置）。结构服务于可维护性，而非目录惯性。
