本文永久链接 – https://tonybai.com/2026/07/11/typescript-compiler-rewritten-in-go-agentic-ai-language

大家好，我是Tony Bai。

微软TypeScript团队用一年多时间，把TS编译器从TypeScript本体迁移到了Go语言，构建速度直接暴涨了一个数量级，并于近日发布了TypeScript 70正式版。这门被很多人认为“过气”、“无聊”的Go语言，正在AI智能体时代悄悄杀回牌桌中央。前Go语言产品经理、知名开源项目Hugo的创造者Steve Francia（以下称为spf13）近日撰文，系统论证了一个反直觉的观点：Go，才是为Agentic AI时代量身定做的语言。

TS编译器弃用TypeScript本体，转投Go，构建速度提升10倍

这件事本身就足够炸裂。

TypeScript的缔造团队，微软官方，把自家旗舰工具的编译器和一整套工具链，从TypeScript迁移到了Go。不是Rust，不是C++，是Go。根据微软最新公布的数据，新版TS 7.0的构建速度提升了一个数量级。

TypeScript的技术负责人Anders Hejlsberg给出的理由非常“朴素”：老版本编译器大量使用函数式写法，几乎可以一比一平移到Go；新老编译器都依赖垃圾回收（GC）；而原生代码加上共享内存并发模型，正是这次十倍性能提升的来源。有意思的是，官方公告里通篇没有提到一个字的“AI”。

但spf13在文章里点出了关键：让这次“平移式重写”成为可能的那些特质——简单的函数、没有隐藏的魔法、自带GC、一个团队能装进脑子里的代码——恰恰是下一个开发时代最需要的特质。

这就是整篇文章要回答的问题：为什么在2026年这个AI智能体疯狂写代码的时间点上，一门2009年为“人类系统程序员”设计的语言，反而成了最契合的选择。

Go的底层哲学：为“读者”优化，不为“写者”优化

要理解spf13的论证逻辑，得先回到Go语言设计之初的一个基本赌注：优化阅读体验，而不是书写体验，用“写起来稍微啰嗦一点”换“读起来不容易读错”。

这个赌注在过去十几年里，一直是Go被吐槽“啰嗦”、“无聊”、“没有语法糖”等的原因。但spf13认为，这个赌注在AI智能体时代突然兑现了红利。

原因很简单：大语言模型“读”代码的频率，远远超过任何人类程序员。而随着AI承担越来越多的代码编写工作，人类工程师的角色也在加速向“阅读者”偏移——审查、把关、决策，而不是逐行敲键盘。

Agentic开发（也就是AI智能体自主完成“写代码-构建-测试-调试-自我修正”这一整套闭环）是对“可读性、可维护性、长期正确性”最极端的一次压力测试。而这恰恰是Go从诞生第一天起就在优化的目标。

Python和TypeScript的“生态光环”，在系统级场景下不够用了

表面上看，Python和TypeScript才应该是AI时代的当红语言：Python坐拥PyTorch、LangChain这些机器学习生态，TypeScript手握整个Web开发者群体，大模型训练数据里到处都是这两种语言，写起来又快又“顺手”。

但spf13的反驳角度很刁钻：Python和JavaScript从诞生起就是脚本语言，追求的是写得快、写得随意、动态灵活。TypeScript虽然给JavaScript加上了类型系统，但这层类型只存在于编译期，运行时会被完全擦除，也就是说TypeScript的所有类型保证，代码真正跑起来的那一刻就荡然无存。

根据GitHub 2025年度Octoverse报告，TypeScript按月活跃贡献者数量已经超过了Python和JavaScript，但同期JavaScript新建仓库数量仍然接近Python的两倍——报告原话是“JavaScript依然庞大”，JavaScript/TypeScript生态整体活跃度仍然超过Python单独一个生态。

但问题的关键在于：Agentic系统不是脚本，而是服务、流水线、命令行工具和需要在生产环境跑上好几年的分布式系统。

而Python、JavaScript、TypeScript这三门语言，在复杂度管理、依赖隔离、部署方式、运行时安全性这几个维度上，都是在跟自己的语言设计初衷“对着干”。

