本文永久链接 – https://tonybai.com/2025/02/16/some-changes-in-go-1-24

北京时间2025年2月12日，恰逢中国传统元宵佳节，远在美国的Go团队正式发布了Go 1.24的第一个版本Go 1.24.0。这也是Go团队在更换Tech Leader为Austin Clements后发布的首个大版本。

按照惯例，每次Go大版本发布时，我都会撰写一篇“Go 1.x中值得关注的几个变化”的文章。自2014年的Go 1.4版本起，这一系列文章已经持续了11年。

不过，随着从Go 1.17版本开始引入的“Go 1.x新特性前瞻”系列以及针对特定技术特性的专题文章，“Go 1.x中值得关注的几个变化”系列文章的形式也在不断演变。原先的“Go 1.x中值得关注的几个变化”可以理解为被目前的“Go 1.x新特性前瞻” + “特定技术特性文章” + “Go 1.x中值得关注的几个变化”所替代。

不过，随着从Go 1.17版本开始引入的“Go 1.x新特性前瞻”系列以及针对特定技术特性的专题文章，“Go 1.x中值得关注的几个变化”系列的形式也在不断演变。原先的“Go 1.x中值得关注的几个变化”已逐渐被目前的“Go 1.x新特性前瞻” + “特定技术特性文章” + “Go 1.x中值得关注的几个变化(新版)”所替代。希望各位读者能够理解这种变化，“Go 1.x中值得关注的几个变化”系列依然会延续，但文章中将不再进行细致的分析，因为这些内容已经在之前的前瞻和专题文章中讨论过了。

好了，言归正传，我们来说说Go 1.24！

1. 语言变化

正如Go一贯所做的，新版Go 1.24.0继续遵循Go1的兼容性规范。使用Go 1.24.0，你可以顺利编译和运行你用Go 1.11编写的代码。相信许多Gopher正是因为这一点而喜欢上Go，就像下面这位Gopher在Go 1.24发布后所表现出的惊喜一样：

不过，正如Go一贯所做的那样，在语法特性方面，Go显得十分“吝啬”。在Go 1.18大方地引入了泛型之后，Go团队又恢复了这种“吝啬”的风格。在Go 1.24的发布说明中，那短短的一行字充分展现了这一特点：

我们看到，Go 1.24仅仅是将Go 1.23版本中的实验特性“带有类型参数的类型别名”转正了，成为了默认特性。当然你仍然可以GOEXPERIMENT=noaliastypeparams显式关闭它。关于这个特性的具体内容，我们多次说过了，大家可以到《Go 1.24新特性前瞻：语法、编译器与运行时》温习一下它的具体内容。

不过这种“吝啬”也是很多Gopher所期望的，当年Go语言之父Rob Pike在“Simplicity is Complicated”演讲中提到的如下权威观点，影响了诸多Gopher，当然也包括我：

因此，在正在如火如荼的“spec: reduce error handling boilerplate using ?”的讨论中，就当前的情况来看，我也倾向于保持现状。

2. 编译器与运行时

在2024年中旬，Fasthttp的作者、VictoriaMetrics的联合创始人Aliaksandr Valialkin曾因Go加入自定义函数迭代的特性而发文抱怨“Go正在朝着错误的方向演进”。不过他也提到，如果Go团队专注于提升Go的性能，而不是在与社区争论一些“华而不实”的语法糖，可能会赢得更多开发者的青睐：

尽管Go 1.24尚未添加对SIMD的官方支持，但引入的优化显然不会让Aliaksandr Valialkin失望。首当其冲的就是对map底层实现的优化——使用更为高效的Swiss Table。关于Swiss Table及Go 1.24重写map的思路，可以参考我的《Go map使用Swiss Table重新实现，性能最高提升近50%》一文。根据文中的实测结果，新版基于Swiss Table的map在多数测试项中表现出显著的性能提升，有些甚至接近50%！

当然，基于Swiss Table的map实现仍在不断完善，其实现者Michael Pratt将持续进行打磨和优化：

参与Go Swiss Table重写方案讨论，并提供参考实现之一的CockroachDB CTO Peter Mattis，也在X.com上分享了新map设计和实现的诞生过程与优势，大家可以阅读以加深理解。

