go协程栈溢出主因是递归过深或局部变量过多，而非初始栈小；其初始栈仅2kb但可动态扩容至默认1gb上限，超限即触发panic。
goroutine 栈溢出不是栈大小设小了，而是函数调用太深或局部变量太多
Go 的 goroutine 初始栈是 2KB，按需增长，上限默认 1GB。但“栈溢出”错误（runtime: goroutine stack exceeds 1000000000-byte limit）往往不是因为栈不够大，而是某个函数内部递归过深、或一次性分配超大局部变量（比如 make([]byte, 100），导致栈帧撑爆。GOMAXPROCS 完全不影响单个 goroutine 的栈大小，它只控制并行 OS 线程数——网上很多教程混淆了这点。
常见错误现象：
- 程序启动不久就 panic，堆栈里反复出现同一函数名（递归未收敛）
- 某次处理大文件或解密长数据时突然崩溃，错误信息带 “stack overflow” 但没递归调用链
- 用
runtime.Stack打印发现单个 goroutine 栈已超 50MB
避免在 goroutine 内部做深度递归或大内存局部分配
递归函数如解析嵌套 JSON、遍历深层树结构，很容易触发栈溢出。Go 不支持尾递归优化，所以不能靠加修饰符解决。
实操建议：
- 把递归改写为显式栈（
stack := []*Node{root}+for len(stack) > 0） - 对大 buffer 分配，别写
data := make([]byte, 10 在函数栈上；改用 <code>data := make([]byte, 10 是堆分配，但若写成 <code>var data [10 就真在栈上炸了 - 用
go tool compile -S检查函数编译后的栈帧大小，超过 8KB 就该警惕
用 pprof 和 runtime.ReadMemStats 定位真实瓶颈
你以为是栈溢出，实际可能是 goroutine 泄漏后堆积了几十万协程，每个都占几 KB 栈，总内存爆了，但报错还是“stack overflow”。这时候光调栈大小没用。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
关键检查点：
- 启动时加
import _ "net/http/pprof"，访问/debug/pprof/goroutine?debug=2看哪些 goroutine 卡在select或 channel receive - 定期调
runtime.ReadMemStats，重点看StackInuse（当前所有 goroutine 栈总占用）和Goroutines数量是否持续上涨 - 如果
StackInuse高但Goroutines数稳定，说明单个 goroutine 确实栈过大；如果两者同步涨，大概率是泄漏
context.WithCancel 无法终止阻塞 I/O，这是最常被忽略的“伪栈溢出”根源
大量 goroutine 卡在 http.DefaultClient.Do(req) 或 conn.Read() 上，既不响应 cancel，也不释放栈。它们不会立刻报栈溢出，但会持续吃内存，最终触发 OOM，而日志里可能只看到模糊的 “fatal error: stack overflow” —— 因为调度器在尝试 dump 大量 goroutine 状态时自己栈也爆了。
必须做的三件事：
- 所有网络调用必须带 context：用
req = req.WithContext(ctx)，客户端设Timeout或用http.Client{Timeout: 5 * time.Second} - 数据库查询、文件读写等阻塞操作，确保驱动支持 context（如
db.QueryContext） - 自定义阻塞逻辑（如轮询、sleep）必须定期检查
ctx.Err() == context.Canceled，不能只依赖 defer cancel
真正难处理的，是那些没有 context 接口的老代码或 Cgo 调用。这种地方要么重构，要么用 runtime/debug.SetTraceback("all") 抓 panic 前的完整栈，否则问题永远在深夜三点复现。
