本文永久链接 – https://tonybai.com/2026/07/14/171-accepted-unimplemented-go-proposals-a-decade-of-technical-debt
大家好，我是Tony Bai。
Go 语言的提案（Proposal）机制，一直被认为是开源社区治理的范本之一：任何人都可以在 golang/go 仓库提交提案，经过公开讨论、每周例会审阅，最终由核心团队给出 Accepted（接受）/ Declined（拒绝）的结论。这套流程运行了十几年，外界普遍评价是“慢，但运行还算正常”。
不过，如果你打开 GitHub 上golang仓库的这条筛选链接：
state:open label:"Proposal-Accepted"
会看到一个略显尴尬的数字——171。
也就是说，有 171 个提案已经被官方明确“批准通过”，却因为迟迟没有代码实现和代码合入，Issue 仍然挂在“未关闭”状态。其中年纪最大的一个，编号 #5901（encoding/json：支持按 Encoder/Decoder 注册自定义的 marshal/unmarshal 规则），提交于 2013 年 7 月——距今已经 13 年。
“被批准”不等于“被实现”，这在任何工程体系里都不新鲜。但 Go 的特殊之处在于，它的提案库是完全公开、有据可查的，这让我们第一次可以完整地把这堆“技术欠账”翻出来，看看它到底欠了多久、欠在哪、以及官方最近有没有在还。
先做一次“体检”：171个Issue的画像
我们抓取了全部 171 条 Accepted 状态的 Issue，按创建时间、里程碑（Milestone）、涉及的包/工具做了统计。
先看年龄分布，以 2026 年 7 月为基准：
| 提案年龄 | 数量 | 占比 |
|---|---|---|
| 不到 1 年 | 9 | 5% |
| 1–2 年 | 15 | 9% |
| 2–3 年 | 22 | 13% |
| 3–5 年 | 40 | 23% |
| 5–8 年 | 44 | 26% |
| 8–10 年 | 32 | 19% |
| 10 年以上 | 9 | 5% |
超过一半（约 50%）的已接受提案，积压时间在 5 年以上。这不是个案，是常态。
再看官方给它们排的"档期"（Milestone）：
| Milestone | 数量 | 含义 |
|---|---|---|
| Backlog | 107 | 已批准，但暂无明确排期 |
| Unreleased | 22 | 已有代码但尚未随版本发布 |
| Unplanned | 21 | 已批准，明确说"暂不计划" |
| Go1.28 | 8 | 已排入下一个大版本 |
| Go1.27 | 6 | 已排入即将发布的版本 |
| Proposal | 7 | 流程状态待整理 |
近 63% 的提案挂在 Backlog——这是 Go 团队一个相对诚实的做法：与其假装“很快就做”，不如明确标注“暂无人力，欢迎社区认领^_^”。
分类来看，欠账最多的是这几块：
x/*扩展仓库（x/net、x/crypto、x/tools 等）：31 个- 标准库综合类（无固定包前缀，多为语言/工具链层面）：26 个
cmd/go命令本身：22 个- 密码学相关（
crypto/*、x/crypto/*）：22 个 - 其他命令行工具（
cmd/vet、cmd/compile、cmd/asm等）：19 个 net/net/http：13 个testing/runtime：各 8 个
一个有意思的规律是：越“边缘”的仓库和越依赖社区贡献的领域，积压越严重。x/* 系列仓库本来就不在 Go 核心团队的 KPI 里，crypto 相关提案往往涉及大量向后兼容的谨慎评估，天然就慢。
几个值得展开讲的“钉子户”故事
数据背后，每一个长期未落地的提案都有自己的故事。挑几个有代表性的说一说。
1. 十年之后，它真的要来了：类型推断的复合字面量
#12854（spec: type inferred composite literals）创建于 2015 年 10 月，讨论热度极高——279 条评论，是 171 个提案里讨论最激烈的第二名。它想解决的问题很朴素：写 []*Point{{1, 2}, {3, 4}} 这种嵌套复合字面量时，能不能让编译器自动推断出内层的类型，而不用每次都写全 &Point{1, 2}。
这个提案在漫长的拉锯之后被正式接受，而根据最新的里程碑标记，它已经被排进了 Go 1.28——也就是说，一个十年前提出的语法改进，很可能会在明年正式落地。这或许是本轮梳理里最好的"欠账终于要还"的例子。
2. 已经实现，却卡在"要不要默认打开"：压缩包路径穿越漏洞
#55356（archive/tar, archive/zip: add ErrInsecurePath）是个安全类提案，创建于 2022 年 9 月，背后关联了 CVE-2018-25046、CVE-2020-36560 等多个真实漏洞编号——archive/tar 和 archive/zip 长期以来会原样返回压缩包里的路径，如果调用方不加处理直接落盘，就可能被"路径穿越"攻击写到任意目录。
有意思的是，这个提案早在 CL 449937 就已经写好代码合入了，但默认是关闭的，需要显式设置 GODEBUG=zipinsecurepath=1 才能拿到旧行为、=0 才是新的安全检查。原因是社区反馈发现大量 Docker 镜像里的 tar 文件本身就包含绝对路径，贸然把安全检查设为默认开启会大面积破坏现有程序。于是这个 Issue 至今仍然挂着 NeedsDecision 标签——代码已经写完，卡住的是"什么时候把开关默认打开"这个产品决策。这提醒我们：一个提案被标记 Accepted、甚至代码已经合并，也不代表它已经在你的程序里生效。
3. 被讨论了8年，至今没人交作业：go build -static
#26492 创建于 2018 年 7 月，标题很简单：给 go build 加一个 -static 参数，把现在那一长串魔法参数（-ldflags '-extldflags "-fno-PIC -static"' -buildmode pie -tags 'osusergo netgo static_build'）封装起来。
八年过去，Issue 底下积累了 42 条评论，几乎全是社区用户在互相传授各种手写的静态编译参数组合，甚至还衍生出了 Windows、macOS、Alpine/musl 下各不相同的坑。核心维护者 Ian Lance Taylor 很早就说过，这个提案本身技术难度不大，缺的是有人愿意投入时间做跨平台测试，标签也一直是 help wanted。这是一个典型的"共识早已达成、代码却始终无人认领"的案例——它比拼的不是技术方案，而是谁愿意花时间去啃这块难啃的边角料。
4. 三年拉锯战：该不该允许"重试"一个测试
#62244（cmd/go: add support for dealing with flaky tests），来自前Go核心成员、现Tailscale 工程师 Brad Fitzpatrick，想给 testing.T 加一个 Retry() 方法，让"偶发失败"的测试可以标记后自动重跑。
这条 Issue 引发了标准库维护者 Bryan Mills 等人长达数十条评论的细节争论——重试该发生在哪一层？子测试失败后父测试还能重试吗？会不会掩盖真正的数据竞争 Bug？最终提案在争论中被接受，目前标签里挂着 FixPending（修复代码正在流程中）。它的价值在于告诉我们：哪怕是一个看起来"该有"的功能，Go 团队也会为 API 的每一个语义细节较真到底，这也是为什么积压清单里有大量提案在"接受"和"落地"之间隔着好几年的讨论期。
5. 早就实现了大半，只是"迟迟关不掉"：寄存器传参
#40724（cmd/compile: switch to a register-based calling convention for Go functions）是本次梳理里讨论最激烈的提案，292 条评论。它提议把 Go 函数调用从"栈传参"改成"寄存器传参"，预期能带来 5%–10% 的整体性能提升。
这个提案其实早在 Go 1.17（2021 年）就已经在 amd64、arm64 上落地，是过去几年 Go 运行时最重要的性能优化之一。但 Issue 至今没关——因为其他架构（386、MIPS 等）的寄存器 ABI 还没做完。这类"大提案"往往会被拆成几十个 CL 分批合入，“未关闭"不代表"没有进展”，反而可能是进展最快的那一批。
为什么会攒下这么多"欠账"？
把这些故事放在一起看，会发现"171"这个数字背后其实有几层原因，而不是简单的"Go团队拖延"：
第一，“Accepted"从来只是共识，不是排期。
官方的表态非常明确——一旦提案通过，Issue 的定位就从"要不要做"变成"记录实现进度”，但具体谁来做、什么时候做，取决于是否有核心团队成员认领，或者是否有社区贡献者提交 CL。Backlog 里 107 个提案，本质上就是"没人认领"的状态。
第二，很多提案依赖社区，而不是 Google 内部资源。
打上 help wanted 标签的提案（比如 -static 标志），核心团队默认把它当作"欢迎外部贡献"的任务，如果没人主动提交实现，它可以在 Backlog 里一直放着。
第三，涉及行为变更的提案，往往要经过漫长的"软着陆"周期。
ErrInsecurePath 的故事说明，哪怕代码写完了，一旦涉及默认行为的改变，Go 团队宁愿先做成 GODEBUG 开关观察几个版本的兼容性反馈，也不愿贸然强推——这是 Go 1 兼容性承诺决定的谨慎风格，代价就是 Issue 长期挂着不关。
第四，x/* 扩展仓库和密码学模块本身优先级更低。
这两块加起来占了 171 个里的 53 个，接近三分之一，恰恰是因为它们不属于标准库的"必须维护"范围，或者涉及密码学安全审查，天然节奏更慢。
但迹象显示：官方正在"加速消化"
如果只看历史积压，容易得出"Go 提案机制正在失速"的悲观结论。但把镜头拉近到最近几周，会看到一些不一样的信号。
以文章开头提到的三个 Issue 为例，截至发稿（2026 年 7 月上旬），它们全部处于近一周内刚被更新的状态：
- #62244（flaky test 重试）：标签已更新为
FixPending，意味着修复代码正在评审队列中； - #55356（压缩包路径安全）：近期仍有维护者在讨论默认行为切换的时间表；
- #26492（
go build -static）：社区在最近一周内仍有新的实践反馈提交。
再结合前面统计到的里程碑分布——Go 1.27（预计 2026 年 8 月发布）已明确排入 6 个历史遗留提案，Go 1.28 排入 8 个，其中就包括那个十年前的"类型推断复合字面量"提案。再往前看这几年的版本节奏：Go 1.26（2026 年 2 月发布）把 gotypesalias、tlsunsafeekm 等好几个拖了多个版本的 GODEBUG 开关正式清理转正；Go 1.27 又计划继续清理一批遗留的兼容性开关。
这背后隐约能看到一种工作方式的转变：与其无限期地让一个"默认关闭的新行为"停留在 GODEBUG 里，Go 团队近几个版本明显加快了把这些历史开关"转正"或者"清理"的节奏，某种意义上也是在替多年前的提案"还账"。
写在最后：给关注 Go 生态的人的几点提示
如果你是 Go 用户或者贡献者，这份"171个已接受未实现"的清单其实很有实用价值：
- 如果你正在等待某个 Go 新特性，先查一下它是不是已经"Accepted"却卡在 Backlog。这意味着共识早已达成，缺的只是实现者——如果你有能力，这可能是一个比"从零提案"低得多的贡献门槛。
- 不要把"Accepted"等同于"即将发布"。一个提案从接受到真正随版本发布，中位数大概率要横跨好几个 Go 大版本，涉及兼容性的改动尤其如此。
- 关注 Milestone 标签，而不是只看 Accepted 标签。挂着
Go1.27、Go1.28这类具体版本号的提案，才是短期内真正会落地的那一批；Backlog和Unplanned更像是一份"愿望清单"。
Go 的提案机制之所以被认为运行良好，恰恰是因为它把这些"没做完"的事情摆在明面上，而不是悄悄雪藏。
171 这个数字看起来触目惊心，但换个角度看，它也是一份公开、透明、随时可以被验证进度的路线图——这在很多闭源语言和框架里，是完全看不到的。
数据来源：GitHub golang/go 仓库 Issue 检索（state:open label:"Proposal-Accepted"），统计时间为 2026 年 7 月。文中提及的版本发布时间以 Go 官方发布说明为准，如有更新以官方信息为准。
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
- 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
- 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
- 想打造生产级的Go服务，却在工程化实践中屡屡受挫？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