此外，Go 1.24还优化了runtime内部的锁实现，新实现在高竞争情况下取得了显著的可扩展性提升，而不是像Go 1.24之前的实现那样随线程数增加而急剧下降。基准测试表明，在GOMAXPROCS=20时，性能提升达3倍。

更多编译器和运行时的变化，可以参考《Go 1.24新特性前瞻：语法、编译器与运行时》。

Go 1.24版本在编译器和运行时方面的优化投入和勇于改变，正是Go社区所期望的。相信后续版本在这方面的持续投入不会让Aliaksandr Valialkin失望。

3. 工具链

Go团队在Go工具链上的投入和结果一直被Go社区认可和赞扬！《Go 1.24新特性前瞻：工具链和标准库》一文中有对Go 1.24工具链变化的详细介绍，但在这里我还是要再次提及其中的三个变化。

go.mod增加tool指示符，支持对tool的依赖管理

借用《Go工具链版本已不由你定：go和toolchain指令详解》中的那幅图：

Go的目标显然是要实现对Go应用所依赖“全要素”进行版本管理”，涵盖Go版本、工具链版本、第三方包版本以及依赖工具版本的管理。而Go 1.24在go.mod中增加tool指示符就是要实现对依赖工具的版本进行管理。增加tool指示符后，你可以像管理第三方包版本那样，使用go get -tool对依赖的tool的版本进行管理，go install tool对tool进行安装，并支持一个tool同时存在多个版本在本地，这是由于通过go.mod管理的依赖的tool会被像module那样缓存在本地构建缓存中(go build cache)。

btw，再说说go 1.24对toolchain依赖管理和选择的改善。即便看了《Go工具链版本已不由你定：go和toolchain指令详解》一文，很多Gopher还是可能因为gotoolchain决策的复杂性和参与要素的众多而感到困惑，Go 1.24增加了GODEBUG=toolchaintrace=1可以输出做出决策的过程日志，告诉你Go为何会选择某个特定的toolchain版本。

go vet的增强

在Go 1.24中，go vet的功能有了较大变化，新增或增强了如下一些分析器(analyzer)：

• 新增测试分析器

可以检测test、fuzz test、基准测试和example test中的常见错误，避免因命名、签名错误或引用不存在的标识符而导致测试无法运行。

• printf分析器增强

新增对fmt.Printf(s)的检查，如果这类调用中格式字符串并非常量且没有传入其他参数，则提醒用户使用fmt.Print。

• buildtag分析器增强

新增对无效Go主版本构建约束的检测，避免错误引用次版本号。例如，如果你使用//go:build go1.23.1，该分析器会提醒你应该使用//go:build go1.23。

• copylock分析器增强

增强对经典三段式for循环中包含sync.Locker的变量复制的不安全操作的诊断，防止锁的复制带来的潜在问题。这也是Go 1.23修正loopvar语义后避免Go用户误用的一个防卫手段。

新增GOCACHEPROG

另一个大家可能忽视的值得关注的改变是新增了GOCACHEPROG环境变量。

Go语言的cmd/go工具已经具备了强大的缓存支持，但其缓存机制仅限于基于文件系统的缓存。这种缓存方式在某些场景下效率不高，尤其是在CI（持续集成）环境中，用户通常需要将GOCACHE目录打包和解压缩，这往往比CI操作本身还要慢。此外，用户可能希望利用位于网络上的共享缓存(比如S3)或公司内部的P2P缓存协议来提高缓存效率，但这些功能并不适合直接集成到cmd/go工具中。

为了解决上述问题，Brad Fitzpatrick提出了一个新的环境变量GOCACHEPROG，类似于现有的GOCACHE变量。通过设置GOCACHEPROG，用户可以指定一个外部程序，该程序将作为子进程运行，并通过标准输入/输出来与cmd/go工具进行通信。cmd/go工具将通过这个接口与外部缓存程序交互，外部程序可以根据需要实现任意的缓存机制和策略。其大致结构如下：

显然一旦可以在云上存储build cache，也能缓解一下Go用户抱怨本地缓存过大的问题。当然从实际情况来看(我的本地环境)，go build cache还不是最大的：

$go env|grep CACHE
GOCACHE='/Users/tonybai/Library/Caches/go-build'
GOCACHEPROG=''
GOMODCACHE='/Users/tonybai/Go/pkg/mod'
$cd /Users/tonybai/Library/Caches/go-build
$du -sh
155M    .

