Go导出函数必须首字母为Unicode大写字母，否则其他包无法调用；小写函数仅限本包使用，且导出函数需配Godoc注释，结构体字段小写会导致JSON序列化丢失。

导出函数必须首字母大写，否则其他包无法调用 —— 这不是约定，是 Go 编译器的硬性规则。

为什么小写函数在其他包里调用不到

Go 的可见性（exported/unexported）完全由标识符首字母大小写决定，不依赖关键字（如 public 或 private）。编译器在解析时直接检查：首字母是 Unicode 大写字母（如 A–Z、α 等），才视为可导出；否则仅限本包内使用。

常见错误现象：

• 在 utils 包里写了 validateEmail，main 包 import "utils" 后调用 utils.validateEmail(...) 报错：cannot refer to unexported name utils.validateEmail
• 函数能编译通过，但 IDE 提示 “undefined”，或 go build 时提示 “not declared by package utils”

首字母大写的实际写法与常见陷阱

不是“只要大写就行”，而是要符合 Go 的 Unicode 字母判定和命名习惯。以下要点直接影响能否被正确导出和使用：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

立即学习“go语言免费学习笔记（深入）”；

• ValidateEmail ✅ 正确：首字母 V 是 ASCII 大写，其他包可调用 utils.ValidateEmail
• _validateEmail ❌ 错误：下划线开头，属于未导出标识符，且 _ 是空标识符，不能作名字
• validateEmail ❌ 错误：首字母小写，即使加了 Godoc 注释也无法被外部访问
• Validateemail ✅ 语法合法但不推荐：首字母大写，但 email 全小写破坏了驼峰一致性，易被误读为 ValidateEmail 的拼写错误
• 含非 ASCII 字符如 ÜberValidate：取决于 Unicode 类别，但实际项目中应避免，标准库和工具链对非 ASCII 导出名支持不稳定

导出函数必须配 Godoc 注释

首字母大写只是导出的前提，不是终点。Go 工具链（如 go doc、VS Code 插件、godoc 服务）只对带注释的导出函数生成文档。没有注释的导出函数，等于“不可见的公开接口”。

• 注释必须紧贴函数声明上方，且以函数名为第一词：// ValidateEmail checks if the string is a valid email format.
• 缺少注释会导致 go lint 报 exported function ValidateEmail should have comment or be unexported
• 注释里需说明参数含义、返回值语义、可能的 error 类型，例如：// Returns true if email is syntactically valid, or an error if input is empty.

跨包调用时大小写不一致引发的 JSON 或反射问题

首字母大小写不仅影响函数可见性，还会间接导致运行时行为差异：

• 如果导出函数返回一个结构体，而该结构体字段是小写（如 type User struct { name string }），即使函数本身导出成功，JSON 序列化时 name 字段会丢失（encoding/json 只序列化导出字段）
• 用 reflect.Value.Call 动态调用函数时，传入的函数名字符串必须严格匹配大小写，"validateEmail" 和 "ValidateEmail" 是两个完全不同的符号
• 测试文件（xxx_test.go）若在不同包中测试导出函数，必须确保导入路径正确，且函数名拼写零误差 —— 少一个大写就编译失败

真正容易被忽略的是：大小写规则在函数名、结构体名、字段名、常量名上统一生效，但它们的“导出后果”不同。函数名小写 = 根本调不到；字段小写 = 调得到但序列化不到。别只盯着函数名改大写，顺手检查它返回或操作的数据类型是否也导出了关键字段。