Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feedertonybai.com
Tony Bai
Get the latest updates from Tony Bai directly as they happen.
Follow now 24 followers
Latest posts
Last updated about 4 hours ago
GitHub英语沟通太难？别让语言成为你参与顶级Go项目的拦路虎！
about 5 hours ago
本文永久链接 – https://tonybai.com/2025/05/09/github-english-communication-patterns-and-practice 大家好，我是 Tony Bai。 身处全球化的软件开发浪潮中，GitHub早已成为我们协作、学习、贡献的“宇宙中心”。但对于我们许多非英语母语的开发者来说，它既是机遇之地，有时也是“望而却步”的挑战场。 你是否也曾有过这样的经历？ 面对一个棘手的 Bug，想在golang/go项目的 Issue 下寻求帮助，却因为担心自己的“蹩脚”英文描述不清，反复修改，最终默默关掉了页面？...
Go 1.25链接器提速、执行文件瘦身：DWARF 5调试信息格式升级终落地
1 day ago
本文永久链接 – https://tonybai.com/2025/05/08/go-dwarf5 大家好，我是Tony Bai。 对于许多Go开发者来说，调试信息的格式可能是一个相对底层的细节。然而，这个细节却对编译速度、最终可执行文件的大小以及调试体验有着深远的影响。经过长达六年的讨论、等待生态成熟和密集的开发工作，Go 语言工具链终于在主干分支（预计将包含在 Go 1.25 中）默认启用了 DWARF version...
代码覆盖率新玩法：Russ Cox教你用差异化分析加速Go调试
2 days ago
???文永久链接 – https://tonybai.com/2025/05/07/debug-with-diff-cover 大家好，我是Tony Bai。 调试，尤其是调试并非自己编写的代码，往往是软件开发中最耗时的环节之一。面对一个失败的测试用例和庞大的代码库，如何快速有效地缩小问题范围？Go团队的前技术负责人 Russ Cox 近期分享了一个虽然古老但极其有效的调试技术——差异化覆盖率 (Differential Coverage)。该技术通过比较成功和失败测试用例的代码覆盖率，巧妙地“高亮”出最可能包含Bug的代码区域，从而显著加速调试进程。 在这篇文章中，我们来看一下Russ...
解读“Cheating the Reaper”：在Go中与GC共舞的Arena黑科技
3 days ago
本文永久链接 – https://tonybai.com/2025/05/06/cheating-the-reaper-in-go 大家好，我是Tony Bai。 Go语言以其强大的垃圾回收 (GC) 机制解放了我们这些 Gopher 的心智，让我们能更专注于业务逻辑而非繁琐的内存管理。但你有没有想过，在 Go 这个看似由...
Go新垃圾回收器登场：Green Tea GC如何通过内存感知显著降低CPU开销？
6 days ago
本文永久链接 – https://tonybai.com/2025/05/03/go-green-tea-garbage-collector 大家好，我是Tony Bai。 随着 CPU 核心数量的激增和内存访问速度日益成为瓶颈，现代计算系统对内存局部性（Spatial & Temporal Locality）和拓扑感知（Topology-awareness）提出了更高的要求。然而，传统的垃圾收集（GC）算法，包括 Go...
“错误即值”，不同实现：Go与Zig错误处理哲学对比
9 days ago
本文永久链接 – https://tonybai.com/2025/04/30/go-vs-zig-in-error-handling 大家好，我是Tony Bai。 使用Go语言有些年头的开发者，大多对其错误处理机制有着复杂的情感。一方面，我们认同 Rob Pike 所倡导的“错误即值 (Errors are values)”的核心哲学——错误不是需要特殊通道（如异常）处理的“二等公民”，它们是普通的值，可以传递、检查，甚至被编程。这赋予了错误处理极大的灵活性和明确性。...
Go的简洁神话？转Go前你需要知道的5个“真相”
10 days ago
本文永久链接 – https://tonybai.com/2025/04/29/hard-truths-before-switching-to-go 大家好，我是Tony Bai。 Go 语言近年来势头强劲，凭借其简洁、高效、出色的并发能力和工具链，吸引了大量开发者投身其中。甚至连TypeScript 团队也宣布将其编译器和工具集迁移到 Go，以提升性能。这无疑是对 Go 的巨大认可。 然而，正如一位拥有超过...
Go开发者必知：五大缓存策略详解与选型指南
11 days ago
本文永久链接 – https://tonybai.com/2025/04/28/five-cache-strategies 大家好，我是Tony Bai。 在构建高性能、高可用的后端服务时，缓存几乎是绕不开的话题。无论是为了加速数据访问，还是为了减轻数据库等主数据源的压力，缓存都扮演着至关重要的角色。对于我们 Go 开发者来说，选择并正确地实施缓存策略，是提升应用性能的关键技能之一。 目前业界主流的缓存策略有多种，每种都有其独特的适用场景和优缺点。今天，我们就来探讨其中五种最常见也是最核心的缓存策略：Cache-Aside、Read-Through、Write-Through、Write-Behind (Write-Back) 和Write-Around，并结合Go语言的特点和示例（使用内存缓存和SQLite），帮助大家在实际项目中做出明智的选择。 0...
go-yaml归档背后：Go开源生态的“脆弱”与“韧性”，我们该如何看待？
11 days ago
本文永久链接 – https://tonybai.com/2025/04/28/go-ecosystem 大家好，我是Tony Bai。 最近，Go社区里的一则消息引发了不少关注和讨论：广受欢迎的 go-yaml 库作者 Gustavo Niemeyer 宣布将项目正式标记为“归档(archived)”。这不仅让很多依赖该库的项目需要考虑迁移，也恰好触动了许多 Gopher...
Rob Pike的“抱怨”与Go的“解药”：直面软件膨胀的四大根源
12 days ago
本文永久链接 – https://tonybai.com/2025/04/27/rob-pike-on-bloat 大家好，我???Tony Bai。 今年年初，Go语言之父、UTF-8编码的发明者Rob Pike的一篇题为”On Bloat”（关于膨胀）的演讲幻灯片(在2024年下旬做的)在技术圈，尤其是在Hacker News(以下简称HN)上，引发了相当热烈的讨论。Pike作为业界泰斗，其对当前软件开发中普遍存在的“膨胀”现象的犀利批评，以及对依赖管理、软件分层等问题的深刻担忧，无疑戳中了许多开发者的痛点。 HN上的讨论更是五花八门，开发者们纷纷从自身经历出发，探讨“膨胀”的定义、成因和后果。有人认为膨胀是“层层叠加的间接性”导致简单修改寸步难行；有人认为是“不必要的功能堆砌”；还有人归咎于“失控的依赖树”和“缺乏纪律的开发文化”。 那么，Rob Pike究竟在“抱怨”什么？他指出的软件膨胀根源有哪些？而作为我们Gopher，Go语言的设计哲学和工具链，能否为我们从纯技术层面提供对抗膨胀的“解药”呢？今天，我们就结合Pike的演讲精髓和HN的热议，深入聊聊软件膨胀的四大根源，并从Go的视角尝试寻找一下应对之道。...
【规律之手】资深码农都懂？软件工程中的13条“潜规则”定律
13 days ago
本文永久链接 – https://tonybai.com/2025/04/26/13-laws-of-software-engineering 大家好，我是Tony Bai。 做软件开发时间越长，越觉得背后似乎有只“无形的手”在影响着项目进度、团队协作、系统架构甚至技术决策。有些现象反复出现，从早期的一头雾水，到后来的似曾相识，再到最后的会心一笑（或许是苦笑），让人不得不感慨其中蕴含的某些“规律”。 最近看到国外一位开发者ANTON ZAIDES总结了软件工程领域的13条“定律”。它们中有些广为人知，有些则相对小众，但都非常实用。它们虽然不像物理定律那样严格精确，但确实精准地捕捉到了我们日常工作中经常遇到的挑战和现象，堪称是工程师和管理者都应该了解的宝贵“经验法则”或“心智模型”。 今天，就让我们一起来了解和学习一下这13条定律，看看它们是如何在我们身边运作的。 注：下面文中各条定律的配图也借自ANTON ZAIDES的原文章。 1....
一个字符引发的30%性能下降：Go值接收者的隐藏成本与优化
14 days ago
本文永久链接 – https://tonybai.com/2025/04/25/hidden-costs-of-go-value-receiver 大家好，我是Tony Bai。 在软件开发的世界里，细节决定成败，这句话在以简洁著称的Go语言中同样适用，甚至有时会以更出人意料的方式体现出来。 想象一下这个场景：你正在对一个稳定的Go项目进行一次看似无害的“无操作（no-op）”重构，目标只是为了封装一些实现细节，提高代码的可维护性。然而，提交代码后，CI系统却亮起了刺眼的红灯——某个核心基准测试（比如 sysbench）的性能竟然骤降了30%！ （图片来源：Dolt博客原文） 这可不是什么虚构的故事，而是最近发生在Dolt（一个我长期关注的一个Go编写的带版本控制的SQL数据库）项目中的真实“性能血案”。一次旨在改进封装的重构，却意外触发了严重的性能衰退。 经过一番追踪和性能分析（Profiling），罪魁祸首竟然隐藏在代码中一个极其微小的改动里。今天，我们就来解剖这个案例，看看Go语言的内存分配机制，特别是值接收者（Value Receiver），是如何在这个过程中悄无声息地埋下性能地雷的。...