$cd /Users/tonybai/Go/pkg/mod
$du -sh
7.0G

我们看到在我本地的环境中，go build cache和go module cache的size相比，简直是不值得一提，所以说如果后续要有个GOMODCACHEPROG就更好了，我也十分希望能将go module cache搬移到云端（比如S3）中，甚至可以让组织内的Gopher共享这些go module cache（当然要区分不同arch和os）。

更多关于工具链的变化，可以参考《Go 1.24新特性前瞻：工具链和标准库》。

4. 标准库

Go标准库向来是变化的大户，这里我显然不会列出所有变化，甚至一些值得关注的变化，比如：json包增加对omitzero选项的支持、新增weak包和weak指针等，也都在新特性前瞻或技术专题性文章中有过详细说明。

这里要说的是Go对fips 140-3合规性的支持，因为这个最终版本与当初新特性前瞻时有所变化。

基于最新的Go fips 140-3文档，我们可以得到关于fips 140-3使用方法的说明，这里简要梳理如下：

• Go 1.24及更高版本开始，Go二进制文件可以原生运行在FIPS 140-3合规模式下，不必依赖注入boringssl等第三方C++包。
• Go新增了的一个特殊的Go加密模块 (Go Cryptographic Module)，其下有一组新增的标准库包（位于crypto/internal/fips140/…下），实现了 FIPS 140-3批准的算法。这个cryptographic module的版本当前为v1.0.0，目前正在接受CMVP认证实验室的测试。

Go引入了GOFIPS140环境变量，用于go build、go install和go test命令，以选择要链接到可执行程序中的Go加密模块版本。该环境变量有三类可选值：

• off (默认): 使用标准库中的crypto/internal/fips140/…包。
• latest: 类似off，但默认启用FIPS 140-3模式。
• v1.0.0: 使用Go加密模块 v1.0.0 版本（在Go 1.24中首次发布，并在2025年初冻结），默认启用FIPS 140-3模式。

在运行时，可以通过GODEBUG=fips140=xxx来控制上述编译到Go中的Go cryptographic module是否运行在FIPS 140-3模式下，默认是off。

当使用GODEBUG=fips140=on时，Go运行时将会启用Go cryptographic module的FIPS 140-3模式。启用后，Go加密模块会执行以下操作：

• 完整性自检: 在init阶段，会验证模块对象文件的校验和，确保代码未被篡改。
• 已知答案自检: 根据FIPS 140-3指南，在init阶段或首次使用时，对算法进行已知答案测试。
• 密钥一致性测试: 对生成的密钥进行配对一致性测试 (这可能导致某些密钥类型生成速度减慢，特别是临时密钥)。
• crypto/rand.Reader改进: 使用NIST SP 800-90A DRBG，并从平台CSPRNG获取随机字节混合到输出中。
• crypto/tls限制: 仅协商符合NIST SP 800-52r2 的协议版本、密码套件、签名算法和密钥交换机制。
• crypto/rsa.SignPSS限制: 使用PSSSaltLengthAuto时，盐的长度会被限制为哈希的长度。

当使用GODEBUG=fips140=only时，不符合FIPS140-3的加密算法会返回错误或者panic。但是此模式仅为尽力而为，不保证符合所有的FIPS 140-3要求。

不过大家要知道的是：在Go 1.24版本中，GODEBUG=fips140=on和only在OpenBSD、Wasm、AIX和32位Windows平台上暂不受支持。

另外要想要检测FIPS 140-3模式是否已经激活，可以调用crypto/fips140.Enabled函数。

之前，一些场合用户使用BoringCrypto模块来实现某些FIPS 140-3算法的机制仍然可用，但已不被官方支持，并计划在未来版本中移除。另外要知道Go+BoringCrypto与原生FIPS 140-3模式并不兼容。这也是Microsoft Go依旧宣称将保留自己维护的符合fips140-3的Go版本的原因。

5. 其他

最后重点说说WebAssembly port。

Go从Go 1.11版本开始通过js/wasm增加了对编译到Wasm的支持。Go 1.21版本又增加了对WASI的支持(GOOS=wasip1)，Go 1.24版本中，Go对Wasm的支持又有了新的特性。在Go 1.24发布没多久，Cherry Mui便在官博发表了名为“Extensible Wasm Applications with Go”的介绍Go 1.24中WebAssembly新特性的文章，文章介绍了Go 1.24对Wasm的支持程度以及一些限制。这里也参考了这篇文章，简单梳理一下Cherry给出的内容要点。

