Go并发基于goroutine+channel的协作式系统，非多线程模拟；goroutine是运行时管理的轻量单元，初始栈2KB，由GMP调度，非OS线程；需限流防阻塞I/O失控；channel核心是协调时序而非传数据。
Go 的并发编程不是“多线程模拟”，而是用 goroutine + channel 构建的一套可预测、低负担的协作式并发系统——它不靠锁来保安全，靠的是“让数据在协程间流动，而不是让协程争抢同一块内存”。
goroutine 是什么？为什么不能当成“线程”来理解？
goroutine 是 Go 运行时管理的轻量执行单元，初始栈仅 2KB，按需自动扩容；创建开销约 1/1000 个 OS 线程。但它不是线程：OS 线程是内核调度的实体，而 goroutine 永远运行在 M（系统线程）+ P（逻辑处理器）绑定的上下文中，由 Go 调度器（GMP）统一编排。
- 误用场景：用
go f()启动大量阻塞型 I/O（如无超时的http.Get），却不控制并发数 → 可能瞬间创建数万G，但实际只有GOMAXPROCS个 P 可调度，其余排队，内存暴涨且响应迟滞 - 正确做法：配合
sync.WaitGroup或带缓冲的chan struct{}做并发限流，例如限制最多 10 个 HTTP 请求同时进行 - 一个常见错觉：认为
go f(); f()是“并发+同步执行”，其实f()仍跑在主线程，和goroutine无调度关系
channel 不只是管道，它是并发控制的开关
channel 的核心作用不是“传数据”，而是“协调时序”。无缓冲 channel 的发送/接收是双向阻塞操作，天然构成同步点；有缓冲 channel 则提供有限异步能力，但缓冲区满或空时依然会阻塞。
- 典型错误：用
make(chan int, 0)（即无缓冲）往未启动接收方的 channel 发送 → 主 goroutine 永久阻塞，程序 hang 住 - 典型修复：要么先
go func(){ ，要么用select+default做非阻塞尝试，或改用带缓冲的make(chan int, N) - 注意：
close(ch)后仍可读取剩余值，但再写入会 panic: “send on closed channel”；读已关闭的 channel 会立即返回零值 +false
GMP 调度器怎么悄悄帮你扛住 10 万 goroutine？
你写的每个 go f() 都不会直接绑定到 OS 线程，而是先入队到当前 P 的本地运行队列（或全局队列）。M 线程从 P 取 G 执行，若遇到系统调用阻塞，P 会被剥离并交给空闲 M，原 M 完成系统调用后需“抢”回 P 或把 G 放回全局队列——整个过程对用户透明。
立即学习“go语言免费学习笔记（深入）”；
- 关键参数：
GOMAXPROCS默认等于 CPU 核心数，它控制 P 的数量，也间接决定真正能并行的 goroutine 上限（非并发上限） - 性能陷阱：频繁跨 P 抢占（work-stealing）虽保证负载均衡，但会增加 cache miss；若任务极轻（如纯计算无阻塞），过度分拆 goroutine 反而因调度开销降低吞吐
- 调试线索：用
runtime.GOMAXPROCS(n)临时调小，或设置环境变量GODEBUG=schedtrace=1000观察调度延迟
真正难的不是写 go 和 chan，而是判断哪个操作该阻塞、哪个该超时、哪个该取消、哪个该丢弃——并发模型给你自由，但也把时序责任全交还给了你。
