go 官方工具链要求每个目录对应一个独立包，因此无法在单个 `main` 包下跨子目录（如 `models/`）存放源文件；若坚持同包，需放弃 `go build` 等标准命令，改用底层编译器直接构建——但该方式缺乏文档支持、不可维护，不推荐。
在 Go 中，包（package）与文件系统目录严格一一对应。这意味着：
- 所有属于同一包（例如 package main）的 .go 文件，必须位于同一目录下；
- 子目录（如 models/）会被 Go 工具链自动视为独立包，即使其声明 package main，也会因与父目录包名冲突而编译失败（./models/foo.go:1:1: package main already declared）。
✅ 正确做法：遵循 Go 的惯用结构，按功能拆分包
src/myProject/
├── main.go # package main
├── models/ # package models
│ ├── foo.go # package models
│ └── bar.go # package models
└── cmd/ # （可选）显式分离入口
└── myapp/
└── main.go # package main —— 更清晰的入口管理models/foo.go 示例：
package models
type Foo struct {
ID int
Name string
}main.go 中导入使用：
package main
import (
"fmt"
"myProject/models" // 模块路径需匹配 GOPATH 或 go.mod module name
)
func main() {
f := models.Foo{ID: 1, Name: "test"}
fmt.Println(f)
}⚠️ 注意事项：
- 不要试图“欺骗”编译器：通过 -I、-L 或手动调用 go tool compile + go tool link 绕过目录约束，会导致构建不可重现、测试失效（go test 不识别跨目录同包）、IDE 支持丢失、模块依赖混乱；
- 启用 Go Modules：在项目根目录运行 go mod init myProject，确保导入路径准确，避免 import "models" 这类相对路径错误；
- main 包应极简：仅负责初始化、依赖注入和启动逻辑；业务模型、工具函数等务必放入独立包，提升可测试性与复用性。
总结：Go 的目录即包设计不是限制，而是对代码边界与职责分离的强制约定。接受它，用好它——结构清晰、工具友好、团队协作顺畅，才是真正的工程效率。