Go 1.24引入了新的编译器指示符go:wasmexport，允许将Go函数导出，以便从Wasm模块外部（通常是从运行Wasm运行时的主机应用程序）调用。该指示符指示编译器将带注释的函数作为Wasm导出提供，在生成的Wasm二进制文件中可用，比如：

//go:wasmexport add
func add(a, b int32) int32 { return a + b }

这样，Wasm模块将具有一个名为add的导出函数，可以从主机调用。

这是如何实现的呢？Cherry告诉我们这是通过构建一种名为WASI Reactor的Wasm模块来实现的。WASI Reactor是一种持续运行的WebAssembly模块，可以多次调用以响应事件或请求。与在主函数完成后终止的“命令”模块不同，reactor实例在初始化后保持活动状态，其导出保持可访问状态。

在Go 1.24中，要构建一个WASI reactor需要使用下面命令：

$GOOS=wasip1 GOARCH=wasm go build -buildmode=c-shared -o reactor.wasm

该构建命令指示链接器不生成_start函数（wasm命令模块的入口点），而是生成_initialize函数（执行运行时和包初始化）以及任何导出的函数及其依赖项。_initialize函数必须在任何其他导出函数之前调用。而main函数不会自动调用。

go:wasmexport指示符和reactor构建模式允许通过调用基于Go的Wasm代码来扩展应用程序。这对于采用Wasm作为具有明确定义接口的插件或扩展机制的应用程序特别有价值。通过导出Go函数，应用程序可以利用Go Wasm模块提供功能，而无需重新编译整个应用程序。此外，构建为reactor可确保可以多次调用导出的函数而无需重新初始化，使其适用于长时间运行的应用程序或服务。

次卧，Go 1.24还放宽了对可用于go:wasmimport函数的输入和结果参数类型的限制。例如，可以传递bool、string、指向int32的指针或指向嵌入structs.HostLayout并包含受支持字段类型的结构体的指针，这使得Go Wasm应用程序可以用更自然的方式编写，并消除了不必要的类型转换。

不过，go:wasmexport当前也有局限性，首先，Wasm 是单线程架构，没有并行性。go:wasmexport标识的函数可以生成新的goroutine。但是，如果函数创建了后台goroutine，则当go:wasmexport指示的函数返回时，它将不会继续执行，直到回调到基于Go的Wasm模块。

另外，尽管Go 1.24中放宽了一些类型限制，但对于可与go:wasmimport和go:wasmexport函数一起使用的类型仍然存在限制。比如由于客户端的64位体系结构和主机的32位体系结构之间的不匹配，我们无法传递内存中的指针。例如，go:wasmimport指示的函数不能采用指向包含指针类型字段的结构体的指针。

但不可否认的是go:wasmexport的支持，让Go更稳固了自己成为主流wasm开发语言之一的位置，虽然还有各种不足。近期Docker之父的初创公司Dagger就发博客宣称使用了Go+WebAssembly重写了其Dagger Cloud的前端！

6. 小结

Go 1.24的发布，标志着Go语言在保持其核心理念——简洁与兼容性的同时，进入了一个新的发展阶段。这个版本没有在语法上大刀阔斧，而是将重心放在了底层性能优化、工具链完善和新兴技术布局上，展现出Go团队务实且具有前瞻性的发展策略。同时，Go 1.24也可以看成是一个承上启下的版本。它既巩固了Go语言在性能和工具链方面的优势，又为未来的发展方向做出了积极的布局。Go语言正以稳健的步伐，朝着更高效、更安全、更具适应性的方向迈进。我们可以期待，在未来的版本中，Go将继续在云原生计算、WebAssembly、AI应用等领域发挥更大的作用，为开发者带来更多的惊喜。

借此文章插播一条国内Go社区的news!

近期GoCN社区发文“Farewell Go，Hello AI：是时候说再见了”和所有国内Go开发人员分享了“GoCN社区将正式转型升级为ThinkInAI社区”，全面拥抱AI的决定！这也意味国内最大Go技术社区的退出，最大Go技术大会GopherChina的正式落幕！除了AI是热门赛道这一原因之外，文章也给出了Go技术分享遇到瓶颈的说法：