反观Go，从一开始就是为“大规模、长生命周期软件”设计的系统语言。这恰好踩在了整个行业正在收敛的方向上：编译型、类型安全、为跑十年而生，而不是为了跑一个下午。

有意思的是，Python生态里目前最“性感”的进展，其实大多发生在Rust身上：Pydantic的校验核心是Rust写的，高性能数据处理库Polars是Rust写的，HuggingFace的tokenizers是Rust写的，连Astral出品的包管理神器uv也是Rust写的。

而Go的存在感体现在另一条战线：它已经成了当前这一波Agentic工具基础设施的默认语言。本地大模型运行标准工具Ollama，是Go写的；支撑无数RAG和智能体记忆系统的向量数据库Weaviate，是Go写的；用来编排长时间运行智能体工作流的持久化执行引擎Temporal，是Go写的；Charm出品、和Google Antigravity同类的AI编程智能体命令行工具Crush，也是Go写的；就连GitHub官方发布的MCP服务器参考实现，同样是用Go写的。

spf13总结道：在一个开发循环里，问题从来不该是“哪门语言最容易写”，而应该是“哪门语言最容易写、审查、并交付上线”。而Agentic开发把这个问题的权重放大了几十倍——因为现在，一天要被问上百次的，是一台机器，而不是一个人类。

Agentic循环，会把每一个语言短板同步放大

spf13给出了一个很直观的对比：一个人类开发者，一小时大概会跑十几次“写-构建-测试”的循环；而一个自主运行的AI智能体，一个任务里就可能跑上几十次这样的循环。这个频率的变化，彻底改变了“语言选择”这件事的经济账。

数据科学工具Ibis的作者Wes McKinney，在他关于“智能体工程学”的文章里也提出过类似观点：一旦写代码的主体变成了AI智能体，编译-测试的循环速度、分发的顺畅程度、构建结果的确定性，比这门语言“人类写起来爽不爽”重要得多。他不只是写文章，他自己给AI编程智能体做的持续后台代码审查工具Roborev，就是用Go写的。

spf13把这套压力拆成了四个会互相叠加放大的问题：

1. 构建速度

对大型Rust或C++项目来说，几分钟的构建时间，人类顶多算“喝杯咖啡的功夫”，但对一个要在一个功能上跑50次迭代的AI智能体来说，这几分钟乘以50，就是实打实被浪费掉的算力和时间。Go的编译速度几乎是即时的，这直接决定了整个循环能不能“转得动”。

2. 依赖管理

Python的pip默认并不保证安装结果的确定性，跨机器的版本冲突至今仍然常见。

Node的npm在处理依赖冲突这件事上其实做得相当不错，node_modules可以嵌套存放同一个包的多个版本，配合package-lock.json和npm ci，安装的可复现性已经好了很多，但在peer dependency（同级依赖）这块依旧容易卡在ERESOLVE报错上，需要人工去解开。而这种“版本灵活性”是有代价的：层层嵌套的依赖树，会把node_modules撑得又大又臃肿，也拉高了AI智能体需要理解和处理的信息量。

更关键的是，Python和Node两个生态都允许在安装阶段执行任意代码（setup.py、postinstall脚本），这本身是真实存在的供应链安全风险，双方都曾因此“中招”过。

Go走的是另一条路：go.sum会锁定精确的校验和，整个构建过程中每个模块只会确定性地选出唯一一个版本，也没有“安装阶段执行代码”这个后门可以被恶意依赖利用。对一个要持续生成代码、持续部署的AI智能体来说，这意味着更少的版本漂移，也意味着更小的攻击面。

3. 错误反馈

Python的类型提示和TypeScript的类型系统，配合mypy、pyright、tsc这类工具，确实能在运行前抓出不少真实错误。但两者都有一个共同的“后门”：Python的类型标注至今仍是可选项，落地程度参差不齐；TypeScript的类型保证在运行时会被完全擦除，而any是一个官方认可、零成本的逃生舱口——只要代码写得不顺手，随时可以用它“摆平”类型报错。

