Go

标题 Go 并发机制一文通：goroutine、channel、同步/异步与典型场景 副标题 / 摘要 这篇文章把 goroutine、channel、WaitGroup、mutex、context 讲清楚，并用工程场景说明它们如何组合使用，解决“同步/异步”和“队列/执行单元”的常见误解。 目标读者 初学者：刚接触 Go 并发，容易把 goroutine 当成队列。 中级开发者：需要在业务中稳定地使用 worker pool / fan-out / pipeline。 团队负责人：希望形成可执行的并发使用规范。 背景 / 动机 很多 Go 新手会把 goroutine 当成“队列”或“异步”的代名词，导致并发设计混乱： goroutine 是执行单元，而队列是数据结构；同步/异步是调用方式，与 goroutine 本身无关。 如果不厘清这些概念，就很容易出现 goroutine 泄漏、死锁、资源失控。 核心概念 goroutine：轻量级执行单元，类似线程，但调度由 Go runtime 负责。 channel：通信与同步原语，可无缓冲（同步握手）或有缓冲（队列语义）。 WaitGroup：等待一组 goroutine 完成。 mutex/RWMutex：共享内存的互斥访问控制。 context：取消、超时与跨 goroutine 传递控制信号。 同步/异步：是否等待结果返回的调用语义，而不是某个工具本身。 小结表格（快速定位概念边界）： 概念 角色定位 典型用途 易错点 goroutine 执行单元 并发执行任务 泄漏/过量创建 channel 通信/同步 任务队列、流水线 未关闭、阻塞 WaitGroup 汇聚等待 fan-in/收口 Add/Done 不匹配 mutex 共享状态保护 map/缓存 死锁、长时间持锁 context 生命周期控制 超时/取消 没有传递或未检查 A — Algorithm（题目与算法） 主题用通俗话说： Go 并发 = “goroutine 负责跑、channel 负责传、WaitGroup 负责等、context 负责停”。 同步/异步只是“要不要等结果”，并不等于“有没有 goroutine”。 ...

标题 Go 死锁排查 Checklist：从报错到定位的实用手册 副标题 / 摘要 一页式清单，帮助你在看到 all goroutines are asleep - deadlock! 时， 快速定位是哪一类等待造成卡死。 目标读者 初学者：首次遇到 deadlock，不知道从哪下手。 中级开发者：需要可复用的排查流程，缩短定位时间。 团队负责人：希望沉淀成团队规范，避免重复踩坑。 背景 / 动机 死锁往往发生在高并发与多协作场景，复现难、定位慢。 有一份稳定的排查清单，可以把“凭直觉猜”变成“按步骤验证”。 核心概念 deadlock 报错：所有 goroutine 都在等待，程序无法推进。 堆栈定位：栈上出现 <-ch / ch <- / mu.Lock() / wg.Wait()。 依赖闭环：等待关系形成环，导致无人能继续执行。 实践指南 / 步骤 1️⃣ 确认报错与堆栈是否完整 记录 fatal error: all goroutines are asleep - deadlock! 后的完整堆栈。 优先关注 main goroutine 的等待点。 2️⃣ 分类定位阻塞类型 channel：<-ch / ch <- WaitGroup：wg.Wait() Mutex：mu.Lock() / RWMutex 的读写锁等待 3️⃣ 检查等待关系是否闭环 ...

