夜雨聆风
Go 1.27的更新说明，比上一版Go 1.26短了将近四分之一。
这不是印象。8月19日Go 1.27发布当天，我把go.dev/doc/go1.27和go.dev/doc/go1.26两个页面都抓到本地，剥掉HTML标签只留正文，用最笨的办法数了一遍：1.27是3138个英文词，1.26是4116个；小标题（h2到h4三级加起来）1.27有50个，1.26有63个。两项都是新版更少。
可这版攒了整整六个月，语言层面还动了泛型方法这种大手术。说明变短，改动就真的变少了？我又数了第二样东西，结果正好翻过来。
说明页的源码里，埋着一份出处清单
每一条release note在HTML里都被一行注释标了出处，长这样：<!-- go.dev/issue/77273 -->。页面上看不见，得看源码。我把注释里的编号和正文里可点的/issue/链接合并去重，1.27是32个，1.26是16个，整两倍。
这里得先做个口径自查。1.27的页面里还多出28行形如6-stdlib/99-minor/crypto/tls/78888.md的碎片文件名注释，那串数字同样是issue号，全算进去能数到55个；而1.26的页面里一行这种注释都没有。两版页面的生成方式不一样，硬拿55比16是不公平的，所以我只按双方都有的那个口径来比，32对16。
说明变短、来源翻倍，这两件事凑一块只说明一点：1.27的条目更密，每条写得更省。省掉的地方，恰恰是数字。
1.26敢写10%到40%，1.27只敢写1%
两版都在运行时上做了性能文章，底气差得挺远。
1.26换掉了垃圾回收器，Green Tea转正，说明里写的是"重度依赖GC的真实程序，开销预计降低10%到40%"，还额外许诺在Ice Lake、Zen 4以后的新CPU上再多10%。
1.27的运行时头条叫"Faster memory allocation"：编译器改为调用按尺寸特化的分配函数，小于80字节的小对象，分配成本最多降30%。紧接着一句就把话收了回去——"整体提升预计在1%左右"，代价是二进制体积涨约60KB。
30%和1%是怎么测出来的，我顺着编号追了一遍。这一节正文里没有可点的链接，注释里的编号是79286。在GitHub上打开golang/go#79286，标题是"runtime: sizespecializedmalloc experiment"，matloob今年5月8日开的，7月6日关掉，21条评论里有18条是机器人贴代码提交，剩下3条在讨论什么时候删掉这个GOEXPERIMENT开关。整个issue里没有一张benchmark表，没有任何一个百分比。
再追写这段说明的那次提交，Gerrit上的CL 783140，提交信息交代得很实在：这段文字是照着1.26周期给sizespecializedmalloc写好的稿子改的，只是换上了新数字。这个特性原本奔着Go 1.26去，滑了一版。
机器信息只在旁边几个提交里留下了间接痕迹。CL 772540和CL 776740挂了性能对比trybot，名字是gotip-linux-amd64_c2s16、gotip-linux-amd64_c3h88，以及arm64的c4as16和c4ah72，按命名规则看是GCP的c2、c3、c4a实例。至于"最多30%"跑的到底是哪个benchmark、"约1%"又是哪个真实程序，issue和这一串CL里我都没找到原始数据。
那句"小于80字节"，差了一个字节
数据查不到，我退一步去核那个尺寸阈值，这个至少是能核死的。
Go仓库的release-branch.go1.27分支里，src/runtime/_mkmalloc/constants.go有个常量specializedMallocMax = 80，旁边注释说更大的尺寸类收益很有限、带上包装层有时反而更慢。生成器mkmalloc.go把它换算成尺寸类上限，循环条件写的是sc <= scMax，闭区间。再翻internal/runtime/gc/sizeclasses.go那张表，第7类正好是80字节一个对象。
也就是说，80字节整的对象是被特化了的。说明里那句"<80 byte"，严格讲该写成"≤80"。一个字节的事，不影响任何人用Go，但它多少透露出这版说明的数字是顺手写的，不是量着写的。
那么对着这两组数，做业务后端的要不要马上升？1%的分配提速，不值得你专门排一次发版窗口。倒是有两件更该先看的：time包创建的channel现在永久变成无缓冲的了，asynctimerchan这个救命GODEBUG被彻底删除，靠它续着的老代码这回没得续；另一件是macOS 12以及更早的机器直接出局，Go 1.27要求macOS 13起步。真正值得为它升级的量级在JSON那边，下面说。
一句话带过的flate，背后是张有点吓人的表
compress/flate那一节，说明里只有一句：Go 1.27里压缩速度提升了。没有数字，没有百分比。
注释给的编号是75532，对应CL 707355，内容是把klauspost那套compress的flate实现清理后搬进标准库。提交信息里贴了完整的benchmark表，我挑三行：Encode/Digits/Default/1e6从18.3ms降到8.5ms，快53.73%；同一份数字数据换成最高压缩档，Encode/Digits/Compression/1e6从18.3ms涨到32.0ms，慢74.58%，吞吐从54.6MB/s掉到31.3MB/s。内存也普遍涨了，多数档位从776KB升到1016至1144KB。用例名尾巴上那个"-32"是GOMAXPROCS，说明跑在32核机器上，具体型号提交里没写。
这个改动2025年9月27日以GitHub PR的形式提上来，2026年4月15日才合并，在评审里躺了近七个月。默认档确实快了一大截，但把压缩级别拧到9的人，升级前最好自己测一遍。
JSON这块，1.26的说明里一个字都没提
两版并排看，落差最大的是JSON。1.26的release notes全文，"json"只出现在示例代码和一句顺带的举例里，没有任何一条正式条目。到了1.27，encoding/json/v2和encoding/json/jsontext两个包直接进标准库，老的encoding/json底层被整个换成v2实现，对外行为不变。
说明里对性能的原话是：marshal大致持平，unmarshal显著更快。"显著"是多少，正文没说。提案issue 71497里，作者dsnet那条性能评论给了口径：unmarshal比v1快2.7倍到10.2倍，测的数据集有名有姓，CanadaGeometry、CITMCatalog、SyntheaFHIR、TwitterStatus、GolangSource、StringUnicode六份，对照基线写明是encoding/json的v1.23.5版本。
但那条评论写于2025年1月31日，测的是当时那个实验模块，图表还是归一化倍数，没写CPU型号。release notes把它压缩成"significantly faster"，这个处理我理解：那组数字和1.27最终落地的实现之间，隔了一年半。
我没查到的部分
先把话说死：这篇里所有百分比，我一个都没有自己跑过。我没在机器上装Go 1.27，没编译，没跑任何benchmark，做的全部是抓页面、数数、追issue和CL、翻源码。
明确查不到的有三处。分配提速"最多30%"对应的原始benchmark，issue 79286和它牵出来的十几个CL里都没有，我只能按release notes的口径转述。"整体约1%"是在什么真实程序上测的，同样没有出处。flate那张表的测试机型号，提交信息只透露了32核这一条。至于JSON那组2.7到10.2倍，来源是提案里的旧评论，不是1.27实现的实测。
Go 1.27说明页里"Faster memory allocation"那一节的出处注释，写的是go.dev.issue/79286，中间是个点，不是斜杠。这个拼法在Go仓库的doc/next/4-runtime.md源文件里就是这么写的，原样渲染进了发布页，是全篇唯一一个拼错的出处标记。
资料来源：go.dev/blog/go1.27（2026年8月19日）、go.dev/doc/go1.27与go.dev/doc/go1.26页面源码、GitHub golang/go issue 79286与71497、Gerrit CL 783140/707355/772540/776740/780300、Go仓库release-branch.go1.27分支源码。词数、章节数与issue引用数为本文作者自行统计。