Go中并发≠并行：并发是程序能同时处理多任务的设计模型，单核即可实现；并行是多核上真正同时执行指令的运行时现象。需用go tool trace、GODEBUG或top验证实际调度。
Go 语言里，“并发”不是“并行”，这是新手最容易卡住的第一道坎。理解错这点，后面写 goroutine、调 runtime.GOMAXPROCS、甚至用 sync.WaitGroup 都会跑偏。
并发 ≠ 并行：单核也能“并发”，但必须多核才“并行”
并发是程序设计模型——它关心“能不能同时处理多个任务”；并行是运行时现象——它关心“是不是真正在多个 CPU 核心上同时跑指令”。
- 一个
goroutine在单核 CPU 上休眠、等待 I/O、让出时间片，其他goroutine被调度执行，这就是并发（宏观并行，微观串行） - 只有当 Go 运行时把多个
goroutine分配到不同 OS 线程，并且这些线程被操作系统真正调度到不同物理核心上运行时，才构成并行 -
runtime.NumCPU()返回的是逻辑核心数，runtime.GOMAXPROCS(n)设置的是可同时执行的 OS 线程上限，但它不保证并行——如果只启了 1 个goroutine，哪怕设成 8 也没用
怎么验证自己写的是并发还是并行？
别靠猜，用工具看真实调度行为：
- 加
go tool trace：运行go run -gcflags="-l" main.go && go tool trace trace.out
，在浏览器打开后点 “Goroutines” 和 “Threads”，能清楚看到 goroutine 切换和 OS 线程绑定情况 - 观察
GODEBUG=schedtrace=1000输出：每秒打印调度器状态，其中M: N表示当前有 N 个 OS 线程（M），G: X是活跃 goroutine 数，若M长期为 1 但G很大，说明是高并发低并行 - 用
top -H -p $(pidof your_program)（Linux）看实际线程数，再对比runtime.GOMAXPROCS()值——不一致就说明调度没打满
新手最常踩的三个坑
不是语法不会，而是模型没对齐：
立即学习“go语言免费学习笔记（深入）”；
-
以为
go f()就自动并行了：其实只是启动 goroutine，是否并行取决于有没有空闲 M、有没有阻塞、有没有 CPU 密集型任务争抢。纯计算任务不加runtime.GOMAXPROCS(runtime.NumCPU())，默认可能只用 1 个核心 -
共享变量不加保护就乱改：并发安全≠线程安全。Go 不阻止你直接读写全局变量，但
shared++这种操作在多个 goroutine 里就是竞态——用sync.Mutex或atomic.AddInt64，别依赖“好像没出错” -
channel 关闭后还往里塞数据：会 panic：
send on closed channel。关闭前确认所有 sender 已退出，或用select+default避免死锁；更稳妥的是用sync.WaitGroup控制生命周期，而不是靠 channel 关闭信号
真正难的不是写多少个 go，而是判断哪些任务该并发（比如 I/O 等待）、哪些该并行（比如矩阵分块计算）、哪些根本不能并发（比如顺序写日志）。模型想清楚了，goroutine 和 channel 才不会变成新包袱。
