Go并发编程以goroutine+channel重构并发思维：goroutine轻量（2KB栈、纳秒级创建）、由GMP调度；channel用于同步与通信，非共享内存替代，无缓冲需配对阻塞，有缓冲仍保序原子性。
Go 并发编程不是“多线程的另一种写法”，而是用 goroutine + channel 重构了并发的思考方式：你不再操心锁、状态同步、线程生命周期，而是设计数据如何流动。
goroutine 不是线程，别拿 pthread 的经验去猜它
启动一个 goroutine 只需 go f()，但它和操作系统线程（pthread）有本质区别：
- 初始栈仅
2KB，可动态伸缩；系统线程栈通常固定1MB~8MB - 创建/销毁不触发系统调用，开销在纳秒级；
pthread_create是微秒级甚至更高 - 调度由 Go 运行时（GMP 模型）接管，不是内核；一个 OS 线程（
M）可跑成百上千个G - 阻塞系统调用（如
read、accept）不会卡死整个线程，运行时会自动把其他G切到别的M上
常见错误：在循环里无节制启 go handle(req) 却不控制并发数 → 内存暴涨或调度器过载。应配合 semaphore 或带缓冲的 channel 限流。
channel 是通信契约，不是共享内存的替代品
channel 的核心作用是同步 + 数据传递，不是“线程安全的队列”。它的行为由类型和缓冲区决定：
-
make(chan int)：无缓冲，send和recv必须配对阻塞（即“握手”），天然实现同步 -
make(chan int, 10)：有缓冲，发送不阻塞直到满；接收不阻塞直到空；但**仍保证顺序与原子性** - 向已关闭的
channel发送 panic；从已关闭的channel接收返回零值 +false（可用v, ok := 判断） - 永远不要在多个 goroutine 中同时关闭同一个
channel—— 这是典型的竞态源，应由发送方单侧关闭
典型误用：for range ch 在接收端，但发送端未关闭 channel → 永远阻塞。务必确保 sender 明确调用 close(ch)，或用 context 控制生命周期。
select 不是 switch，它是 goroutine 的“等待多路复用器”
select 用来同时监听多个 channel 操作，但它不是轮询，也不保证公平性：
- 所有
case的 channel 操作必须是**非阻塞准备就绪**状态，否则该case被跳过 - 多个
case同时就绪时，Go 运行时**随机选择一个**（不是 FIFO），不可依赖顺序 - 加
default可实现非阻塞尝试；不加default且所有case阻塞，则当前 goroutine 挂起 - 不能在
select里直接调用函数（如case ch ），因为compute()会在 select 判定前执行，破坏语义
实用技巧：用 select + time.After 实现超时，但注意 time.After 创建的是单次定时器，高频场景建议复用 time.NewTimer 并 Reset。
context 不是“传参工具”，它是 goroutine 生命周期的总控开关
context.Context 的唯一正统用途是**取消传播与截止时间控制**，不是用来塞业务参数（那是 anti-pattern）：
-
context.WithCancel：手动触发取消，适合用户中断、任务终止等显式信号 -
context.WithTimeout/context.WithDeadline：自动在超时后关闭Done()channel，下游 goroutine 应监听并退出 -
context.WithValue仅限传递**请求范围的、不可变的元数据**（如request-id,user-id），绝不传结构体指针或可变对象 - 所有 I/O 操作（
http.Client.Do、database/sql.QueryContext）都支持context，不传等于放弃超时/取消能力
最容易被忽略的一点：goroutine 启动时若没把 ctx 传进去，或者传了却没在关键路径上检查 ctx.Err()，那这个 goroutine 就成了“幽灵协程”——无法被优雅终止，最终导致泄露。
