概述 在goroutine的应用中，有些经典场景如：超时控制、派生goroutine管理、通用上下文传递等，因此官方在1.7版本引入了context库来提供便捷的解决方案。

概述 根据官网对defer的描述， defer func()的存储结构是栈，即LIFO，有多次defer调用时遵循后进先出的逻辑进行执行 而go中return的逻辑如下 先将返回值赋值 执行 defer 栈 返回调用函数 举个栗子 123456789func demo() (res int) { for i := 1; i < 4; i++ { de

问题今天在使用 github.com/spf13/viper 加载配置文件时突然发现有几个字段的值始终无法正常加载，大致形如 12345678910111213141516type Config struct { Name string `yaml:"name"` UserId int `yaml:"user_id"`}func

有以下名为 Server 的类型。 1234type Server struct { Port int Protocol string} 构造器 123456func NewServer(port int, protocol string) *Server{ return &Server{ Port: port, Protocol:

今天看代码的时候，遇到一段： 1234567891011type keyType struct{}var ctxKey = keyType{}func FromContext(ctx context.Context) (OrgUser, error) { if orgUser, ok := ctx.Value(ctxKey).(OrgUser);

今天看context的代码时，发现了一个这样的写法 123456789101112131415type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{} Err() error Value(key any) any}type valu

问题 最近发现自动化任务里的网易云音乐私有文件(ncm)不能直接备份为公共文件格式(flac、aac、mp3等)。 现象分析 把之前yoki123的ncmdump项目打开debug发现应该是做convention时出现了字段不匹配的问题。 解析ncm的meta信息可得 123456789101112131415161718192021{ "musicId"

概述 在源码中channel的数据结构大体如下： 1234567891011121314151617181920212223242526type hchan struct { // chan 里元素数量 qcount uint // chan 底层循环数组的长度 dataqsiz uint // 指向底层循环数组的指针 // 只针对有缓冲的 channel buf un

概述 G — 表示 Goroutine，它是一个待执行的任务； M — 表示操作系统线程，它由操作系统的调度器调度和管理，实际承载goroutine的运行； P — 表示逻辑处理器，它可以被看做运行在线程上的本地调度器。 M:N模型 Runtime 会在程序启动的时候，创建 M 个线程（CPU 执行调度的单位），之后创建的 N 个 goroutine 都会依附在这 M 个线程上执行。

概述 红黑树是一种自平衡二叉搜索树 (任意节点的左子树的值均小于该节点，任意节点右子树的值均大于该节点，在插入删除节点后自动调整树的结构保证树的高度平衡，即任意节点的左右子树高度差不大于1) , 红黑树的节点会有颜色区分，不是红色就是黑色。 叶子结点*(没有子结点的节点)*、根结点、空节点为黑色 红色结点的子结点为黑色 任意节点到叶子结点所有路径上的黑色结点数目一致 操作 旋转 为保证