一行不起眼的代码，一次直通 Go 源码的奇妙旅程
去年，在我日常阅读 Golang 官方 issue 时，一条并不起眼的问题引起了我的注意。
问题的起点
某位开发者在 Go 的 text/template 包中写了这样一段代码：
go
package main
import (
"os"
"text/template"
"log"
)
func main() {
tmpl := `{{/*
This is a multiline comment.
It spans multiple lines.
*/}}
{{undefinedFunction "test"}}
`
t, err := template.New("test").Parse(tmpl)
if err != nil {
log.Fatalf("Template parse error: %v", err)
}
err = t.Execute(os.Stdout, nil)
if err != nil {
log.Printf("Template execution error: %v", err)
}
}
这段代码的目的是测试 template 中对多行注释的处理。但当你运行它时会发现一个奇怪的现象：报错的行号与实际出错的代码行对不上。乍一看可能觉得只是一个小问题，但对于调试模板解析错误的人来说，这种错位让人抓狂。
更神奇的是，我自己在使用 text/template 时也遇到过类似的问题------那种你一度怀疑人生、满头问号的场景。
不懈的调试
于是，我决定一探究竟。
我开始从 text/template/parse 包中的源码层层往下翻查。由于 template 模板引擎内部涉及到大量递归解析 AST 节点的过程，要完全掌握它的逻辑并不容易。调试过程中，我反复设置断点，尝试不同的输入模板，一步步缩小问题的范围。
最终，我锁定了问题根源：golang/go#69526。
原因是在处理多行注释时，没有正确地增加行号计数。因为多行注释的跳过逻辑处在深层递归中，估计最初写代码的工程师也不曾留意这一点。
提交修复补丁
确认问题后，我决定亲自提交一个修复 PR：golang/go#69532。
我不仅修复了逻辑，还特地补充了单元测试，确保类似场景以后不会再出现行号错乱的情况。
Go 的源码不是直接在 GitHub 上维护的，他们使用自己的一套 Gerrit 代码评审系统：go-review.googlesource.com
在这个平台上，我参与了一场激烈的技术讨论，收获颇丰。
Rob 的 Code Review ------ 人生巅峰
更让我惊喜的是，Go 的作者之一，Rob Pike，亲自给我做了 Code Review。
这个名字对我来说并不陌生，Plan 9、Unix、Go......Rob 是一个传奇人物。
他在 review 中给我提了一个小建议：把测试函数的名字改得更清楚点。
虽然只是一个细节，但那一刻我有种被历史亲手点名的感觉。
更有趣的是，我后来才发现：原来这个 bug 最早就是 Rob 写的代码里埋下的，某种意义上，我算是替他擦了个小锅（笑）。
我的补丁，正式并入 Go 源码
最终，我的修改顺利合入 Go 源码主干。
GitHub 上的 PR 会被关闭，Go 团队每隔一段时间会将 Gerrit 上的提交同步到 GitHub。这种流程对于代码质量和审查透明度的把控，令人敬佩。
后记
我常听人说："35 岁就该退休转管理了。"但看看 Rob，年近 60 仍然活跃在一线写代码、做 code review。
而我，也因为一个不起眼的 issue，意外地走进了 Go 源码的世界。那种 "把一个世界级项目的 bug 修复并写入历史"的感觉，无法用言语形容。
每一行注释，每一个测试用例，都是我热爱这个职业的证明。
撒花🎉