Go 要求同一目录下所有 .go 文件必须声明相同的 package 名称；若混用 package main 和 package hello，编译器将报错“found multiple packages”，这是强制性约束，不可绕过。
go 要求同一目录下所有 `.go` 文件必须声明相同的 `package` 名称；若混用 `package main` 和 `package hello`，编译器将报错“found multiple packages”，这是强制性约束，不可绕过。
在 Go 语言中，目录即包（directory = package） 是一项核心设计原则。你遇到的错误：
can't load package: package hello: found packages main (main.go) and hello (utilities.go) in .../hello
正是 Go 构建系统对这一规则的严格校验结果——它明确拒绝在同一文件夹内存在多个不同包名的源文件。
✅ 正确做法：统一包名，按职责拆分逻辑
既然 main.go 需要作为程序入口（必须为 package main），而 utilities.go 又仅服务于本项目且不希望暴露为独立模块，最直接、合规的方案是：
-
将
utilities.go也声明为package main
并确保它不定义func main()（避免multiple main functions错误），仅提供函数、类型或变量供main.go直接调用。
// utilities.go
package main
import "fmt"
// Exported utility function (capitalized name)
func SayHello(name string) {
fmt.Printf("Hello, %s!\n", name)
}// main.go
package main
func main() {
SayHello("World") // ✅ 可直接调用，同包内可见
}✅ 运行方式（任选其一）：
go run main.go utilities.go # 显式列出 go run *.go # 类 Unix 系统推荐（shell 展开） go run . # ✅ 最佳实践（Go 1.11+，全平台兼容，自动识别全部 main 包文件）
⚠️ 为什么不能混用包名？底层机制解析
你的 ADD 2 和 ADD 3 实验非常有价值，揭示了 Go 的关键机制：
-
import "pkg1"指定的是模块路径（module path + directory），而非源码中的package声明； -
package pkg2在pkg1/file1.go中，等效于隐式import pkg2 "pkg1"—— 但这仅在导入方显式使用别名时才合法； - 而在同一目录内混用包名，会破坏 Go 的构建模型：编译器需将整个目录视为一个逻辑单元进行类型检查、符号解析和依赖分析。若包名不一致，就无法确定作用域边界，故直接拒绝加载。
? 补充验证：运行
go list -f '{{.Name}}' .在hello/目录下，将报错；而统一为package main后，输出main—— 这正是 Go 工具链识别“当前目录所属包”的唯一依据。
? 进阶建议：随项目演进采用标准工程结构
当功能复杂度上升（如需复用工具、支持多命令、引入测试或依赖管理），应主动升级为社区标准布局：
myapp/ ├── go.mod # go mod init myapp ├── cmd/ │ └── myapp/ # 可执行入口 │ └── main.go # package main; import "myapp/internal/util" ├── internal/ │ └── util/ # 私有逻辑包 │ ├── utilities.go # package util │ └── helpers.go └── ...
此时：
-
cmd/myapp/main.go仅负责初始化和调度； -
internal/util包可被其他内部子包安全复用，但对外不可导入（internal/语义保护）； - 所有包名与目录名保持一致，语义清晰，工具链（
go build,go test, IDE 支持）完全兼容。
? 总结：三条铁律
-
一目录一包：同一文件夹下所有
.go文件必须声明相同package名（_test.go除外）； -
main 包可拆分：
package main允许多文件共存，只需确保仅一个含func main()； -
构建命令要匹配意图：
- 快速调试 →
go run .（推荐）； - 构建发布 →
go build -o bin/app .； - 模块化演进 →
cmd/+internal/+go.mod。
- 快速调试 →
遵循这些规范，既能享受多文件带来的代码可维护性，又能完全契合 Go 工具链的设计哲学。