不过就像文中所说的“这是任何技术发展到成熟阶段的必然现象”，在评论中一些Gopher也提到：一个技术不再被更多讨论是成熟的标志。

这其实与我在《2024年Go语言盘点：排名历史新高，团队新老传承》一文中表达的Go演进趋势不谋而合！Go真的进入了成熟期了!

GoCn不在了，但go在国内的传播和使用依然会继续。请继续关注诸如Gopher Daily、我的公众号以及国内其他诸如像鸟窝老师的blog以及公众号，了解Go的最新动态以及技术理解。

最后感谢AstaXie(谢孟军)对国内Go社区发展所做出的卓越贡献，我也因有幸多次参与GopherChina以及会上分享而感到无比自豪。

Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且，2025年将在星球首发“Go陷阱与缺陷”和“Go原理课”专栏！此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
• Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2025/01/23/the-hidden-details-of-go-exported-identifiers

前不久，在“Go+用户组”微信群里看到有开发者向七牛云老板许式伟反馈七牛云Go SDK中的某些类型没有导出，导致外部包无法使用的问题(如下图)：

七牛开发人员迅速对该问题做出了“更正”，将问题反馈中涉及的类型saveasArgs和saveasReply改为了导出类型，即首字母大写：

不过，这看似寻常的问题反馈与修正却引发了我的一些思考。

我们大胆臆想一下：如果saveasReply类型的开发者是故意将saveasReply类型设置为非导出的呢？看一下“更正”之前的saveasReply代码：

type saveasReply struct {
    Fname       string `json:"fname"`
    PersistenId string `json:"persistentId,omitempty"`
    Bucket      string `json:"bucket"`
    Duration    int    `json:"duration"` // ms
}

有读者可能会问：那为什么还将saveasReply结构体的字段设置为导出字段呢？请注意每个字段后面的结构体标签(struct tag)。这显然是为了进行JSON 编解码，因为目前Go的encoding/json包仅会对导出字段进行编解码处理。

除了这个原因，原开发者可能还希望包的使用者能够访问这些导出字段，而又不想完全暴露该类型。我在此不对这种设计的合理性进行评价，而是想探讨这种做法是否可行。

我们对Go导出标识符的传统理解是：导出标识符（以大写字母开头的标识符）可以在包外被访问和使用，而非导出标识符（以小写字母开头的标识符）只能在定义它们的包内访问。这种机制帮助开发者控制类型和函数的可见性，确保内部实现细节不会被随意访问，从而增强封装性。

但实际上，Go的导出标识符机制是否允许在某些情况下，即使类型本身是非导出的，其导出字段依然可以被包外的代码访问呢？该类型的导出方法呢？这些关于Go导出标识符的细节可能是鲜少人探讨的，在这篇博文中，我们将系统地了解这些机制，希望能为各位小伙伴带来更深入的理解。

1. Go对导出标识符的定义

我们先回顾一下Go语言规范(go spec)对导出标识符的定义：

我们通常使用英文字母来命名标识符，因此可以将上述定义中的第一句理解为：以大写英文字母开头的标识符即为导出标识符。

注：Unicode字符类别Lu（Uppercase Letter）包含所有的大写字母。这一类别不仅包括英文大写字母，还涵盖多种语言的大写字符，例如希腊字母、阿拉伯字母、希伯来字母和西里尔字母等。然而，我非常不建议大家使用非英文大写字母来表示导出标识符，因为这可能会挑战大家的认知习惯。

而第二句后半部分的描述往往被我们忽视或理解不够到位。一个类型的字段名和方法名可以是导出的，但并没有明确要求其关联的类型本身也必须是导出的。

这为我们提供了进一步探索Go导出标识符细节的机会。接下来，我们就用具体示例看看是否可以在包外访问非导出类型的导出字段以及导出方法。

2. 在包外访问非导出类型的导出字段

我们首先定义一个带有导出字段的非导出类型myStruct，并将它放在mypackage里：

// go-exported-identifiers/field/mypackage/mypackage.go

package mypackage

type myStruct struct {
    Field string // 导出的字段
}

// NewMyStruct1是一个导出的函数，返回myStruct的指针
func NewMyStruct1(value string) *myStruct {
    return &myStruct{Field: value}
}

// NewMyStruct1是一个导出的函数，返回myStruct类型变量
func NewMyStruct2(value string) myStruct {
    return myStruct{Field: value}
}

