Go强制goroutine间不直接共享变量，所有数据传递必须经channel；绕过channel操作全局变量或指针即违背CSP范式，易致并发panic；无缓冲channel默认同步阻塞，保障原子有序通信。
“通过通信共享内存”到底在说什么
这不是一句修辞，而是 Go 运行时强制你遵守的约束：goroutine 之间**不直接读写同一块变量**，所有跨 goroutine 的数据流动必须经由 channel。它不是“推荐做法”，而是模型设计的硬性边界——当你绕过 channel 去用全局变量或指针传参修改状态，你就已经脱离 CSP 范式，进入传统多线程陷阱区。
- 典型错误现象：
fatal error: concurrent map writes或随机 panic，尤其在没加sync.Mutex的 map 并发读写中高频出现 - 本质区别：CSP 不是“避免共享”，而是把“共享”这件事交给
channel封装——你看到的是发送/接收动作，底层运行时确保这个动作原子、有序、可阻塞 - 一个直观对比：用
chan int传数字，比用*int指针让多个 goroutine 改同一个值，更安全、更易推理、更少锁
为什么无缓冲 channel 是 CSP 的“默认语气”
声明 make(chan int)（不带缓冲）时，Go 默认启用同步语义：发送会卡住，直到有 goroutine 在另一端 接收；接收也一样。这正是 CSP 中“通信即同步”的体现——你不显式协调，运行时就替你卡住流程，逼你写出顺序清晰的协作逻辑。
- 常见误用：在需要解耦生产/消费节奏时（比如日志批量刷盘），仍死守无缓冲 channel，导致上游 goroutine 频繁阻塞、吞吐骤降
- 缓冲选择不是越大越好：
make(chan int, 1000)看似流畅，但可能掩盖背压缺失问题——下游慢了，消息全堆在 channel 里，内存悄悄涨，最终 OOM - 真正该问的不是“要不要缓冲”，而是“谁该为背压负责”：如果下游必须实时处理，就用无缓冲；如果允许短暂积压且能控量，才加缓冲，并配
len(ch)监控水位
死锁不是 bug，是 CSP 模型在报警
Go runtime 报 fatal error: all goroutines are asleep - deadlock，往往不是代码写错了，而是你画了一张“没人收件、也没人发件”的通信图。CSP 没有超时、没有异步丢弃，默认一切操作都要求两端到场。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 高频场景：只发不收（如忘记
for range ch或漏掉close(ch)）、只收不发（如ch := make(chan int); 却没别的 goroutine 往里塞）、<code>select里没写default又没其他 case 就绪 - 关键修复点：对每个
chan明确它的生命周期——谁 close？谁 range？有没有超时兜底？不要依赖“应该有人来读”这种模糊假设 - 实用技巧：用
select+time.After包一层发送/接收，或者用context.WithTimeout控制整条链路，比硬扛死锁更可控
goroutine 泄漏：CSP 里最隐蔽的资源黑洞
一个启动了却永远卡在 或 <code>ch 的 goroutine，不会报错，但会一直占着栈内存和调度器 slot。它不像内存泄漏那样立刻被 pprof 抓到，而是悄无声息拖垮整个服务的并发能力。
立即学习“go语言免费学习笔记（深入）”；
- 典型模式：启动 goroutine 去监听 channel，但 channel 永远不会关闭（比如忘了
close(done)），或 sender 已退出但 receiver 还在空转for range ch - 排查线索：pprof 的
/debug/pprof/goroutine?debug=2查看堆积的 goroutine 栈，重点盯runtime.gopark后面跟着 channel 操作的位置 - 防御写法：凡是有
go func() { for range ch { ... } }()，必须确保ch会被某处close()；凡是有go func() { ch ，最好包进 <code>select加default或ctx.Done()，防止单向阻塞
CSP 的难点不在语法，而在思维切换——你得习惯把“状态放在哪”变成“消息往哪送”，把“我锁一下变量”变成“我等一个信号”。很多坑，都是因为半只脚还在共享内存里，半只脚踩进 channel 通道。
