本篇要回答的问题：版本规划——“下一步重点放哪里、什么先做什么后做”——的套路是什么？从 Go 语言九年的版本演进里，能提炼出怎样的战略定力？
前面话题集中在软件工程的质量与效率（架构师要对执行结果负责）。本讲跃升到一个更高维的话题：版本规划。方向正确不代表能走到最后，执行路径与方向同等重要——它能影响业务成败、企业生死。本讲以 Go 语言为实际案例来推敲背后的逻辑。
Go 版本的演进历史
Go 大体每半年发布一个版本。关键脉络如下：
| 版本 / 时间 | 标志性变化 | 类别 |
|---|---|---|
| Go 1.0 (2012.03) | 里程碑：发布向后兼容承诺；os.Error → 内建 error 类型；工程工具完善（go test/doc/vet/pprof）；GC 效率被诟病 | 使用范式定型 + 工程能力 |
| Go 1.1 (2013.05) | 专注内在机制与性能（编译器、GC、map、调度）；发布竞态探测器 race detector | 性能 |
| Go 1.2 (2013.12) | 单元测试覆盖率工具 go tool cover | 工程能力 |
| Go 1.3 (2014.06) | 栈改连续段分配（替代 segment stack）；引入 sync.Pool 内存池；channel 优化 | 性能 |
| Go 1.4 (2014.12) | runtime 由 C/汇编改为 Go 实现（GC 更精确，堆分配减 10~30%）；Android/iOS 支持；go generate | 性能 + 领域扩展 |
| Go 1.5 (2015.08) | 实现自举，GC 全面重构（并发 GC，延迟降一个数量级）；引入 vendor（后证明不成功）；go tool trace | 性能 + 工程能力 |
| Go 1.6 (2016.02) | GC 延迟进一步降低；支持 HTTP/2 | 性能 + 标准库 |
| Go 1.7 (2016.08) | context 包进标准库（网络编程最佳实践标准化）；编译性能优化（二进制更小 20~30%） | 标准库 + 性能 |
| Go 1.8 (2017.02) | GC 延迟降到毫秒级以下；大幅提升 defer 性能 | 性能 |
| Go 1.9 (2017.08) | type alias 语法；sync.Map 支持并发访问 | 使用范式 |
| Go 1.10 (2018.02) | go test 结果缓存、go build 包缓存，加速构建 | 工程能力 |
| Go 1.11 (2018.08) | Go modules（推翻 vendor 重来）；试验性 WebAssembly 支持 | 工程能力 + 领域扩展 |
| Go 1.12 (2019.02) | go vet 基于 analysis 包重写，支持自定义 checker | 工程能力 |
| Go 1.13 (2019.08) | sync.Pool 性能改善；逃逸分析重写（更少堆分配）；GOPROXY 默认值 | 性能 |
Go 版本迭代的背后：变的是什么？
Go 1.0 之后语言本身基本稳定，那么这些年到底在变什么？归纳为四条主线：
| 主线 | 具体表现 |
|---|---|
| 性能、性能、性能！ | 尤其 GC 效率持续优化，为它大范围重构、完成自举；连续栈、内存池、更快编译、更小可执行文件 |
| 强化工程能力 | 各种 go tool；最突出的是模块版本管理（vendor → module 两次尝试） |
| 标准库能力增强 | context、HTTP/2 等；context 是对网络编程最佳实践的一次标准化 |
| 业务领域扩展 | 整体专注服务端，仅对 Android/iOS/WebAssembly 做经验性支持 |
如何做版本规划
很多技术同学一上来就陷入技术细节泥潭。但对一个从 0 到 1 的业务，首先把焦点放在哪里才至关重要。Go 给出了示范：
| 业务阶段 | 焦点放在哪 | 原则 |
|---|---|---|
| 从 0 到 1 | 用户使用姿势（产品规格）的迭代 | 与此无关的事达到及格线就先放一放——这也是为什么 Go 早期被吐槽 GC 仍安之若素 |
| 从 1 到 100（扩张期） | 切换到用户看不见的地方：非功能性需求 | 生产环境用户最关心的指标，成为最关注的事，日复一日优化 |
关键判断：这是很了不起的战略定力——知道什么情况下，最该做的事情是什么。
遇到招致巨大影响面的重大需求怎么办？ 以 Go 的泛型为例：
| 错误姿势 | Go 的正确姿势 |
|---|---|
| 急着快速支持（因为听起来振奋） | 认真对待但不急实现，放到旁路版本独立演化，验证成熟后才合并到 Go 1.x，届时才诞生 Go 2.0 |
关键判断：客户是需要尊重的，而尊重客户的正确姿势是——别折腾他们。
总结
版本规划的侧重点随业务阶段剧变：从 0 到 1 验证用户使用姿势，性能不是第一位；进入扩张期则迭代用户真正最在乎的非功能性需求。遇到冲击巨大的需求，头脑别发热，回到从 0 到 1 的方法论——放旁路版本、在少量客户上先做灰度。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 版本规划 | 下一步重点放哪、什么先做什么后做的顶层选择 |
| 战略定力 | 知道在什么阶段，最该做的事是什么，并能忍住不做其他 |
| 旁路版本 | 把冲击大的重大需求隔离独立演化，成熟后才合并主线 |
| 从 0 到 1 vs 扩张期 | 前者迭代 “使用姿势”，后者迭代看不见的 “非功能性需求” |
一句话速记
从 0 到 1 只盯 “用户怎么用”，性能够及格就放一放；进了扩张期就死磕用户看不见却最在乎的非功能指标；遇到大冲击的需求别上头，丢进旁路版本慢慢灰度——尊重客户就是别折腾他们。
几条值得记住的判断
- Go 1.0 后语言基本不变，真正在持续变的是性能、工程能力、标准库。
- 战略定力比追新更难也更重要：早期被吐槽 GC 仍专注使用姿势。
- 重大需求放旁路版本独立验证，是响应巨大影响面需求的正确姿势。
思考题
回到你的产品：你现在处于从 0 到 1 还是扩张期？你的版本规划焦点对得上这个阶段吗——是不是在用户使用姿势还没稳定时，就过早去抠性能？面对一个 “听起来很振奋” 的大需求，你有勇气把它放进旁路版本慢慢验证吗？