然后我们在包外尝试访问myStruct类型的导出字段：

// go-exported-identifiers/field/main.go

package main

import (
    "demo/mypackage"
    "fmt"
)

func main() {
    // 通过导出的函数获取myStruct的指针
    ms1 := mypackage.NewMyStruct1("Hello1")

    // 尝试访问Field字段
    fmt.Println(ms1.Field) // Hello1

    // 通过导出的函数获取myStruct类型变量
    ms2 := mypackage.NewMyStruct1("Hello2")

    // 尝试访问Field字段
    fmt.Println(ms2.Field) // Hello2
}

在go-exported-identifiers/field目录下编译运行该示例：

$go run main.go
Hello1
Hello2

我们看到，无论是通过myStruct的指针还是实例副本，都可以成功访问其导出变量Field。这个示例的关键就是：我们使用了短变量声明直接通过调用myStruct的两个“构造函数(NewXXX)”得到了其指针(ms1)以及实例副本(ms2)。在这个过程中，我们没有在main包中显式使用mypackage.myStruct这个非导出类型。

采用类似的方案，我们接下来再看看是否可以在包外访问非导出类型的导出方法。

3. 在包外访问非导出类型的导出方法

我们为非导出类型添加两个导出方法M1和M2：

// go-exported-identifiers/method/mypackage/mypackage.go

package mypackage

import "fmt"

type myStruct struct {
    Field string // 导出的字段
}

// NewMyStruct1是一个导出的函数，返回myStruct的指针
func NewMyStruct1(value string) *myStruct {
    return &myStruct{Field: value}
}

// NewMyStruct1是一个导出的函数，返回myStruct类型变量
func NewMyStruct2(value string) myStruct {
    return myStruct{Field: value}
}

func (m *myStruct) M1() {
    fmt.Println("invoke *myStruct's M1")
}

func (m myStruct) M2() {
    fmt.Println("invoke myStruct's M2")
}

然后，试着在外部包中调用M1和M2方法：

// go-exported-identifiers/method/main.go

package main

import (
    "demo/mypackage"
)

func main() {
    // 通过导出的函数获取myStruct的指针
    ms1 := mypackage.NewMyStruct1("Hello1")
    ms1.M1()
    ms1.M2()

    // 通过导出的函数获取myStruct类型变量
    ms2 := mypackage.NewMyStruct2("Hello2")
    ms2.M1()
    ms2.M2()
}

在go-exported-identifiers/method目录下编译运行这个示例：

$go run main.go
invoke *myStruct's M1
invoke myStruct's M2
invoke *myStruct's M1
invoke myStruct's M2

我们看到，无论是通过非导出类型的指针，还是通过非导出类型的变量复本都可以成功调用非导出类型的导出方法。

提及方法，我们会顺带想到接口，非导出类型是否可以实现某个外部包定义的接口呢？我们继续往下看。

4. 非导出类型实现某个外部包的接口

在Go中，如果某个类型T实现了某个接口类型I的方法集合中的所有方法，我们就说T实现了I，T的实例可以赋值给I类型的接口变量。

在下面示例中，我们看看非导出类型是否可以实现某个外部包的接口。

在这个示例中mypackage包中的内容与上面示例一致，主要改动的是main.go，我们来看一下：

// go-exported-identifiers/interface/main.go

package main

import (
    "demo/mypackage"
)

// 定义一个导出的接口
type MyInterface interface {
    M1()
    M2()
}

func main() {
    var mi MyInterface

    // 通过导出的函数获取myStruct的指针
    ms1 := mypackage.NewMyStruct1("Hello1")
    mi = ms1
    mi.M1()
    mi.M2()

    // 通过导出的函数获取myStruct类型变量
    // ms2 := mypackage.NewMyStruct2("Hello2")
    // mi = ms2 // compile error: mypackage.myStruct does not implement MyInterface
    // ms2.M1()
    // ms2.M2()
}

在这个main.go中，我们定义了一个接口MyInterface，它的方法集合中有两个方法M1和M2。根据类型方法集合的判定规则，*myStruct类型实现了MyInterface的所有方法，而myStruct类型则不满足，没有实现M1方法，我们在go-exported-identifiers/interface目录下编译运行这个示例，看看是否与我们预期的一致：

$go run main.go
invoke *myStruct's M1
invoke myStruct's M2

