Go编译器将同一包下所有.go文件视为整体一次性编译，无需指定主文件；go run必须显式包含全部同包源文件（如go run a.go b.go）或使用go run .，否则会报“undefined”错误。
Go 编译器不按文件名顺序编译，也不需要你指定“主文件”；它把同一包下所有 .go 文件当作一个整体一次性处理。 你不会遇到“file2.go 找不到 file1.go 定义的函数”这种问题——只要它们同属一个包、都在当前编译范围内，就能互相访问。
go run 时必须显式包含所有同包源文件
当你用 go run 启动一个含多个文件的 main 包时，Go 不会自动扫描目录加载其余文件：
-
go run main.go→ 只编译main.go，其他同目录的utils.go、handler.go被完全忽略 -
go run *.go→ 在某些 shell（如 zsh）中可能因通配符展开顺序错漏文件，或意外包含_test.go -
go run .→ 推荐方式：编译当前目录下所有非测试的.go文件，且自动排除以.或_开头的文件
错误示例：./main.go:5: undefined: NewServer，往往就是只传了 main.go，而 NewServer 定义在 server.go 中。
build 标签影响多文件包的实际参与编译范围
同一个包下的文件不一定全被编译——//go:build 或旧式 // +build 注释会过滤文件：
-
config_linux.go开头有//go:build linux→ 在 macOS 上编译时被跳过 -
debug.go包含//go:build debug→ 默认不参与编译，需加-tags debug - 文件名含
_test.go→ 永远不被go build或go run .加入主包编译（仅用于go test）
这意味着：看似“同包”的文件，实际编译时可能被拆成不同组合。比如 log.go 和 log_windows.go 共享 package log，但 Windows 和 Linux 构建出的 log.a 内容并不相同。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
import 路径指向的是编译产物，不是源文件路径
当你写 import "myproject/utils"，Go 并不读取 $GOPATH/src/myproject/utils/ 下的源码来编译——它优先查找已编译好的 .a 文件：
- 若存在
$GOPATH/pkg/$GOOS_$GOARCH/myproject/utils.a且时间戳新于源码，则直接链接该归档 - 否则才去
$GOPATH/src/myproject/utils/收集所有匹配构建标签的.go文件，合并编译成新的.a - 模块模式下（
go.mod存在），路径解析和缓存位置变为$GOCACHE下的哈希目录，逻辑不变
所以修改了一个 utils/ 下的文件后，依赖它的程序不一定会立刻生效——得确保对应 .a 被重新生成。手动触发可用 go install myproject/utils 或删掉 $GOCACHE 对应条目。
最容易被忽略的一点是：包内跨文件调用从不涉及 import 语句，也无需考虑定义顺序；但一旦文件被构建标签排除，或没被 go run 显式包含，那个“消失”的定义就真的不存在了——编译器不会报“文件未找到”，只会报“undefined identifier”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
