Go 构建工具的文件忽略规则
在go语言的开发实践中，我们可能会遇到一个看似反直觉的现象：某些以特殊字符开头的go源文件（.go文件）在执行go build命令时，其内容并未被编译到最终的可执行文件或库中。这主要是因为go的构建工具链，特别是其核心的go/build包，对文件命名有一套特定的处理规则。
具体而言，任何以下划线（_）或点（.）字符开头的.go、.c、.h、.s文件，都会被go build命令自动忽略，不会作为包的一部分进行编译。这意味着这些文件中定义的任何函数、变量或类型都将无法在导入该包时被外部访问。
设计考量与官方解释
这种文件忽略机制并非偶然，而是Go语言设计者为了提高开发效率和避免不必要的编译而有意为之。其主要目的是：
- 忽略临时文件或编辑器生成文件： 许多文本编辑器在保存文件时会生成以.或_开头的临时文件（例如.myfile.go.swp或_myfile.go），或者在某些场景下，开发者可能希望创建一些不属于最终构建的草稿文件。Go工具链通过忽略这些文件，避免了将它们误编译到项目中，从而保持项目结构的清晰和构建过程的健壮性。
- 遵循标准库约定： 这一行为在Go标准库的go/build包中得到了明确的定义和实现。go/build包负责解析Go包的结构和依赖关系，其内部逻辑明确指出会排除这些特定命名的文件。
go/build包的官方文档对此有清晰的说明：
在包含包的目录中，.go, .c, .h, 和 .s 文件被视为包的一部分，除了：包文档中的 .go 文件以 _ 或 . 开头的文件（很可能是编辑器临时文件）构建约束不满足上下文要求的文件
示例与影响分析
让我们通过一个具体的例子来理解这种规则的影响。假设我们有一个Go模块 mypkg，其文件结构如下：
立即学习“go语言免费学习笔记（深入）”；
mypkg/ _func.go a.go b.go
其中：
-
_func.go 文件内容可能如下：
// mypkg/_func.go package mypkg func HiddenFunction() string { return "This function is hidden." } -
a.go 文件内容可能如下：
// mypkg/a.go package mypkg func PublicFunctionA() string { return "This is function A." }
当其他包尝试导入 mypkg 并使用其中的函数时，例如：
package main
import (
"fmt"
"mypkg" // 假设 mypkg 在 GOPATH/src 或模块路径下
)
func main() {
fmt.Println(mypkg.PublicFunctionA())
// fmt.Println(mypkg.HiddenFunction()) // 编译错误！
}尝试调用 mypkg.HiddenFunction() 将会导致编译错误，因为 _func.go 文件在构建时被忽略，HiddenFunction 并未被编译到 mypkg 包中，因此对外部是不可见的。而 mypkg.PublicFunctionA() 则可以正常调用。
注意事项与最佳实践
- 避免在生产代码中使用 _ 或 . 前缀： 除非你有明确的意图希望文件被忽略（例如，用于本地测试或临时脚本，且不希望其被构建），否则请避免在Go源文件、C/C++源文件或汇编文件的文件名前使用下划线或点。
- 区分特殊用途文件： Go语言中确实存在一些以_开头但具有特殊含义的文件命名约定，例如：
-
替代方案： 如果你需要创建一些不希望被编译但又想保留在项目目录中的文件，可以考虑以下方法：
- 将其放置在非Go包的子目录中（例如，docs/、scripts/）。
- 使用 .txt、.md 等非编译性扩展名。
- 如果确实是Go代码，但希望在特定条件下才编译，请使用Go的构建约束（Build Constraints）。
总结
Go语言中以_或.开头的源文件会被go build命令明确忽略，这是go/build包设计的一部分，旨在排除临时文件、编辑器生成文件或开发者不希望参与编译的辅助文件。理解这一规则对于避免潜在的编译问题和维护清晰的Go项目结构至关重要。在日常开发中，应遵循Go的命名约定，避免使用这些前缀来命名需要被编译的Go源文件。
