Go 的并发模型不是设计模式，而是语言级执行模型与编程范式；它基于CSP理论，通过goroutine和channel等运行时原语实现，并非可复用的代码组织模板。
Go 的并发模型不是设计模式，而是语言级的执行模型与编程范式。 它不满足“设计模式”的定义——即面向对象语境下、针对常见问题的可复用解决方案模板。Go 的 goroutine 和 channel 是运行时直接支持的原语，不是程序员手动组合的类或接口结构。
为什么说 CSP 不是 Go 里的“设计模式”
CSP（Communicating Sequential Processes）是 Tony Hoare 提出的**并发理论模型**，Go 借鉴并落地为语言机制：每个 goroutine 是一个顺序执行的轻量实体，channel 是它们之间唯一被鼓励的通信方式。这不是“怎么组织代码”的套路，而是“程序该怎么跑”的底层契约。
- 设计模式（如 Observer、Strategy）可被任何语言模拟，不依赖运行时；而
goroutine的调度、channel的阻塞/缓冲行为，由 Go runtime 硬实现 - 你无法用 interface + struct “实现一个 CSP 模式”，但你可以直接写
go f()和ch - Go 官方文档从不称其为“pattern”，而始终称其为 concurrency model 或 programming model
“Do not communicate by sharing memory”到底怎么落地
这句话不是口号，是写法约束。它意味着：一旦你用 sync.Mutex 或 atomic 显式保护共享变量，你就已偏离 CSP 主流路径——不是语法错误，但大概率说明通信编排没想清楚。
- 典型正向做法：把状态封装进一个
goroutine，所有读写都通过channel进入该协程（即 “state owner” 模式） - 反例陷阱：多个 goroutine 同时读写
map并加锁 —— 这本质还是共享内存模型，CSP 优势（无锁、可推演、易测试）全部丢失 - 注意：
channel本身是共享的，但它只负责传递值拷贝或指针，不暴露内部状态；真正共享的是“消息”，不是“内存地址”
什么时候必须跳出 CSP 范式
现实项目中，完全回避共享内存不现实。Go 允许你用，只是不鼓励——关键在识别哪些场景绕不开：
- 高性能计数器（如请求 QPS 统计）：用
atomic.AddInt64比走channel少至少一个内存拷贝和调度开销 - 初始化阶段的全局配置：单次写、多处读，
sync.Once+var conf Config更直白 - 与 C 互操作或零拷贝场景：必须传指针，此时需靠文档+约定明确所有权，而非靠 channel 隔离
这些不是 CSP 的失败，而是它的边界——就像你不该用锤子拧螺丝，也不该用 channel 做原子计数。
新手最容易误解的三个点
很多人学完 goroutine/channel 就以为掌握了 CSP，结果写出一堆隐式耦合代码：
- 用
chan struct{}当信号量但不关闭，导致接收方永久阻塞 —— CSP 要求通信双方对消息生命周期有共识 - 把
channel当成“全局总线”，到处send和recv，失去“顺序进程”的边界感 —— 每个 goroutine 应有清晰输入/输出契约 - 认为“无锁=无竞争”，却忘了
close(ch)和len(ch)本身不是原子的，误用会引发 panic 或竞态
CSP 的难点从来不在语法，而在放弃“我控制一切”的执念——你得信任 channel 的阻塞语义，接受消息到达的时序就是逻辑时序，而不是靠 sleep 或重试去“凑”。
