go的goroutine和channel是单机并发基础构件，真正落地分布式系统需理解何时弃用channel、放弃goroutine自调度，并对齐本地并发与跨节点一致性。
goroutine 和 channel 不是“学完就能写分布式系统”的工具，它们只是基础通信构件。真正决定你能不能落地分布式系统的，是你是否理解**何时不该用 channel、何时必须放弃 goroutine 自调度、以及怎么让本地并发模型和跨节点一致性对齐**。
什么时候该用 chan int，而不是 chan struct{} 或 chan bool
类型选择不是风格问题，而是语义和内存行为问题。用 chan int 传递信号，会多分配 8 字节（64 位平台），还可能掩盖你本意是“通知”而非“传值”。
- 仅用于同步通知（如“任务完成”）：优先用
chan struct{}—— 零大小，语义清晰，GC 压力最小 - 需要区分多种状态（如 success/fail/time-out）：用带枚举字段的结构体，别靠
bool或 magic int - 缓冲区容量设为 1 就够用时，别写
make(chan int, 100)—— 多余缓冲会延迟阻塞判断，掩盖背压问题
sync.Mutex 在微服务里基本没用，但很多人还在用
你在单机服务里加 sync.Mutex 保护一个 map，没问题；但一旦拆成多个实例，这个锁就彻底失效——它只在当前进程内有效。
- 跨实例共享状态（如库存扣减、订单号生成）：必须用分布式锁（如 Redis + Lua 或 etcd 的 Lease + CompareAndSwap）
- 本地缓存更新冲突：可用
sync.RWMutex+atomic控制 reload 触发，但要配合版本号或 TTL，不能只靠锁 - 误用典型：把 gRPC handler 里所有 DB 查询都包进同一个
Mutex.Lock()—— 直接把并发吞吐压到串行水平
context.Context 不是“加个参数就行”，它得和 goroutine 生命周期对齐
常见错误是：启动 goroutine 时不传 context，或者传了 context.Background() 后再也没检查 Done()。结果就是超时或取消信号永远收不到，goroutine 泄漏。
- 所有可能阻塞的操作（HTTP 调用、DB 查询、
time.Sleep、channel receive）前，必须先select等待ctx.Done() - 子
goroutine必须用context.WithCancel或context.WithTimeout衍生新 context，不能复用父 context 的 Deadline - 不要在
defer里调cancel()后还继续用该 context —— cancel 后ctx.Err()永远返回非 nil，后续操作会立即失败
分布式任务调度里，time.Ticker 是个危险信号
你在本地用 time.Ticker 每 5 秒拉一次配置，没问题；但放到 k8s 多副本里，所有实例同时触发，就变成“分布式毛刺”。这不是并发问题，是协调缺失。
- 定时任务跨实例唯一执行：必须依赖外部协调器（如 Quartz + DB 锁、Temporal、或自研基于 etcd leader election）
-
time.Ticker只适合单实例内部节奏控制（如连接池健康检查、本地指标 flush） - 如果硬要用 Ticker 做“伪分布式”：至少加上随机 jitter（比如
time.After(time.Duration(rand.Int63n(1e9)))），避免雪崩式重试
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