如果我们去掉上面代码中对ms2的注释，那么将得到Compiler error: mypackage.myStruct does not implement MyInterface。

注：关于一个类型的方法集合的判定规则，可以参考我的极客时间《Go语言第一课》专栏的第25讲。

接下来，我们再来考虑一个场景，即非导出类型用作嵌入字段的情况，我们要看看该非导出类型的导出方法和导出字段是否会promote到外部类型中。

5. 非导出类型用作嵌入字段

我们改造一下示例，新版的带有嵌入字段的结构见下面mypackage包的代码：

// go-exported-identifiers/embedded_field/mypackage/mypackage.go

package mypackage

import "fmt"

type nonExported struct {
    Field string // 导出的字段
}

// Exported 是导出的结构体，嵌入了nonExported
type Exported struct {
    nonExported // 嵌入非导出结构体
}

func NewExported(value string) *Exported {
    return &Exported{
        nonExported: nonExported{
            Field: value,
        },
    }
}

// M1是导出的函数
func (n *nonExported) M1() {
    fmt.Println("invoke nonExported's M1")
}

// M2是导出的函数
func (e *Exported) M2() {
    fmt.Println("invoke Exported's M2")
}

这里新增一个导出类型Exported，它嵌入了一个非导出类型nonExported，后者拥有导出字段Field，以及两个导出方法M1。我们也Exported类型定义了一个方法M2。

下面我们再来看看main.go中是如何使用Exported的：

// go-exported-identifiers/embedded_field/main.go

package main

import (
    "demo/mypackage"
    "fmt"
)

// 定义一个导出的接口
type MyInterface interface {
    M1()
    M2()
}

func main() {
    ms := mypackage.NewExported("Hello")
    fmt.Println(ms.Field) // 访问嵌入的非导出结构体的导出字段

    ms.M1() // 访问嵌入的非导出结构体的导出方法

    var mi MyInterface = ms
    mi.M1()
    mi.M2()
}

在go-exported-identifiers/embedded_field目录下编译运行这个示例：

$go run main.go
Hello
invoke nonExported's M1
invoke nonExported's M1
invoke Exported's M2

我们看到，作为嵌入字段的非导出类型的导出字段与方法会被自动promote到外部类型中，通过外部类型的变量可以直接访问这些字段以及调用这些导出方法。这些方法还可以作为外部类型方法集中的一员，来作为满足特定接口类型(如上面代码中的MyInterface)的条件。

Go 1.18增加了泛型支持，那么非导出类型是否可以用作泛型函数和泛型类型的类型实参呢？最后我们来看看这个细节。

6. 非导出类型用作泛型函数和泛型类型的类型实参

和前面一样，我们先定义用于该示例的带有导出字段和导出方法的非导出类型：

// go-exported-identifiers/generics/mypackage/mypackage.go

package mypackage

import "fmt"

// 定义一个非导出的结构体
type nonExported struct {
    Field string
}

// 导出的方法
func (n *nonExported) M1() {
    fmt.Println("invoke nonExported's M1")
}

func (n *nonExported) M2() {
    fmt.Println("invoke nonExported's M2")
}

// 导出的函数，用于创建非导出类型的实例
func NewNonExported(value string) *nonExported {
    return &nonExported{Field: value}
}

现在我们将其用于泛型函数，下面定义了泛型函数UseNonExportedAsTypeArgument，它的类型参数使用MyInterface作为约束，而上面的nonExported显然满足该约束，我们通过构造函数NewNonExported获得非导出类型的实例，然后将其传递给UseNonExportedAsTypeArgument，Go会通过泛型的类型参数自动推导机制推断出类型实参的类型：

// go-exported-identifiers/generics/main.go

package main

import (
    "demo/mypackage"
)

// 定义一个用作约束的接口
type MyInterface interface {
    M1()
    M2()
}

func UseNonExportedAsTypeArgument[T MyInterface](item T) {
    item.M1()
    item.M2()
}

// 定义一个带有泛型参数的新类型
type GenericType[T MyInterface] struct {
    Item T
}

func NewGenericType[T MyInterface](item T) GenericType[T] {
    return GenericType[T]{Item: item}
}