标题 Go 死锁入门：常见场景、排查方法与工程实践 副标题 / 摘要 从 Go 运行时的 deadlock 报错切入，系统讲清死锁的本质、 最常见的触发方式，以及如何在工程中稳定规避。 目标读者 初学者：第一次写 Go 并发代码，对 deadlock 报错感到困惑。 中级开发者：需要建立稳定的并发协作流程，减少线上卡死。 团队负责人：想沉淀一套可执行的并发规范和排查手册。 背景 / 动机 在 Go 里，“死锁（deadlock）”指的是：所有 goroutine 都在等待某个事件发生 （通常是等锁、等 channel、等 WaitGroup），但这个事件永远不会发生。 典型报错是： fatal error: all goroutines are asleep - deadlock! 一旦触发，程序会卡住或直接退出，线上影响极大。 理解死锁的触发机制与排查路径，是 Go 并发开发的必修课。 核心概念 阻塞（Blocking）：goroutine 等待 channel、锁或 WaitGroup，无法继续执行。 无缓冲 channel：发送/接收必须同时发生，否则阻塞。 WaitGroup 计数匹配：Add 的次数必须被 Done 抵消。 Mutex 不可重入：同一 goroutine 里重复 Lock 会自我阻塞。 锁顺序一致：多把锁必须统一获取顺序，避免交叉等待。 常见出现背景（什么时候容易发生） 生产者/消费者启动顺序错位：发送先发生、接收未就绪，常见于任务队列、worker pool。 扇出/扇入未配对：启动了多个 worker，但聚合端没把结果全部读完。 pipeline 未关闭或退出信号缺失：上游结束但下游仍 range 等待。 持锁做阻塞操作：拿着锁去收/发 channel、网络 I/O、或等待另一个锁。 多锁资源交叉持有：两个 goroutine 以不同顺序拿锁，形成循环等待。 为什么会出现（根因归纳） 等待关系闭环：A 等 B，B 等 C，C 等 A，没有外力打破。 同步原语用法不成对：channel 收发未配对、WaitGroup 计数未归零。 协程生命周期不一致：生产者先退出/未 close，消费者无限等。 锁粒度/顺序不清晰：共享资源越多，锁顺序越容易失控。 A — Algorithm（题目与算法） Go 运行时判定死锁的核心逻辑是： 当主 goroutine 在等待，且所有其他 goroutine 也都在等待，并且没有任何事件能 推动程序继续执行，runtime 会直接报错并终止。 ...

XOR 与 RC4：从原理到 Go 实战（含安全替代建议） 副标题 / 摘要 用最少的数学解释 XOR 与 RC4 的工作机制，给出可运行的 Go 示例，并说明 RC4 的安全问题与替代方案。 目标读者 想读懂遗留 RC4 代码的后端工程师 想区分“编码”与“加密”的初学者 需要建立流密码心智模型的中级开发者 背景 / 动机 很多系统仍遗留 RC4 或“自研解密”的逻辑。常见误区是把 Base64 当作加密，或忽视“完整性校验”。理解 XOR 与 RC4，有助于正确评估安全性，并避免把旧方案复制到新系统。 核心概念 XOR（异或）：按位运算，可逆 流密码：用伪随机密钥流与明文逐字节 XOR RC4：经典流密码，但已不推荐 Base64：编码，不是加密 完整性：仅加密不等于防篡改 实践指南 / 步骤 接收 Base64 字符串（通常是 RC4 输出） Base64 解码得到原始字节 用共享密钥初始化 RC4 将密钥流与字节逐字节 XOR 把输出按 UTF-8 转为字符串（若是文本） 可运行示例（Go） package main import ( "crypto/rc4" "encoding/base64" "fmt" ) func rc4XOR(key string, data []byte) ([]byte, error) { c, err := rc4.NewCipher([]byte(key)) if err != nil { return nil, err } out := make([]byte, len(data)) c.XORKeyStream(out, data) return out, nil } func encryptToBase64RC4(key, plaintext string) (string, error) { out, err := rc4XOR(key, []byte(plaintext)) if err != nil { return "", err } return base64.StdEncoding.EncodeToString(out), nil } func decryptBase64RC4(key, encoded string) (string, error) { raw, err := base64.StdEncoding.DecodeString(encoded) if err != nil { return "", err } out, err := rc4XOR(key, raw) if err != nil { return "", err } return string(out), nil } func main() { key := "demo-key" plaintext := "hello rc4" enc, _ := encryptToBase64RC4(key, plaintext) dec, _ := decryptBase64RC4(key, enc) fmt.Println(enc) fmt.Println(dec) } 运行： ...