goroutine 创建开销远小于线程，因其栈初始仅2kb且动态伸缩，而线程栈默认2mb固定分配；go在用户态调度，避免系统调用与内核开销，采用m:n调度模型与work-stealing机制提升并发效率。
goroutine 创建开销为什么比线程小得多
因为 goroutine 的栈初始只有 2KB，且按需动态伸缩；而一个 OS 线程默认栈是 2MB（Linux 下通常如此），固定分配、不可收缩。这意味着：启动 10 万个 goroutine 只需约 200MB 栈内存（实际更少，因多数只用几 KB），而 10 万个线程光栈就吃掉 200GB——根本起不来。
- Go 运行时在用户态管理 goroutine，不触发系统调用；
go func() {}几乎就是一次指针赋值 + 少量元数据写入 - 线程创建必须走
clone()或pthread_create()，涉及内核资源分配、TLB 刷新、寄存器上下文初始化等重量级操作 - goroutine 栈最大可到
1GB，但绝大多数不会涨——递归深度大时自动扩容，用完即缩，没有“为防爆栈预占 2MB”的浪费
调度机制差异直接决定并发上限
goroutine 是 M:N 调度：M 个协程跑在 N 个 OS 线程（P 个逻辑处理器）上，由 Go runtime 自己抢断、迁移、负载均衡；线程是 1:1，完全交给内核调度，频繁的上下文切换（尤其是跨核）会带来显著延迟和缓存失效。
- 当某个 goroutine 阻塞在 I/O（如
net.Conn.Read）时，Go runtime 会自动将其挂起，并把同一线程上的其他 goroutine 切换执行——无需等待系统唤醒 - 线程一旦阻塞（比如
read()系统调用），整个线程就卡住，内核无法替你“切走”它正在做的工作 - Go 的 work-stealing 调度器会让空闲的
P主动从其他P的本地队列或全局队列偷任务，避免 CPU 空转
共享内存 vs 通信：不是语法区别，是并发模型分水岭
线程天然共享进程地址空间，所以必须靠 mutex、rwlock、atomic 等同步原语保护临界区；goroutine 虽然也共享内存，但 Go 的哲学是“不要通过共享内存来通信，而要通过通信来共享内存”，channel 是第一公民。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
sync.Mutex保护 map 并发读写？容易漏锁、死锁、误判临界区边界 - 用
chan int传数据？发送方和接收方天然解耦，背压清晰，panic 时 channel 关闭行为明确 - 注意：
channel不是万能的——高吞吐场景下，无缓冲 channel 的阻塞式收发可能拖慢整体节奏；该用sync.Pool复用对象时别硬扛 GC
goroutine 泄漏比线程泄漏更隐蔽，排查手段完全不同
线程泄漏通常表现为 ps -eLf | grep your_app | wc -l 持续上涨，一眼可见；goroutine 泄漏却可能悄无声息吃光内存或卡死调度器，因为它们不对应任何 OS 资源句柄。
- 用
runtime.NumGoroutine()打点监控，突增或长期不降就是信号 - 导出 goroutine stack：
kill -SIGUSR1 PID（Linux/macOS）或访问/debug/pprof/goroutine?debug=2，重点看大量处于select、chan receive、IO wait却无人唤醒的状态 - 常见坑：忘记
close()channel 导致接收方永久阻塞；for range读未关闭 channel；time.AfterFunc引用外部变量造成 goroutine 持有长生命周期对象
真正难的不是写 go f()，而是判断这个 goroutine 是否会被及时调度、是否持有不该持有的资源、是否在错误的时机被 GC 延迟回收——这些都藏在 runtime 的调度策略和内存管理细节里，没法靠直觉猜出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
