理解Go语言的标识符可见性：导出与非导出
go语言在处理标识符（变量、函数、方法、类型等）的可见性时，采用了一种与c语言更为相似的机制，即“导出（exported）”与“非导出（unexported）”。这与许多面向对象语言中常见的“公共（public）”和“私有（private）”概念有所不同。在go中，一个标识符如果首字母大写，则表示它是导出的，可以在包外部被访问；如果首字母小写，则表示它是非导出的，只能在当前包内部使用。这种机制的核心在于“包”的边界。
单一包独立应用的标识符实践
对于一个不作为库、不期望被其他Go程序导入的独立应用程序（例如一个命令行工具），其核心逻辑通常包含在一个main包中。在这种情况下，由于该包不会被其他任何外部包导入，因此将包内的所有标识符都设为非导出（即首字母小写）通常是更符合Go语言习惯的做法。
理由如下：
- 明确意图： 应用程序的内部实现细节不应暴露给外部。将标识符设为非导出，清晰地表明这些是内部组件，无需对外提供接口。
- 减少意外依赖： 即使未来某个时刻，该应用程序的代码片段被意外地导入到其他包中，由于大部分标识符都是非导出的，外部包也无法直接访问其内部实现，从而避免了不必要的耦合和潜在的副作用。
- 简化思维： 无需纠结哪些是“公共”的，哪些是“私有”的，因为整个包的职责就是运行应用程序，而非提供可复用的API。
组织复杂应用的子包策略
尽管上述建议倾向于将单一包应用的所有标识符设为非导出，但在实际开发中，当应用程序的规模逐渐增大时，为了更好地管理代码、实现关注点分离，将一个大型应用程序拆分为多个内部子包是一个非常有效的策略。这些子包仍然属于主应用程序项目的一部分，其目的并非作为独立的库对外发布，而是为了在项目内部进行模块化。
示例项目结构： 考虑以下项目结构，其中projectname是主应用程序包，而subcomponent1和subcomponent2是其内部的子包：
projectgopath/src/projectname
projectname/subcomponent1
projectname/subcomponent2在这种结构下：
立即学习“go语言免费学习笔记（深入）”；
- 主包 (projectname) 仍然是应用程序的入口，它可能会导入subcomponent1和subcomponent2。
- 子包 (subcomponent1, subcomponent2) 内部的标识符，如果仅供该子包内部使用，则应设为非导出（首字母小写）。
- 子包间通信： 如果projectname包需要调用subcomponent1中的某个函数或访问其某个类型，那么subcomponent1中相应的标识符就必须是导出的（首字母大写）。同样，如果subcomponent1需要与subcomponent2通信，也需要通过导出的标识符。
这种结构的好处包括：
- 关注点分离： 每个子包负责特定的功能模块，降低了单个包的复杂性。
- 代码组织： 逻辑相关的代码被聚合在一起，提高了可读性和可维护性。
- 清晰的边界： 导出的标识符明确了子包对外提供的接口，而非导出的标识符则封装了内部实现细节。
- Go工具链友好： go build和go install命令能够很好地处理这种内部子包结构，编译和安装过程与单一包应用无异。
总结与最佳实践
对于Go语言的独立应用程序开发：
- 默认倾向于非导出： 如果你的应用程序是一个单一的main包，且不打算被其他程序导入，那么将所有标识符设为非导出（首字母小写）是符合Go习惯的。
- 利用子包进行内部组织： 当应用程序变得复杂时，不要犹豫将其拆分为内部子包。这样做可以更好地实现关注点分离和代码组织。
- 子包间的导出： 在子包之间需要通信时，通过导出（首字母大写）必要的标识符来提供接口，但仍要尽量限制导出的范围，只暴露最少量的必要功能。
- 外部接口始终非导出： 无论内部如何拆分，整个应用程序项目对外（即对其他Go项目）应保持非导出状态，除非它被设计成一个可复用的库。
通过采纳“导出”与“非导出”的思维模式，并灵活运用子包结构，开发者可以构建出结构清晰、易于维护且符合Go语言惯例的独立应用程序。
