goroutine 是 Go 运行时调度的用户态并发单元，轻量（初始栈2KB）、切换开销仅20–50ns、按需扩栈、通过 channel 通信、泄漏需 pprof 定位，非免费但远优于 OS 线程。
Go 的 goroutine 不是线程，也不是对 OS 线程的简单封装；它是运行时调度的用户态并发单元，和系统线程（如 pthread）在生命周期、调度方式、资源开销上存在本质差异。
goroutine 切换不陷入内核，线程切换必须上下文切换
OS 线程每次调度都要保存寄存器、切换页表、更新内核调度队列，开销在 1–5μs；goroutine 切换由 Go runtime 在用户态完成，只保存栈指针和 PC，开销仅 20–50 ns。这意味着：当一个 goroutine 因 read 网络 socket 阻塞时，runtime 会自动将它从当前 M（OS 线程）剥离，并唤醒另一个就绪的 G——整个过程不挂起 M，M 可继续跑其他 G。
常见错误现象：
— 误以为 runtime.Gosched() 是“让出 CPU”，其实它只是提示调度器可切换，不保证立即切换；
— 在 select 中写死 default 导致忙等，掩盖了真正阻塞点，反而放大调度压力。
栈大小与增长机制完全不同
每个 OS 线程默认栈固定（Linux x86_64 通常 8MB），不可动态调整；而每个 goroutine 初始栈仅 2KB，按需扩缩容（最大可达几 MB），由 runtime 自动管理。
立即学习“go语言免费学习笔记（深入）”；
使用场景：
— 大量短生命周期任务（如 HTTP handler）用 goroutine 几乎无内存压力；
— 若手动创建百万级 pthread，很快 OOM 或触发系统限制（/proc/sys/kernel/threads-max）；
— goroutine 栈溢出不会崩溃进程，runtime 会 panic 并打印 stack overflow 错误。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
通信模型决定并发安全边界
线程共享地址空间，靠 mutex、rwlock、atomic 等同步原语保护临界区；goroutine 默认不共享内存，推荐通过 channel 传递数据，天然规避多数竞态。
容易踩的坑：
— 用全局变量 + sync.Mutex 模拟 channel 行为，既失去 Go 并发哲学，又易漏锁；
— channel 未关闭就 range，或向已关闭 channel 发送，直接 panic；
— select 中多个 case 同时就绪时随机选择，不能依赖执行顺序。
goroutine 泄漏比线程泄漏更隐蔽
OS 线程泄漏通常表现为 ps -eL | grep yourapp | wc -l 持续上涨；goroutine 泄漏则要靠 pprof 抓取 /debug/pprof/goroutine?debug=2 才能定位阻塞点（比如未读的 channel、死锁的 sync.WaitGroup、忘记 close 的 timer）。
性能影响：
— 千级泄漏 goroutine 可能只占几 MB 内存，但会拖慢 GC 扫描速度；
— runtime 默认限制最大 M 数（GOMAXPROCS 控制 P 数，M 数按需伸缩），但泄漏 G 会持续占用 P 的本地运行队列，导致新任务排队延迟；
— runtime.NumGoroutine() 是唯一轻量探测手段，建议在健康检查接口中暴露。
最常被忽略的是：goroutine 不是免费的。它虽轻，但仍有调度元数据（约 2KB）、栈内存、GC mark 成本；高频创建销毁（比如每毫秒启一个）仍会带来可观压力，此时应考虑复用（worker pool）或改用同步逻辑。
