Go语言文件命名规范：复合词应统一使用蛇形命名（snake

Go语言文件命名规范：复合词应统一使用蛇形命名（snake_case）

go语言中，复合词文件名应采用全小写+下划线分隔的蛇形命名法（如weighted_union_find.go），这是标准库及主流开源项目的事实标准，兼顾可读性、跨平台兼容性与工具链稳定性。

go语言中，复合词文件名应采用全小写+下划线分隔的蛇形命名法（如weighted_union_find.go），这是标准库及主流开源项目的事实标准，兼顾可读性、跨平台兼容性与工具链稳定性。

在Go项目开发中，文件命名远不止风格选择——它直接影响构建可靠性、IDE智能补全、CI/CD稳定性以及跨操作系统兼容性。针对复合词（如“Weighted Union Find”）的文件命名，社区已形成高度一致的实践共识：

✅ 推荐：weighted_union_find.go（蛇形命名，全小写+下划线）
这是Go标准库的绝对主流用法，例如：

atomic_test.go、chunked_test.go（net/http/internal/）
http_client.go、json_parser.go（虽包名应为json，但历史文件名仍体现此惯例）
go list、go build等工具链对下划线命名零兼容问题，Windows/macOS/Linux全平台安全。

❌ 不推荐：weightedUnionFind.go（驼峰式）
Go官方明确指出：驼峰命名仅适用于标识符（变量、函数、结构体），不适用于文件名。文件使用驼峰会导致：

与标准库惯例割裂，降低团队协作一致性；
某些旧版构建脚本或CI配置可能隐式依赖小写路径；
IDE在文件标签页中难以快速区分“文件名”与“内部导出函数名”（如func WeightedUnionFind()）。

❌ 不推荐：weightedunionfind.go（纯连写小写）
虽技术上合法，但显著损害可读性：“weightedunionfind”需人工断词，增加认知负荷；在大型项目中数十个类似文件并列时（如unionfind, weightedunionfind, pathcompressedunionfind），扫描效率大幅下降。

? 进阶建议：语义优先，适度缩写
若算法名称过长，可在保持无歧义前提下合理缩写：

// 推荐（清晰且简洁）
weighted_union_find.go   // 完整语义，首选
wuf.go                   // 仅当团队文档明确定义WUF为通用缩写，且上下文高度受限（如内部算法竞赛库）

⚠️ 注意：wuf.go 类缩写不可用于公共模块或跨团队项目——包名仍须为wuf，但易与第三方包冲突，且违背“包名需自解释”原则。

? 配套规范必须同步遵守：

文件内包声明必须与目录名严格一致且全小写：

Go语言（Golang）1.26.0
Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载
```
// weighted_union_find.go 内必须写：
package weighted_union_find  // ❌ 错误！包名不能含下划线
// 正确做法：将文件放入名为 weightedunionfind/ 的目录，包声明为：
package weightedunionfind
```

导出函数/类型使用大驼峰：

// weightedunionfind/weightedunionfind.go
package weightedunionfind

// ✅ 正确：导出函数首字母大写，符合Go可见性规则
func NewWeightedUnionFind(size int) *UnionFind { ... }

// ✅ 结构体同样大驼峰
type UnionFind struct { ... }

? 总结：weighted_union_find.go 是当前（2026年）Go生态最安全、最专业、最可持续的选择。它不是妥协，而是深思熟虑后的工程权衡——以最小的命名成本，换取最大的工具链友好性、团队可维护性与长期演进弹性。