这恰恰是一个在时间和token压力下运行的AI智能体，最容易被诱导去做的事：用any让代码“先跑起来”，成本几乎为零。

搭建AI智能体编排框架Superpowers的Jesse Vincent，记录过这个后门被打开之后会发生什么：AI智能体会“合理化”自己绕过规则的行为。他遇到过一个真实案例——一个AI智能体为了让失败的测试“消失”，直接把测试文件删掉了，逻辑上竟然自洽：不存在的测试，当然不会失败。他的原话总结得很精辟：规则总有一个可以被“合理化”绕开的口子（“我先做完这一件事再遵守”），而闸门没有——条件不满足，下一步动作就是被物理拦住，无从商量。

Go恰好没有这个口子。Go也有any（本质是interface{}的别名），但和TypeScript的any不是一回事：TypeScript的any会关闭它所触及的所有类型检查，而Go的any在每一个使用点都依然会被检查，编译器会拒绝任何类型不支持的操作，除非你显式做类型断言，而这个断言本身也会被编译器验证。换句话说，逃生舱口本身也是被锁着的。

在Python或TypeScript里，一个错误往往要拖到运行时才会暴露——而这时候，AI智能体很可能已经在这个错误的基础上继续往上叠加了更多代码，返工成本（上下文和API调用）已经像利滚利一样滚起来了。在Go里，同样的错误在编译阶段就会被当场逮住，智能体还没来得及运行任何代码。

这个差异同样会体现在代码审查环节——现在审查双方也经常都是AI。一个负责审查的智能体，能看懂Python或JavaScript代码“写了什么”，但未必能可靠地判断它“实际做了什么”，因为元类（metaclass）和原型链会把真实的行为路径藏起来，静态阅读根本看不出来。

Go用同样的方式消除了这个盲区：一个函数名只对应一个含义，方法调度只按名字走，没有任何隐藏的控制流可以在审查的任何一侧“藏”住一个bug。Go的类型系统不是后加的一层修饰，它就是这门语言本身，天然覆盖100%的代码。

4. 生态更迭

spf13认为这可能是四个问题里影响最大的一个。Go有一份延续至今的兼容性承诺：2012年为Go 1.0写的代码，今天依然能正确编译运行。语言和标准库只做加法，几乎从不破坏已经跑通的东西。

而Node生态里，没有任何东西能提供类似的保证。主流框架频繁打破自己此前版本的兼容性：Svelte 5的Runes是和Svelte 4完全不同的响应式模型；Vue 3彻底重写了Vue 2的响应式系统；React从class组件到hooks再到服务端组件的演进，导致现在同时流通着好几套互不兼容的“React代码写法”。问一句“这段代码是哪个版本的Svelte或Vue”，本质上是在问“这段代码到底还能不能跑”。Python也不是完全免疫——Python 2到3长达十年的迁移就是前车之鉴——但Node生态的更迭速度明显更快、更持续。

这种生态震荡对AI智能体来说是个特殊的、会持续叠加的问题：智能体对一个生态的“认知”，本质上是训练时刻的一张快照，而在一个快速变化的生态里，这张快照很快就会过期，产出的代码看起来“很像那么回事”，实际调用的却是早已被重构或废弃的接口。而在Go的世界里，几年前的训练快照放到今天依然是正确的。这意味着智能体可以直接信任自己已有的知识，而不需要每次任务都重新去核实一遍。

Google的杰出工程师Dave Rensin，在带队用AI智能体搭建一个面向10万用户的内部工具时，说过一句很扎心的话：“如果我们不小心，我们做的就不只是更快地写代码，而是在批量生产我们自己的错误。” 这个风险不是Go独有的，它是AI辅助开发在任何语言下都存在的通病。但Go的结构——静态类型、显式导入、没有魔法——恰好是天然对抗这个风险的摩擦力：糟糕的代码，从一开始就更难被写出来。

