本文永久链接 – https://tonybai.com/2022/07/07/gocn-community-go-book-club-issue2-go-programming-from-beginner-to-master 本文是2022年6月26日我在GoCN社区的Go读书会第二期《Go语言精进之路》直播的文字稿。本文对直播的内容做了重新整理与修订，供喜欢阅读文字的朋友们在收看直播后的揣摩和参考。视频控的童鞋可以关注GoCN公众号和视频号看剪辑后的视频，也可以在B站GopherChina专区下收看视频回放(https://www.bilibili.com/video/BV1p94y1R7jg)。 ...
本文永久链接 – https://tonybai.com/2022/06/12/go-1-19-foresight 美国时间2022年5月7日，Go 1.19版本开发分支进入新特性冻结(freeze)阶段，即只能修Bug，不能再向Go 1.19版本中增加新特性了。由于上一个版本Go 1.18因引入泛型改动较大，推迟了一个月发布，这直接导致了Go 1.19版本的开发周期被缩短。 ...
本文永久链接 – https://tonybai.com/2022/05/17/understand-the-nature-of-go-method-and-how-to-choose-the-correct-receiver-type Go语言虽然不支持经典的面向对象语法元素，比如：类、对象、继承等，但Go语言也有方法（method）。和函数相比，Go语言中的方法在声明形式上仅仅多了一个参数，Go称之为receiver参数，而receiver参数正是方法与类型之间的纽带。 ...
本文永久链接 – https://tonybai.com/2021/08/09/when-variables-captured-by-closures-are-recycled-in-go 1. Go函数闭包 Go语言原生提供了对闭包(closure)的支持。在Go语言中，闭包就是函数字面值。Go规范中是这样诠释闭包的： 函数字面值(function literals)是闭包：它们可以引用其包裹函数(surrounding function)中定义的变量。然后，这些变量在包裹函数和函数字面值之间共享，只要它们可以被访问，它们就会继续存在。 ...
Go内建函数源码，我好像在哪里见过你。 – 佚名 1. 何为Go内建函数 众所周知，Go是最简单的主流编程语言之一，截至Go 1.15版本，Go语言的关键字的规模依旧保持在25个： ...
这篇文章的初衷是想解答知乎上的一位知友提出的问题。没想到完成一种实现后，这个问题居然被删除了。那么既然实现了，就分享出来吧。问题的原文找不到了，问题大致是这样的： 一个程序中存在多个函数调用链都调用了函数D： A1 -> B1 > C1 -> D A2 -> B2 > C2 -> D A3 -> B3 -> C3 -> D ... ... 那么，如果某次函数D被调用时出现了问题，那么怎么知道这个D是哪个函数调用链里的D呢？ 有些gopher可能会说通过Delve在线调试打印函数调用栈可以知晓D的调用链，还有些gopher可能会说通过各个函数中输出的业务日志可以查明出问题的D归属的函数调用链，这些都是可行的思路。 ...
一. 引子 书接上文，在发表了《对一段Go语言代码输出结果的简要分析》一文之后，原问题提出者又有了新问题，这是一个典型Gopher学习Go的历程，想必很多Gopher们，包括我自己都遇到过的。我们先来看看这段代码(来自原问题提出者)： // https://play.golang.org/p/dOUFNj96EIQ package main import "fmt" func main() { var i int = 1 defer fmt.Println("result =>",func() int { return i * 2 }()) i++ } 这里显然有坑！初学者的常规逻辑一般是：defer是在main函数退出后执行，退出前i已经做了+1操作，值变成了2，这样一来defer后的Println应该输出：result => 4 才对！实际输出结果呢？ ...
年后事情实在是多，各种被催进度，于是好长一段时间未更博客了，自责中….。今天蹦出来热热身^0^！ 中午在微博私信中看到一封来自某Gopher的咨询，他贴了一段代码，并表示对代码的输出结果的不解，希望我能帮他分析一下。他的代码如下： ...
近一段时间重读了一些经典书籍，诸如《敏捷软件开发：原则、模式与实践》、 《程序员修炼之道》、《Unix编程艺术》等。这些书中关于如何衡量或评价一个类或函数设计好坏的几个原则(Principle)让人印象深刻。《敏捷软件开发》中谈到了SRP、OCP、DIP; 程序员修炼之道则以DRY、“正交性”为话题展开;《Unix编程艺术》围绕紧凑性、SPOT、分离等阐述作者立场。这么多经典原则，如何学习把握？我们不妨来挖掘一下这些新设计原则背后的本质。 追本溯源，从计算机编程语言的发展历史来看，成熟的结构化程序设计语言(如C语言、Pascal等)要先于成熟的OO设计语言(C++、Java等)出现，那么其成熟的设计理论显然也是要早于后者的。这里就不能不提到经典结构化设计的代表作：《Structured Design: Fundamentals of a Discipline of Computer Program and System Design》，这本书出于1975年(年份来自维基百科，Amazon上卖的是1979年版)。说实话我也没有看过此书原版，不过书中的内容和思想早已被其他后继书籍引用和借鉴，我们在市面上能看到的关于结构化设计方面的书籍，尤其是中文书籍，多照搬了此书内容和思想，所以也算是间接学习到了。 ...
近期在考虑对底层函数库进行一些重构，今天下午花了两个小时考量现有的函数库的接口设计，发现目前函数库的实现存在着一个普遍的问题：与特定的内存分配实现耦合的太紧。 我们的应用是多进程结构的，并使用了共享内存这种最快捷的IPC机制，鉴于此很多同事在实现一些数据结构或者算法时可能只考虑到了我们常见的应用场景-多进程共享，而对非共享内存分配的情况考虑不足。那如何将目前某些库函数实现与内存分配之间的强耦合解开呢？针对这道题我发起了一次mail讨论。 题目再重述一下：“目前底层库中的一些数据结构，比如xx_tree、xx_hash_table等，在它们的实现中都会有“分配内存空间”的需求，现有的实现多是直接调用已有的xx_shm_malloc和xx_shm_free在共享内存上动态申请和释放内存，但实际上有些场合我们并不需要在共享内存上分配内存，进程私有堆上的内存完全可以满足需求。如果让大家考虑修改目前xx_tree的实现或重新设计xx_tree的接口，以达到让xx_tree支持多种内存分配策略的目的，你是如额考虑的，请谈谈你的设计思路。" ...