我给Geth提了一行代码，然后被合并了

这事儿得从半年前说起,那时候我还在折腾自己的小项目，一个基于以太坊的轻量级索引服务，跑着跑着，发现节点同步总是卡在某个区块高度，日志里反复出现一个奇怪的内存警告。

我翻了半天文档,最后把矛头指向了Geth——也就是以太坊官方最常用的那个Go语言客户端，说实话，当时我对给这种重量级项目提交代码没什么概念，总觉得那是核心开发者的事儿，跟我这种写业务代码的没关系，但那个内存问题实在烦人，我决定打开源代码看看。

第一眼看到Geth的代码，我是有点懵的。

几百万行的Go代码,光目录结构就够研究半天，我顺着报错信息找到了 core/state 目录下的 statedb.go，问题出在一个状态对象的缓存清理逻辑上，每次区块状态变更，它都会触发一次全量扫描，清理那些已经不再被引用的存储槽位，这个设计在理论上没问题，但实际操作里，当交易特别密集的时候，这种全量扫描会造成明显的性能抖动。

我当时的想法很简单：能不能把这个扫描改成增量式的？只标记那些真正被改动过的槽位，而不是每次遍历整个状态树。

我把这个想法写成了一个小补丁，发到了Geth的GitHub仓库。

说实话,发出去之后我就没抱太大希望，那会儿是周四晚上，我甚至做好了被冷落的准备，结果第二天一早，邮箱里就躺着一封来自Péter Szilágyi的回复——他是Geth的核心维护者之一，回复很简短：“有意思，但你的基准测试呢？”

我意识到,光有代码是不够的。开源贡献的门槛不在写代码，而在证明你的代码比原来的更好。 于是我开始做基准测试，用Go自带的pPRof工具，跑了三组不同的测试场景：一是普通转账，二是密集的合约交互，三是极端情况下的状态膨胀。

结果出乎意料,我那个增量补丁在普通转账场景下确实快了百分之十几，但在合约交互场景下，反而慢了，因为合约会频繁修改同一个存储槽位，增量逻辑需要额外维护一个脏标记列表，这部分开销抵消了性能收益。

我没放弃，重新设计了方案。

我抛弃了“全增量”的想法，改成自适应策略，用一个简单的计数器，记录最近一段区块内的状态修改频率，如果修改频率低，就走全量扫描；如果修改频率高，就切换成增量模式，这样两种场景都能覆盖。

这个版本我跑了两周测试,数据稳定，然后我重新提了PR，附上了完整的基准测试结果，包括内存占用曲线和CPU profile截图，这次Péter回复得很快，他提了几个细节问题，比如并发安全、内存对齐，还有对 trie 缓存的影响，我一一回答，并且又补了两个边缘场景的测试。

两个月后，这个PR被合并了。

合并那天,我盯着屏幕看了好一会儿，不是激动，是很平静，那行被合并的代码总量并不大，核心逻辑加起来不到一百行，但合并之后，Geth在区块处理效率上确实有了微小的提升，Geth的每一次版本更新，都会影响到成千上万个节点，以及依托这些节点的应用。

说实话,我最初以为这只是一次普通的技术贡献，但后来我发现，开源贡献的深意远不止于此。

代码风格。

Geth的代码规范极其严格,提交之前，我重写了三遍注释，因为维护者要求每一行注释都要解释“为什么这样做”，而不是“做了什么”，这让我反思自己平时写业务代码的习惯——大多数时候我们只关心功能实现，很少关心代码的意图传达，在开源项目里，你的代码会被无数人阅读，注释本身就是文档。

沟通方式。

在PR的讨论区,我学会了如何用数据说话，而不是用感觉，Péter问问题，从来不问“你觉得这个方案怎么样”，而是问“这个场景下你想过没有”或者“你能不能提供这个数据”，这让我明白，开源社区是靠信任运转的，而信任只能建立在可验证的事实上。

再有一点，是维护者的耐心。

我提交的第一版方案,其实并不好，但没有人嘲讽，也没有人直接关闭，他们给了详细的反馈，指出问题所在，然后等我自己去改进，这种氛围，跟公司里“今天提需求明天要上线”的急躁感完全不同，你会觉得，你是在跟一群认真对待技术的人合作，而不是在完成一个任务。

现在回头想，给Geth提的那次代码优化，改变了我对“贡献”的理解。

贡献不是一个宏大的概念,它可能是修一个拼写错误的注释，也可能是优化一个热点路径上的内存分配，Geth的更新日志里，每一条看起来都那么小，但正是这些无数的小改进，堆出了以太坊主网的稳定运行。

我记得有一次,在某个技术群里看到有人讨论“为什么Geth的代码这么难读”，有个老哥回复说：“难读是因为它被无数人改过，而每次改动都必须兼顾所有人。”这句话我深有体会。

我提交的那个补丁，后来被其他开发者继续优化了两轮。

有人改进了我的计数器算法,让它更适应高并发环境，有人补充了对SSZ格式的支持，我的代码成了别人工作的起点，这种感觉很奇妙，你不再是孤立的个体，而是整个生态系统里的一环。

如果你也想参与开源贡献，我的建议其实就三条。

第一,别怕，别觉得自己的水平不够，Geth里面也有大量简单的PR，比如更新依赖版本、修复文档错误、添加测试用例，这些同样是贡献，同样会被感谢。

第二,从自己遇到的问题出发。 我最初就是因为那个内存警告才去翻源码的，你日常开发中遇到的任何怪异行为，都可能是项目的bug或者优化空间，自己踩过的坑，解决起来动力最足。

第三,学会接受批评，开源贡献者的反馈往往直接甚至尖锐，但别往心里去，那是对代码的批评，不是对你的否定，把每条意见当成一次免费的代码审查，你会学到比任何教程都多的东西。

我的那个补丁,现在躺在Geth的代码库里，每次看到新版本发布，我都会下意识地翻一下变更日志，找找有没有我的那条记录，虽然它已经淹没在密密麻麻的更新条目里，但我知道它在那儿。

那天晚上,我删掉了自己项目里原本用来绕过那个内存问题的hack代码，因为Geth已经不需要那个hack了。

开源这东西，说大也大，说小也小，大到你没法一个人改变它，小到你一行代码就能让它变得更好，而我，只是那无数个“微小”里的一部分。