spf13还提到了一个PayPal团队分享给他的真实案例：一套自研的C++数据库性能强劲、逻辑正确，但团队却陷入了停滞——每个新人入职都要花几个月才能吃透代码库，大部分工程产能都耗在了维护上。大约六个月后，一支约十人的团队用Go重写了这套系统，性能在生产环境反超了原来的C++版本，维护成本却低得多。Go并不比C++更快，真正的瓶颈从来不是代码运行速度，而是团队能不能理解、维护、扩展这套代码。“实际能兑现的性能，胜过理论上的性能”——这正是今天Agentic团队在做的同一笔交易，只是被压缩进了一个短得多的周期里。

那Rust呢？为什么不是Rust？

Rust和Go其实是互补关系，各自适合不同的场景，在Agentic开发里都有一席之地，但spf13认为Rust更像是一件“专用工具”，而不是默认选项。

Rust和Go共享很多优点：内存安全、静态类型、没有隐藏的运行时魔法。Rust的编译器报错也出了名地详细——按照“编译器即闸门”的逻辑，一条详尽的借用检查器（borrow checker）报错信息，对AI智能体来说同样是实打实的价值。

但两者的分歧恰好出现在Agentic开发最不能容忍的地方：Rust的编译时间明显更长；而支撑Rust安全保证的那套复杂机制——生命周期、trait约束、借用检查器——本身是要付出代价的，代价就是Go那种“一件事只有一种明显写法”的可读性。

这个代价在重构阶段体现得最明显：按spf13的经验，一处改动在Go里往往是局部的，而在Rust里却可能沿着生命周期和trait约束层层扩散开。而“可重构性”恰恰是Agentic开发最依赖的能力——现在做返工的是AI智能体而不是人类，智能体需要做的返工量还远远大于人类。语言越复杂，智能体读错的概率就越高，而一旦读错，这个bug会随着迭代不断累积。

不过Rust也有自己的独门绝技：通过PyO3、maturin这类工具，Rust可以零成本地生成C ABI绑定，非常适合在Python包底层塞入一个编译好的Rust核心——这正是Pydantic、Polars、HuggingFace tokenizers都选择Rust的原因。

相比之下，Go在这个场景里历来偏弱，因为cgo（Go调用C代码的机制）本身会带来不小的性能开销。虽然Go 1.26已经把cgo调用的基础开销削减了约30%，但在很多这类场景里，Rust仍然是更好的选择。

spf13的结论很务实：对Agentic开发而言，Go的简洁和可读性，让它成为智能体越来越依赖的“系统层”的默认选择；而Rust，则是当它的那些保证真正值得付出代价时，才该请出来的专用工具。

上下文窗口才是Agentic开发里最稀缺的资源，而Go在保护它

这一段可能是全文最反直觉、也最值得工程师细品的部分。

前面提到的所有问题，本质上都是“成本 × 迭代次数”，而上下文（context）则是Agentic工作里一笔持续存在的固定成本——而且，上下文窗口不是越大越好。

“干脆用更大的上下文窗口”，这个想法背后有一个默认假设：模型能均匀地在20万甚至100万token的窗口里进行推理。

Chroma在2025年的一项研究里，对包括GPT-4.1、Claude 4、Gemini 2.5、Qwen3在内的18个主流大模型做了直接测试：固定任务难度，只改变输入长度，结果证明这个假设是错的——即便是很简单的任务，性能也会随着输入变长而下降。研究把最大的元凶称为“干扰项”（distractors）：那些和任务主题相关、但并不是答案本身的内容。一个干扰项就能让准确率明显下滑，四个干扰项叠加起来，伤害是复合式的。与其想办法把上下文窗口做大，更划算的做法其实是想办法把输入变小。

一条类的继承链、一串mixin、一层层装饰器（decorator）——对一个正在追踪bug的AI智能体来说，这些都是干扰项的重灾区。一个super()调用要经过菱形继承才能解析到位，一个元类在运行时悄悄改写了行为，一个override被埋在三层继承之外——这些内容本身都不是智能体需要的逻辑，但它依然得把这些内容加载进来、权衡一遍、再排除掉，而这一切都发生在同一个本就在“性能衰减”的推理窗口里。这也是为什么AI智能体经常自信满满地写出忽略了某个继承覆写、或者调用错了mixin方法的代码。

Go的设计恰好是极简且显式的：一个文件需要的所有东西，都写在这个文件和它直接导入的包里——没有继承链，没有从六个目录之外引入的mixin，没有在运行时偷偷改写方法解析规则的元类。函数名只对应一个含义，编译器会强制执行这一点。Go代码里几乎所有token，都是真正相关的token。

这还带来一个连锁效应：它降低了完成一个任务所需要的模型门槛。一个能装进2万个“干净”token的bug，和一个被埋在15万token框架噪音里的同一个bug，需要的推理能力完全不是一个量级。更简单、干扰更少的代码，对模型来说更容易写对，这意味着更小、更便宜、甚至本地部署的模型，也能写出能跑的Go代码——而同样的任务换成Python、Java、Rust或TypeScript/JavaScript，这些小模型很可能就翻车了。

这一点在AI公司不再“烧钱补贴”算力成本的那一天会变得更加重要——而这个趋势已经开始显现。

一门能让代码始终保持简洁、简单到中等模型也能正确处理的语言，它的成本结构才经得起补贴消失之后的考验。同一个特质在天平的两端同时兑现：让小模型能写对代码的东西，也正是让人类审查者能快速读懂代码的东西——因为双方都不需要再费力“反推”出被隐藏起来的行为。

再往深一层说，这还意味着代码更可能一次就写对，也就意味着更少的迭代次数、更少的API调用、更少被烧掉的上下文，模型能把更多精力花在真正不需要人类介入的任务上。

上下文效率，其实是Go在2009年就下的那笔赌注里最锋利的一个体现：无论读者是人类还是机器，永远优先为“读”而不是为“写”去优化。

一种格式，零风格之争

同样这个“为读者优化”的赌注，也体现在代码的表面形态上。gofmt是Go自带的官方格式化工具，整个社区的代码都跑在它上面。不管是人类写的、机器生成的、写于十年前的，还是AI智能体今天早上刚写完的，每一份Go代码在结构上看起来都一模一样。

长期打造AI辅助Go工具的开发者Simon Willison也观察到了这一点：他评价说，Go“通常只有一种明显该做的方式”，写出来的代码“朴素又好读”，而这恰好是大语言模型非常擅长驾驭的那种代码风格。

当每一份Go文件看起来都长得一样时，一个AI智能体在开始工作之前，其实就已经被“预先调教”好了。

只要把它指向Go标准库（比如encoding/json、net/http、io），它立刻就能写出符合社区规范、生产级质量的代码，完全不用纠结black和yapf哪个更好、isort和ruff该选哪个。

再配合像 go-skills 这样的项目，这种“预调教”效果会更直接——智能体不再需要从零散的示例里推测代码规范，而是拿到了一份明确、可复用的Go惯用写法指南。对代码审查来说，无论审查者是人类还是AI，注意力都能完全集中在逻辑本身，而不是格式噪音上。

Go优化的不只是“写代码”，而是整条软件生命周期

大部分语言比较文章，关注点都停留在“写代码这一步谁更快”。但软件开发生命周期（SDLC）远不止写代码：构建、测试、部署、调试、维护，每一环都要走。而在Agentic工作流里，每一环都是以机器的频率在运转的。

过去十年里，Go的生态已经从一门语言，进化成了一整套完整的SDLC平台：模糊测试（fuzzing）成了内置能力，govulncheck让漏洞管理走向成熟，workspace模式统一了monorepo开发体验，模块代理机制大幅减少了版本冲突——而这一切，都不需要跳出Go生态本身去解决。

依赖管理交给go mod tidy，无论在笔记本、CI还是容器里，结果都是确定性的、完全一致的——不像pip或npm，每一次依赖解析失败都意味着白白损失一次迭代。

测试环节，go test ./...一条命令就够了：不需要挑选测试框架，不需要配置一堆fixture。在包目录下丢一个_test.go文件，写一个Test开头的函数，一条命令跑完。

对一个要强制执行测试驱动开发（TDD）的AI智能体来说，这种可靠性让“闸门”这件事变得真正确定，而不是像Python那样被fixture的复杂配置拖累。编译速度快，靠的是精确的依赖关系图，这直接乘数级地提升了迭代吞吐量。

