go 要求 `go run` 显式指定所有参与编译的 `.go` 文件（如 `go run main.go otherfile.go` 或 `go run *.go`），仅传入 `main.go` 时不会自动包含同目录下其他 `package main` 文件，因此导致未定义标识符错误。
在 Go 项目中，将 main 包逻辑拆分到多个文件是完全合法且推荐的做法（例如分离命令逻辑、配置初始化、工具函数等），但需注意 Go 构建工具链对文件加载的显式性要求。
✅ 正确做法：显式指定全部源文件
假设你的项目结构如下：
$GOPATH/src/testapp/ ├── main.go └── otherfile.go
其中：
main.go
package main
import "fmt"
func main() {
fmt.Println(SomeFunc()) // 调用 otherfile.go 中定义的函数
}otherfile.go
package main
func SomeFunc() string {
return "a thing"
}此时，不能只运行：
go run main.go # ❌ 报错：undefined: SomeFunc
而应使用以下任一方式：
-
显式列出所有文件：
go run main.go otherfile.go
-
通配符一次性包含当前目录所有 .go 文件（推荐用于小型 CLI 项目）：
go run *.go
-
或使用 go build + 执行（更接近生产流程）：
go build -o testapp . ./testapp # 输出：a thing
⚠️ 注意事项
- go run 默认不递归扫描目录，也不会自动合并同包的其他文件——这是设计使然，确保构建行为可预测、无隐式依赖。
- 若使用 go mod init testapp 初始化模块（推荐现代 Go 工作流），仍需遵守上述规则；模块模式下 go run . 也有效（表示“运行当前模块的主包所有文件”）：
go run . # ✅ Go 1.11+ 支持，等价于 go run *.go（但更安全，会自动排除测试文件等）
- 避免在 main 包中跨文件循环引用（如 main.go 调 otherfile.go，后者又调回 main.go 中未导出函数），虽语法允许，但会降低可维护性。
✅ 最佳实践建议
- 小型命令行工具：用 go run . 快速验证。
- 多文件协作开发：配合 go fmt、go vet 和 IDE（如 GoLand 或 VS Code + Go 插件）保障一致性。
- 不要依赖 go run main.go 单文件运行多文件逻辑——这不是 bug，而是 Go 明确的设计约束。
通过理解 go run 的文件粒度控制机制，你就能灵活组织 main 包代码，兼顾清晰性与可维护性。
