标签 goroutine 下的文章

2026年,大厂重构核心系统为何集体投向 Go?

本文永久链接 – https://tonybai.com/2026/06/08/the-real-reason-big-tech-is-switching-to-go

大家好,我是Tony Bai。

在软件工程中,核心技术栈的迁移是一项高风险、高成本的决策。

然而,在近期的技术演进中,我们看到了一股明显的趋势:全球科技巨头与快速成长的 AI 独角兽们,正在不约而同地将核心系统向 Go 语言(Golang)收敛。

  • 微软宣布将 TypeScript 核心编译器移植到 Go,构建速度暴涨 10 倍。
  • Reddit将庞大的 Python 单体架构逐步解耦,核心数据模型全面改用 Go 重写。
  • Lovable(前沿 AI 独角兽)将 4.2 万行 Python 代码移植为 Go,服务器实例直接从 200 个锐减到 10 个。
  • Uber作为长期拥有最庞大 Go 代码库的企业之一,持续将后端服务从 Python、Node.js 收敛、统一至 Go 语言,以极低的算力成本承载海量并发。

这并非盲目的技术跟风,而是一场基于运行成本、高并发能力和工程维护性的理性重构。今天,我们就通过这些大厂的真实工程案例,深入拆解大厂重构核心系统时,集体投向 Go 的底层逻辑与技术启示。

微软的编译器移植:为什么 C# 之父不选 C# 和 Rust?

2025 年 3 月,微软宣布将 TypeScript 的编译器和工具链移植到 Go 语言。到了 2026 年 4 月,采用 Go 编译器底层的 TypeScript 7 Beta 正式发布。

令人瞩目的是,这个项目的操盘手正是 Anders Hejlsberg —— C# 语言的设计者TypeScript 的创造者

这一决策在技术社区引发了深度探讨:为什么微软不用自家的 C#,也没有选择近年来大热的 Rust?这背后隐藏着极具启发性的工程权衡。

明确“移植(Port)”与“重写(Rewrite)”的边界

在工程决策中,这两者有着本质区别:

  • 完全重写(Rewrite):意味着抛弃旧代码,从零开始重新设计(New Design),风险极高。
  • 代码移植(Port):翻译现有代码,保持原有的代码结构和行为(Same behavior & structure),风险可控。

旧的 TypeScript 编译器是用函数式风格编写的,且重度依赖垃圾回收(GC)

  • 为什么不选 C#?C# 是典型的面向对象(OOP)语言。如果使用 C#,将很难平滑移植函数式风格的旧编译器,几乎等同于要推倒重写。
  • 为什么不用 Rust?Rust 没有垃圾回收机制,要求开发者手动且极其严苛地管理内存。如果改用 Rust,团队必须彻底推翻并重新设计整套代码的内存生命周期,这直接背离了“平滑移植”的初衷。

Go 为什么是最佳折中方案?

Go 既支持原生编译,拥有极高的运行速度,同时还内置了高效的垃圾回收(GC)。

更关键的是,习惯写法的 Go 代码(Idiomatic Go)在结构上与 TypeScript 原有的编码模式有着天然的相似性。这使得原有团队在维护移植后的 Go 代码时,几乎没有认知摩擦。

移植后的性能收益:
* 编译构建速度直接提升了 10 倍
* 编辑器加载时间从原来的 9.5 秒缩短至 1.2 秒

微软用事实证明:Go 是在维持原有代码结构的前提下,实现性能跨越式提升的最短路径。

Reddit 的解耦之路:高并发压力下的“影子测试”

Reddit 曾长期使用 Python 单体(Monolith)架构。随着全球流量的爆发,单体架构的弊端逐渐显现:代码耦合严重、可靠性降低,系统维护成本极高。在高峰期,甚至连发帖、评论等基础操作都会遭遇严重的延迟。

为了解决高并发瓶颈,Reddit 决定对核心的四大基础特性(评论、账户、帖子、子社区)进行解耦,全部用 Go 语言重写为独立的微服务。

为什么选择 Go?

在高并发场景下,Go 内置的轻量级协程(Goroutine)和通道(Channel)调度模型,相比于 Python 的多线程/多进程,能够以更低的系统开销和更少的网络协调,抗住同等规模的流量。

零故障上线的“影子测试(Shadow Testing)”

系统重构最忌讳“一刀切”式的直接上线。Reddit 采用了一套精妙的过渡方案:

他们让 Python 旧单体Go 新服务在后台同时运行。对于每一次写入请求,两个系统都会收到相同的输入。Go 服务将数据写入一个隔离的测试数据库。

               ┌───────────────┐
               │  User Input   │
               └───────┬───────┘
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
    ┌─────────────────┐ ┌─────────────────┐
    │ Python Monolith │ │   Go Services   │
    └────────┬────────┘ └────────┬────────┘
             ▼                   ▼
    ┌─────────────────┐ ┌─────────────────┐
    │  Production DB  │ │     Test DB     │
    └─────────────────┘ └─────────────────┘
             │                   │
             └─────────┬─────────┘
                       ▼
             Compare & Debug Output

通过在后台持续对比两个系统的输出结果,团队在不影响真实用户的前提下,排查并修复了新服务中的所有潜在 Bug。确认无误后,才 100% 将流量平滑切换到了 Go 服务。

重构后的收益:
* 关键写入操作的 P99 延迟直接砍半,系统高可用性大幅提升。

运行成本与算力优化:Lovable 与 Uber 的工程实践

对于快速成长的 AI 独角兽 Lovable 来说,技术栈的选择直接关系到服务器账单和业务存亡。

作为一个允许非技术用户通过 AI 构建应用的平台,Lovable 在核心链路上面临着极高并发的挑战。用户发送一条聊天指令,后台需要瞬间触发超过 50 个 HTTP 并发调用,分别去请求各大模型提供商、内部存储及周边服务。

Python 在这种高度并行的 IO 密集型场景下显得力不心。Lovable 团队果断将 4.2 万行 Python 代码重写为 Go

无独有偶,Uber 作为长期拥有最庞大 Go 代码库的企业之一,也曾经历过从 Python、Node.js 向 Go 逐步收敛的过程。为了在单机上压榨出更高的并发能力,减少冗余的服务器开销,Uber 逐步在后端服务中停用了 Python,将核心服务统一收敛至 Go。

这两家公司,用 Go 实现了令人惊叹的算力优化:

小结:大厂系统重构释放的工程信号

这些大厂和独角兽们的集体实践,为我们释放了清晰的工程信号:

  1. “运行成本”正成为系统重构的首要驱动力
    在项目初期,动态语言(如 Python、TypeScript)确实能提供极佳的开发爽感。但当业务规模扩大、高并发场景增加时,其带来的服务器硬件成本和维护开销将呈指数级上升。
  2. Go 处于“开发效率”与“运行性能”的黄金分割点
    它不像 Rust 那样有着极其陡峭的内存管理和所有权学习曲线,能够让团队保持极高的开发效率;同时,它又拥有接近原生代码的执行速度,和冠绝群雄的轻量级并发模型。这使其成为了现代生产级后端服务的首选。

大厂的重构实践,为我们提炼了以下三条黄金工程铁律:

  1. 分清“移植”与“重写”:在系统重构时,若想在保留原有业务逻辑的前提下快速提升性能,像微软那样进行代码级移植(Port)是风险最低、效率最高的路径。
  2. 善用“影子测试(Shadow Testing)”:核心系统解耦和替换时,切忌盲目上线。采用双轨并行、对比输出的影子测试,是保障系统平滑过渡、零故障上线的最佳实践。
  3. 高并发场景首选轻量并发模型:当系统面临大量并发 IO(如 AI 编排、多 API 协同调用)时,Go 语言的协程机制能够以极低的资源消耗提供极佳的吞吐量。

系统重构的本质,是在业务发展、团队认知和机器成本之间寻找最优解。而 Go,正是大厂在经历数次工程实践后,给出的最务实的答案。

资料链接:https://www.youtube.com/watch?v=-Z813pHqSFI


今日开放讨论:

  1. 微软不用 C# 也不用 Rust,而是选择 Go 来移植 TS 编译器,这个决策中的“移植 vs 重写”权衡是否启发了你?
  2. Reddit 采用的“双轨制影子测试”非常稳健,你在实际的系统迁移或重构中,使用过类似的测试方案吗?
  3. 从 Lovable 将 200 个实例缩减为 10 个,到 Uber 节省 97% 的算力,这些真实的性能与成本数据是否改变了你对后端技术选型的看法?

欢迎在评论区留下你的硬核观点,我们一起探讨系统重构与 Go 的工程之美!


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

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

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


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

省下 10% CPU!Uber 揭秘 Go 栈扩容的隐秘代价

本文永久链接 – https://tonybai.com/2026/05/28/uber-reveals-hidden-cost-of-go-stack-growth-10-percent-cpu-savings

大家好,我是Tony Bai。