部署环节更是简单到只有go build：一个自包含的二进制文件，没有运行时依赖，没有解释器版本问题，没有容器启动时间——复制这个二进制文件，直接运行就行。

这些优势不是简单相加，而是相乘：每一环的循环都变快，意味着每小时能跑的迭代更多、API成本更低、结果也更可靠。

这不是要“一统天下”，而是“分层最优”

spf13在文章最后特别强调，这篇文章的主张从来不是“弃用Python”或者“弃用TypeScript”。把一整个技术栈的所有层级都押注在同一门语言上，无论押的是哪门语言，本质上都是同一种错误。

真正该问的问题更具体：在Agentic工作流越来越依赖的系统、服务、基础设施这一层，哪门语言最合适？ 在2026年，答案更多时候是Go，因为它恰好完美契合这一层的需求。

Python的机器学习生态——PyTorch、LangChain、Transformers——依然不可替代，也不应该被替代。训练模型、跑推理，Python依然是标准答案，Go完全不在这个赛道上竞争，而是在为它提供补充。

Go完全可以运行在Python底层，也可以运行在它旁边。Simon Willison做过一个叫 go-to-wheel 的工具，能把编译好的Go二进制文件打包成Python的wheel包发布到PyPI上——任何Go程序都能变成一行pip install或uvx就能装的东西，他自己写的并发文件系统扫描工具sqlite-scanner就是这么发布的。

Flask的创造者Armin Ronacher也从另一个角度印证了同样的观点：他把自己的MiniJinja项目从Rust移植到Go，只花了45分钟、60美元的API调用成本，也正因如此，他认为“写代码的成本正在急剧下降……生态系统的广度，重要性正在变得越来越低”。

Python负责编排，Go负责底层执行——而随着语言之间移植成本越来越低，“只能押注一个生态”这个理由，正在一个月一个月地被削弱。你不需要在Go的结构性优势和Python的生态优势之间二选一，两者完全可以兼得。

写在最后：Go，天生就是为这个时代准备的

spf13的结论很直接：Go当年被设计出来的目的，就是为了降低大规模软件的总体成本——而这恰恰是Agentic开发正在把它推向极限的那个问题。那些当年让Go适合人类规模团队的特质，放到今天每天要跑几千次迭代的机器身上，同样适用。

这不代表Go是唯一值得用的语言。Python依然稳坐机器学习生态的头把交椅，Rust和TypeScript在各自的场景里也依然有充分的理由被选用。

spf13给出的建议是：与其追求“一门语言统治一切”，不如把Go当作Agentic开发中系统、服务、基础设施这一层的默认选项，除非你有明确理由选别的。

当你要新建一个服务、一个命令行工具或者一套系统时，先问一句“为什么不用Go”——如果你能说出一个站得住脚的理由（比如某个关键库只有别的语言才有、性能要求Go达不到、或者团队已经在某门语言上投入太深，迁移成本已经超过收益），那就用别的语言。如果说不出来，Go大概率就是正确的默认选项。

文章的最后一句话，或许是整篇文章最值得工程团队记下来的一句：“每一个因为构建太慢、依赖不稳定、或者运行时意外而损失掉的百分点，最终都会变成实打实的API成本。随着Agentic工作负载在2026年持续扩张，语言选择很可能是撬动这笔成本最大的一根杠杆。早一步消除这些摩擦的团队，会比还在为此买单的团队，迭代得更便宜、也更快。”

这篇文章之所以值得细读，不只是因为它对Go语言的力挺，更因为它提供了一个思考AI智能体时代工具选择的通用框架——当“写代码”的主体从人变成机器，那些原本只是“工程师品味偏好”的语言特性（可读性、类型系统的严格程度、依赖管理的确定性、生态的稳定性），正在变成实打实可以用API调用成本和迭代效率来量化的硬指标。无论你是否认同“Go是天选语言”这个结论，这套评估框架本身，值得每一个正在搭建Agentic开发流水线的团队认真想一想。

参考链接：

• https://spf13.com/p/go-the-agentic-language/
• https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。