func main() {
    // 创建非导出类型的实例
    n := mypackage.NewNonExported("Hello")

    // 调用泛型函数，传入实现了MyInterface的非导出类型
    UseNonExportedAsTypeArgument(n) // ok

    // g := GenericType{Item: n} // compiler error: cannot use generic type GenericType[T MyInterface] without instantiation
    g := NewGenericType(n)
    g.Item.M1()
}

但由于目前Go泛型还不支持对泛型类型的类型参数的自动推导，所以直接通过g := GenericType{Item: n}来初始化一个泛型类型变量将导致编译错误！我们需要借助泛型函数的推导机制将非导出类型与泛型类型进行结合，参见上述示例中的NewGenericType函数，通过泛型函数支持的类型参数的自动推导间接获得GenericType的类型实参。在go-exported-identifiers/generics目录下编译运行这个示例，便可得到我们预期的结果：

$go run main.go
invoke nonExported's M1
invoke nonExported's M2
invoke nonExported's M1

7. 非导出类型使用导出字段以及导出方法的用途

前面的诸多示例证明了：即使类型本身是非导出的，但其内部的导出字段以及它的导出方法依然可以在外部包中使用，并且在实现接口、嵌入字段、泛型等使用场景下均有效。

到这里，你可能会提出这样一个问题：会有Go开发者使用非导出类型结合导出字段或方法的设计吗？

其实这种还是很常见的，在Go标准库中就有不少，只不过它们更多是包内使用，类似于非导出类型xxxImpl和它的Wrapper类型XXX的关系，或是xxxImpl或嵌入到XXX中，就像这样：

// 包内实现
type xxxImpl struct {  // 非导出的实现类型
    // 内部字段
}

// 导出的包装类型
type XXX struct {
    impl *xxxImpl  // 包含实现类型
    // 其他字段
}

// 或者通过嵌入方式
type XXX struct {
    *xxxImpl  // 嵌入实现类型
    // 其他字段
}

但也有一些可以包外使用的，比如实现了某个接口，并通过接口值返回，提供给外部使用，例如下面的valueCtx，它实现了Context接口，并通过WithValue返回，供调用WithValue的外部包使用：

//$GOROOT/src/context/context.go

func WithValue(parent Context, key, val any) Context {  // 构造函数，实现接口
    if parent == nil {
        panic("cannot create context from nil parent")
    }
    if key == nil {
        panic("nil key")
    }
    if !reflectlite.TypeOf(key).Comparable() {
        panic("key is not comparable")
    }
    return &valueCtx{parent, key, val}
}

// A valueCtx carries a key-value pair. It implements Value for that key and
// delegates all other calls to the embedded Context.
type valueCtx struct {
    Context
    key, val any
}

func (c *valueCtx) Value(key any) any {
    if c.key == key {
        return c.val
    }
    return value(c.Context, key)
}

这么做的目的是什么呢？大约有如下几点：

• 隐藏实现细节

非导出类型的主要作用是防止外部直接使用和依赖其内部实现细节。通过限制类型的直接使用，库作者可以保持实现的灵活性，随时调整或重构类型的内部逻辑，而无需担心破坏外部调用代码； 还可以避免暴露多余的API，使库的接口更加简洁。

• 控制实例的创建和管理

通过非导出类型，开发者还可以确保外部代码无法直接实例化类型，而必须通过导出的构造函数或工厂函数，就像前面举的示例那样。这种模式可以保证对象始终以特定的方式初始化，避免错误使用。同时，它还可以用来实现更复杂的初始化逻辑，如依赖注入或资源管理。

• 在接口实现中的作用

非导出类型可以用来实现导出的接口，从而将接口的实现细节完全隐藏。对于用户来说，只需要关心接口的定义，而无需关注其实现。

8. 小结

本文探讨了Go语言中的导出标识符及其相关细节，特别是非导出类型如何与其导出字段和导出方法结合使用。

尽管某些类型是非导出的，其内部的导出字段和方法依然可以在包外访问。此外，非导出类型在实现接口、嵌入字段和泛型中也展现出良好的应用。这种设计不仅促进了封装和接口实现的灵活性，还允许开发者通过构造函数返回非导出类型的实例，从而有效控制实例的创建与管理。这种方式帮助隐藏实现细节，简化外部接口，使得代码结构更加清晰。

本文涉及的源码可以在这里下载。

Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且，2025年将在星球首发“Go陷阱与缺陷”和“Go原理课”专栏！此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾
。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
• Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。