在顶级互联网巨头的底层架构中,性能优化绝不仅仅是写两段优雅的代码,而是一场“刀尖舔血”的硬核战争。

试想一下,如果你的公司拥有超过 200 万个 CPU 核心(Cores),且其中 65% 的微服务完全由 Go 语言驱动,会发生什么?在 Uber 这样的计算体量下,哪怕仅仅提升 1% 的 CPU 效率,每年都能为公司省下数百万美元的真金白银。

最近,Uber 基础架构团队在对核心服务进行性能 Profiling 时,抓出了一个隐藏极深的 CPU “吸血鬼”。这个内鬼既不是复杂的业务逻辑,也不是被千夫所指的垃圾回收(GC),而是 Go 语言引以为傲的并发基石——Goroutine 栈扩容(Stack Expansion)

在部分核心微服务中,仅仅是栈扩容(runtime.copystack)这一项底层操作,就吞噬了近 10% 的 CPU 资源!而在 Uber 全局 600 多个微服务大盘中,栈拷贝的平均成本也高达 3.9%(作为对比,代价高昂的 GC 平均成本约为 7.3%)。

面对如此惊人的性能黑洞,Uber 的工程师们没有选择向官方妥协。他们直接向 Go 运行时(Runtime)开刀,甚至手撕底层汇编代码,硬生生把这 10% 的 CPU 损耗压到了 0.0047%。不仅如此,他们还将研究成果反哺给 Go 官方社区(Issue #77893),正在推动 Go 语言栈分配机制的历史性进化。

今天,就让我们扒开 Go 运行时的源码,重走一遍 Uber 团队打赢这场性能保卫战的硬核之旅。

剖析“案发现场”:Go 栈扩容的阿喀琉斯之踵

熟悉 Go 的开发者都知道,Go 在全球范围内大杀四方的核心武器就是 Goroutine(协程)

为了实现极高的并发密度,Go 语言在设计上做了一个大胆的取舍:与传统的操作系统线程(OS Thread,如 pthread_create 动辄分配 2MB 或 4MB 的初始栈)不同,一个 Goroutine 的初始栈空间仅仅只有 2KB

这种设计的优势是极其明显的:你可以轻松在一台普通机器上拉起数十万甚至上百万个 Goroutine,而不用担心内存溢出(OOM)。但天下没有免费的午餐,如果你的函数调用层级过深,或者在函数内部声明了较大的局部变量,区区 2KB 的栈空间瞬间就会被撑爆。

当 2KB 不够用时,Go 会怎么做?

Uber 团队在博客中深入解释了这一机制:Go 编译器会在每个函数的序言(Prologue)阶段插入一段检查指令,对比当前的栈指针(Stack Pointer)是否超过了阈值。


用于演示栈扩展过程的示例汇编代码

第 2 行展示了堆栈指针的值。如果该值超过了阈值,程序就会跳转到 runtime.morestack 函数进行处理。

一旦触发 runtime.morestack,Go 运行时会执行以下昂贵的操作:

  1. 申请一块原栈空间两倍大(即 4KB)的新内存。
  2. 调用 runtime.copystack,将旧栈的数据原封不动地“拷贝”到新栈中。
  3. 极其复杂的一步:更新旧栈中所有指向局部变量的指针,确保它们指向新栈的正确内存地址。
  4. 释放 2KB 的旧栈。

如果 4KB 依然不够呢?那就继续分配 8KB、拷贝、释放;再分配 16KB、拷贝、释放……

在 Uber 复杂的微服务链路中(比如处理庞大的 gRPC 请求、复杂的序列化/反序列化中间件),一个请求进来,往往需要数十 KB 的栈空间。这意味着每次请求都会触发多次徒劳无功的“搬家行为”。在峰值流量下,无数个 Goroutine 都在疯狂扩容,最终导致 CPU 算力被海量的内存拷贝白白挥霍。

为什么 Go 1.19 的“自适应栈”彻底失效了?

其实,Go 官方早就意识到了这个问题。在 Go 1.19 版本中,官方高调引入了一项优化:自适应栈大小(Adaptive Stack Size)

其设计初衷非常聪明:Go 会在每次垃圾回收(GC)扫描栈时,计算当前所有存活 Goroutine 的平均栈大小。如果当前程序的平均栈大小是 16KB,那么接下来新创建的 Goroutine 就会直接以 16KB 启动,完美避开 2KB -> 4KB -> 8KB -> 16KB 的拷贝地狱。

但这套看似完美的机制,在 Uber 真实的业务场景下,却彻底崩溃了。

在向 Go 官方提交的 GitHub Issue #77893 中,Uber 工程师贴出了详细的统计数据。他们发现,微服务中的 Goroutine 栈分布并不是均匀的,而是呈现出典型的双峰分布(Bimodal Distribution)

  • 海量的“僵尸”协程:在 Uber 的任意一个实例中,通常会有数千个长时间存活的后台 Goroutine。比如监听配置更新的轮询、阻塞在网络 I/O 上的长连接、或是空闲的 gRPC worker。这些 Goroutine 存活了极长的时间(超过 190 分钟),但它们的栈极浅,通常只有 2KB 到 4KB。
  • 少数的“重装”协程:真正在干活的、处理活跃请求的 Goroutine 数量相对较少,但一旦被触发,它们的栈会迅速膨胀到 16KB 甚至 32KB 以上。

悲剧就此诞生。由于海量的“僵尸协程”疯狂拉低了全局平均值,导致 Go 运行时计算出的平均栈大小永远在 4KB 左右徘徊。结果就是,那些真正需要处理复杂业务的新请求,依然只能以 4KB 悲惨开局,继续遭受 copystack 的毒打。

寻找解药:为什么常规优化方案行不通?

在明确了病因后,Uber 团队开始探索解决方案。

选择 1:Goroutine 池化(Goroutine Pooling)

这是很多高并发框架爱用的伎俩。Uber 内部的 M3 团队就曾使用过这个方案——让一堆固定数量的 Goroutine 常驻内存,任务来了就丢给它们执行。因为常驻协程已经扩容到了最大栈,所以不会再发生拷贝。

放弃原因:这需要对全公司的业务代码进行伤筋动骨的重构。协程池不仅增加了代码复杂度,还引入了 Channel 通信的额外 CPU 开销。如果在高负载下任务堆积,还容易导致系统死锁。

选择 2:手动摸石头过河(Manual Mode)

运维人员手动改代码,给服务分配 4KB 的初始栈,部署上去看 Profile;不行再改成 8KB,再部署……

放弃原因:完全不可扩展。Uber 有上千个微服务,靠人力试错无异于天方夜谭。

常规手段全部碰壁,Uber 的基础架构狂人们决定直接向 Go 运行时的底层规则发起挑战。

暴力美学:用黑魔法强改 Go 运行时变量

既然运行时的全局平均算法被后台“僵尸任务”带偏了,那我们就强行接管它!

然而,Go 官方并没有提供任何可以修改初始栈大小的公共 API(这是被隐藏在 runtime 包内部的机制)。为了打破这层封印,Uber 工程师动用了 Go 语言的终极黑魔法://go:linkname。

通过 go:linkname 这个编译器指令,Uber 成功绕过了包的可见性限制,强行将自己写的外部函数链接到了 runtime 内部的私有变量上。

同时,通过GODEBUG关闭了官方的自适应扩容和栈收缩逻辑(debug.gcshrinkstackoff = 1)。

这里还有一个插曲:由于滥用 linkname 会破坏语言的安全性,Go 官方在 Go 1.23 版本中严格限制了这一机制的使用。为了维持这个 Hack,Uber 甚至被迫在内部维护了一个对 Go 语言源码的 Patch(补丁),专门放开对 startingStackSize 变量的链接权限。

通过这一通硬核魔改,他们成功为不同的微服务通过配置下发(Runtime Environment Variables)注入了静态的初始栈大小。

这套暴力魔改的效果,堪称震撼:

当他们将某个核心请求链路的初始栈静态固定为 32KB 后:

  • CPU 吸血鬼被秒杀:runtime.copystack 的耗时从惊人的 39.98 秒(9.77%)垂直暴跌至 0.42 秒(0.0047%)
  • 整体算力大减负:整个容器的 CPU 实际消耗量直接下降了近 16%

从图中可见:部署了 32KB 静态栈补丁后,黄线(上周)与绿线(本周)的对比,CPU 使用率出现了明显的下降。

代价是什么?仅仅是容器多占用了不到 200MB 的物理内存(对于拥有 16GB 内存的微服务节点来说,这不到 2% 的内存开销简直是白送)。这就是系统级工程中典型的“空间换时间”神之一手。

全局扩展:自研汇编解析器,实现智能化预测

让一个服务吃上 32KB 很容易,但如何自动化地推断 Uber 旗下数百个微服务究竟需要多大的栈?

Uber 团队给出了一份教科书级别的“自动化性能反馈回路(Feedback Loop)”方案:

Uber 设计的自动化调整架构。从生产环境拉取 Profile -> 筛选出触发扩容的函数 -> 获取带符号表的二进制文件 -> 逆向反汇编计算栈大小 -> 将最优配置下发给微服务。

这里的技术难点在于:Profile 只能告诉你哪个函数触发了扩容,但它没法告诉你这个函数到底需要多大的内存。

Uber 的做法简直硬核到了极点:反汇编(Disassembly)。

他们编写了一个自动化工具,使用 Go 原生的 debug/elf 库解析带有符号表的二进制文件,找到那个罪魁祸首的函数,然后直接读取它的底层汇编指令!

在 x86 汇编中,函数在进入时会通过减小栈指针寄存器(RSP)来分配当前函数所需的栈帧空间。指令通常长这样:SUB $128, RSP。
Uber 的分析器精准地捕获这条指令,提取出立即数(比如 128 字节),然后沿着 Profile 的调用栈层层累加,最终极其精确地计算出这棵调用树在最深处到底需要多少物理内存!

通过这种“开天眼”般的方式,Uber 为每一个微服务量身定制了最完美的 2的次幂(如 8KB、16KB、32KB)作为静态启动栈,消灭了全公司的大部分的栈扩容内耗。

反哺开源:推动 Go 语言社区的历史性进化

Uber 并没有将这个每年能省下数百万美元的黑科技据为己有。

在验证了方案的巨大威力后,Uber 工程师带着详尽的生产级数据,敲开了 Go 官方 GitHub 的大门(Issue #77893),期望从语言底层寻找一种更优雅、无需魔改代码的终极解法。

这引起了 Go 核心开发团队(如 Keith Randall, thepudds)的高度重视。针对 Uber 揭示的“双峰分布”导致平均值失效的痛点,社区目前正在紧锣密鼓地测试几项革命性的补丁(如 CL 758141, CL 764220):

  1. 剔除“僵尸”协程(Filtering Inactive Goroutines):在计算全局平均栈大小时,直接把那些在过去一两个 GC 周期内完全没动过、一直阻塞在 Select 或 I/O 上的长时协程排除在数学公式之外。
  2. 放弃平均值,改用 P90 算法:不再使用易被极端值影响的平均数(Mean),转而追踪所有新销毁协程栈大小的 P75 或 P90 分位数。
  3. 内存阈值保护:为了防止盲目分配导致 OOM,Go 可能会引入一个软上限:只要预测的较大初始栈带来的额外内存开销,不超过程序总堆(Heap)大小的 1%,就允许新协程以更大的姿态启动。

Uber 工程师在他们的基础服务中测试了 Go 官方仍在 WIP(开发中)的“P90 + 剔除僵尸协程”补丁。结果令人振奋:在不写一行魔改代码的情况下,服务的 copystack 成本自动下降了高达 80%!

不出意外的话,在即将到来的 Go 新版本中,全球数以百万计的 Go 开发者,都将免费享受到由 Uber 趟出的这条性能优化之路。

小结:给高阶开发者的三个启示

从 Uber 这次优化战役中,我们应当汲取到系统级优化的深刻智慧:

  1. 没有永恒的银弹(No Silver Bullet):Go 的 2KB 极轻量级并发机制让它在网络编程中大杀四方,但在重度计算和深层中间件调用的微服务中,初始内存过小反而成了 CPU 杀手。理解底层的 tradeoff(空间换时间)是每一位高阶架构师的必修课。
  2. 让 Profiling 成为上帝之眼:如果 Uber 没有建立起常态化、Fleet-wide的 CPU Profiling 机制,这 10% 的算力损耗将永远隐藏在数据中心的嗡嗡作响中,无人知晓。性能优化,永远是数据驱动的。
  3. 敬畏底层,但也敢于重塑底层:遇到语言层面的严重瓶颈,平庸的工程师会说“官方机制就是这样,没办法”;但顶级的极客会直接打开源码,用 go:linkname 强行逆天改命,手撕机器汇编,最后再拿着硬核数据去推动官方修改世界规则。

技术的世界里永远没有绝对的黑盒,有的只是一次又一次在极限边缘的疯狂试探。今天,Uber 帮全球的 Go 开发者点亮了一盏明灯,而在不远的未来,这束光将照亮我们运行在云端的每一行代码。

资料链接:

  • https://www.uber.com/us/en/blog/zero-growth-stack
  • https://github.com/golang/go/issues/77893

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

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

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


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 从 0 开始构建 Agent Harness Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats