打开一个陌生的 Go 项目，第一件事往往是追踪函数调用：入口在哪里，这个函数在哪个文件定义，为什么另一个文件能直接调用它？如果把文件、包和模块当成同一个概念，导入路径和可见性规则就很容易越看越乱。
这篇文章用一个只输出 Hello, Go 的小程序展开。先让两个源码文件运行起来，再增加一个文件，观察跨文件调用、包名变化和编译错误。读完后，你应该能够沿着一条导入语句，在项目中找到它对应的代码。
先准备已安装的 Go 环境。这个小程序使用 Go Modules 组织代码，没有第三方依赖。
先运行一个两文件程序
建立下面的目录。go.mod 是项目配置，不是 Go 源码文件，所以这里的两个源码文件指 main.go 和 greeting.go。
hello-go/
├── go.mod
├── main.go
└── greeting/
└── greeting.go
go.mod 的内容：
module example.com/hello-go
go 1.22
module 后面是本模块的路径，它也是模块内各个包的导入路径前缀。go 行记录模块的 Go 版本要求。此处使用 example.com 作为练习标识，不需要先创建同名网站或仓库。
greeting/greeting.go 的内容：
package greeting
func Hello(name string) string {
return "Hello, " + name
}
暂时只需要读懂这一句：Hello 接收名为 name 的字符串，返回一个字符串。Go 把参数类型写在参数名后面，return 表示返回结果。
main.go 的内容：
package main
import (
"example.com/hello-go/greeting"
"fmt"
)
func main() {
fmt.Println(greeting.Hello("Go"))
}
package main 与 func main() 组成程序入口。fmt.Println 负责输出，greeting.Hello("Go") 调用另一个包中的函数。
进入 hello-go/ 目录，执行：
go run .
你会看到：
Hello, Go
先保留这个能够运行的版本。后面的概念都可以回到它上面验证。
从这个程序分清三个层次
| 层次 | 这个例子里是什么 | 主要负责什么 |
|---|---|---|
| 文件 | main.go、greeting.go | 将源码分开放置 |
| 包 package | 根目录的 main 包、子目录的 greeting 包 | 一起编译一组源码，并形成名称与访问边界 |
| 模块 module | go.mod 定义的 example.com/hello-go | 管理相关包的依赖与版本 |
在这套工具规则下，一个目录组织一个普通包；子目录中的包不会自动并入父目录的包。hello-go/ 和 hello-go/greeting/ 是两个目录，因此这里有两个包。它们属于同一个 go.mod 定义的模块。
包和模块解决的问题不同。调用函数时，代码需要导入某个包；添加外部依赖时，Go 工具需要确定它属于哪个模块、使用哪个版本。Go 官方代码组织说明
完整导入路径如何找到本地代码
回到这条导入：
import "example.com/hello-go/greeting"
它可以拆成两部分：
example.com/hello-go + greeting
当前模块的路径 包相对于模块根目录的位置
构建这个模块时，Go 已经从 go.mod 知道当前模块路径，所以能够把这条导入对应到本地的 greeting/ 目录。这里写完整路径，不意味着需要到网上下载本项目。
这套写法让包拥有统一的导入身份。包位于当前模块时，工具找到本地源码；包来自外部模块时，再按依赖规则寻找相应源码。导入字符串负责说明“需要哪个包”，具体位置由 Go 工具解析。Go 模块参考
同一文件中的 import "fmt" 则来自 Go 标准库，不需要在 go.mod 中声明依赖。不能把不带域名的名字都理解为当前目录下的文件简称。
源码导入与命令行目录也要分开看：
go list ./...
go build ./...
第一个命令列出当前目录树中的包，输出包含 example.com/hello-go 和 example.com/hello-go/greeting；第二个命令构建这些包。./... 是命令行的目录选择方式。在 Go Modules 项目里，不能因此将源码导入改成 import "./greeting"。
增加一个文件后为什么不用互相导入
现在将前缀提取出来。新增 greeting/prefix.go：
package greeting
func prefix() string {
return "Hello, "
}
把 greeting/greeting.go 改为：
package greeting
func Hello(name string) string {
return prefix() + name
}
再次执行 go run .，输出仍然是 Hello, Go。greeting.go 没有导入 prefix.go，却能直接调用 prefix()，因为两个文件都属于 greeting 包。
Go 根据目录收集参与本次构建的源码，再一起编译这个包。普通顶层声明在包内共享，文件名不会为这些声明另建一层名字空间。彼此可见是语言规则，不需要等到源码被压成某个物理“包文件”后才发生。
这也意味着，小写函数名不表示“仅本文件可见”。prefix 供本包使用；同包中的其他文件也能调用它。
大小写控制的是跨包访问
根目录中的 main.go 使用 greeting.Hello，因为 Hello 是导出名称。Go 通过名称的首字母控制导出：大写开头的包级名称可以供其他包使用，小写开头的名称不能直接从其他包访问。
将 main.go 中的调用改成：
fmt.Println(greeting.prefix())
构建会失败，因为 prefix 没有导出。将调用恢复为 greeting.Hello("Go") 后，又能运行。
判断可见性时，先看调用者是否属于同一个包，再看名称是否导出；不要仅根据它是否在同一个仓库或文件中判断。
三种编译错误揭示了包的约束
下面每个实验都从上面的可运行版本开始，观察结果后恢复，再做下一项。
| 修改 | 构建结果 | 说明 |
|---|---|---|
删除 greeting.go 的 package greeting | 语法错误 | 每个参与构建的源码文件必须有包声明 |
仅将 prefix.go 改为 package other | 同目录包名冲突 | 普通源码不能通过写不同包名，在一个目录里任意组成两个包 |
在 prefix.go 再定义一个普通 Hello 函数 | 名称重复 | 不同文件不会隔离同包的顶层名称 |
重复定义普通函数时，诊断中会出现类似 Hello redeclared in this block 的信息。把两个同名函数分到不同文件，不能解决这种冲突。不同函数各自的局部变量则可以同名，因为它们不在同一个局部范围内。
导入还有一个单独的范围规则：main.go 导入了 fmt，不代表 prefix.go 也可以直接使用它。如果你在 prefix.go 中调用 fmt.Sprint，就要由这个文件自己导入 fmt。函数等普通顶层声明属于包级范围，导入名称属于文件级范围。Go 规范中的声明与作用域
包名与目录名不一致时会发生什么
继续使用同一个程序，不换到另一套例子。将 greeting/ 目录下两个文件的第一行一起改为：
package salutation
然后把 main.go 中的调用改成：
fmt.Println(salutation.Hello("Go"))
导入路径保持不变：
import "example.com/hello-go/greeting"
程序仍然能够运行。目录仍然叫 greeting，所以导入路径没有变；包声明变成了 salutation，所以调用方默认使用 salutation.Hello。
这说明目录位置、导入路径和代码中的包名存在联系，但不是同一个东西。实际编写普通库时，让包名与目录末段一致通常更省心。这个实验用于理解规则，不是鼓励故意使用不一致的名称。Go 规范中的包与导入
完成后，可以恢复 package greeting 与 greeting.Hello，与随文示例保持一致。
包级共享带来的维护成本
共享名称让同一个职责的实现容易拆分到多个文件。移动 prefix 的定义不需要修改调用方式，代码也不用维护文件之间的导入关系。
代价是，文件内看不到所有包内依赖。一个包越大，辅助函数越可能被不同职责的代码复用，小写成员也无法形成文件级隔离。因此，将大型程序继续堆进一个包会增加维护难度。
不同包拥有各自的名称空间，可以通过导出入口协作。划分包时，应寻找稳定的职责，而不是为了避免一次重名就把每个函数拆成一个包。后者会增加需要理解的接口和依赖。
阅读陌生项目时，可以沿着 调用位置 → 所属包 → 导入路径 → go.mod 追踪代码，再检查跨包调用是否只依赖必要的导出成员。此时，文件数量与代码边界就不再是同一个问题。
