go run . 是最简单可靠的多文件编译方式；它自动包含当前目录下所有非_test.go、非隐藏的.go文件，但要求同目录所有文件包名一致，否则报found multiple packages。
直接说结论：go run . 是最简单可靠的多文件编译方式；“找不到包”90%不是路径问题，而是目录结构或包名不合规导致 Go 工具链压根没把目标文件纳入编译范围。
go run main.go 为什么总报 undefined？
因为 go run main.go 只编译你写的那个文件，其他同目录的 utils.go、server.go 全被忽略——Go 不会自动扫描目录。哪怕它们都声明 package main，只要没被显式列出或用通配符包含，就等于不存在。
- 错误现象：
./main.go:5: undefined: NewServer，而NewServer明明定义在server.go里 - 临时解法（仅调试）：
go run main.go server.go utils.go或go run *.go（Linux/macOS） - 推荐解法（全平台、稳定、免维护）：
go run .—— 它自动识别当前目录下所有非_test.go的.go文件，且跳过以.或_开头的文件 - 注意：
go run .要求所有文件包名一致，否则报found multiple packages
同一目录下多个 .go 文件必须同包名
Go 强制规定：一个目录 = 一个包。如果你在 main.go 写 package main，又在同目录的 api.go 里写 package api，go run . 会直接失败，报错 found packages main and api。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：所有同目录文件都声明
package main（仅限入口逻辑简单的小项目） - 但
main.go和api.go都得是package main，且都不能定义func main()（否则报multiple main functions） - 如果想拆分职责，必须换目录：把
api.go移到internal/api/，改包名为package api，再在main.go里import "myproject/internal/api" - 别试图用子目录塞进同一个包——
models/foo.go和main.go即使都写package main，也会被当作两个包，编译报错
长期项目必须用标准目录结构
把所有代码堆在根目录写 package main 是技术债起点。真正出问题的不是编译命令，而是结构松散导致后期无法维护、复用和测试。
-
cmd/下按二进制名建子目录：cmd/api/main.go→ 构建出./api，避免multiple main packages -
internal/放私有业务逻辑（如internal/handler、internal/repo），外部模块 import 会直接被编译器拒绝 -
pkg/放可复用的通用能力（如pkg/ulid、pkg/httputil），命名要具体，别叫pkg/util -
go.mod必须在项目根目录，且模块路径（如github.com/user/project）要和所有import语句完全匹配，大小写、斜杠都不能错
最容易被忽略的一点：构建标签（//go:build linux）和 _test.go 文件会让“看起来同包”的文件实际不参与编译——你以为它在，其实编译器根本没看到。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
