go进阶

go 提供一种 panic-recover 模式用于处理程序的异常，这和其他语言的采用的 Exception 机制类似。但也不太一样，使用时需要小心。 核心点：panic 是基于goroutine级别

官方提供的 `error` 实在是无力吐槽，虽然从 `1.13` 提供了一个 `Wrap` 和 `UnWrap` 方式，但是还是无法满足我们日常开发的需求。所以我们不得不对它进行二次封装。今天和大家分

最近在项目开发中使用了下 go 1.18 的 workspace 新特性，有一些实操的感受分享给大家。正好最近的 goland 2022.3 也同步支持了 workspace 特性，所以这也激发了我在

swig 对于写 C/C++ 的同学来说并不陌生，它是一个开发工具，用以把当前的C/C++项目和其他高层次语言连接起来，直白的说就是：可以生成供其他语言调用的api 接口代码。那么对于Go的项目来说，

使用Go调用C库，往往比使用C调用Go的动态库更为常见(上一篇文章)。之所以很过公共库是由底层类似C语言来封装，由上层应用层语言来调用，要么是性能的瓶颈；要么是降低公共服务的维护成本，尤其是在一家大型

在 Go 语言中，使用 cgo 无非就两种主要场景：一种是 Go 生成动态库so文件（或静态文件），供其他语言如c来使用；另一种是使用 C 语言封装动态库，供 Go 调用。接下来...

Go属于静态编译类型语言，但有时候我们希望在线上系统中能给业务方开放更多干预服务逻辑的能力，但又不想完全开放整个系统能力。这时候让我想到了 Go 是否可以使用插件机制动态加载代码Go代码，下面总结了

Go使用GPM模型来实现goroutine调度，Go在启动的时候会自动获取系统cpu可用的数量来设置P这个值，那么你是否知道：Go是如何获取当前系统可用的cpu数量呢? “好奇心害死猫”，我也想知道