加 //go:nosplit 后仍会 panic: stack overflow，因其禁用栈分裂检查但不扩容栈，初始2KB栈超限即崩溃；仅适用于 runtime 底层极简函数、汇编实现及中断处理等确定性场景。
//go:nosplit 禁用栈分裂检查，但不等于“无限栈”——它只是跳过 runtime.morestack 调用，把栈溢出风险直接交给开发者承担。
为什么加了 //go:nosplit 还会 panic: stack overflow
加 //go:nosplit 后函数不再插入 CMP SP, stackguard0 检查，但 Goroutine 初始栈仍是固定大小（2KB），且扩容机制完全失效。一旦函数帧所需空间超过当前剩余栈（含 guard 区），运行时直接 fatal error，不尝试搬家。
- 常见触发点：函数内声明
var buf [8192]byte，哪怕没用到，编译器已按需预留栈空间 - 闭包捕获大结构体、递归调用链深、或在
//go:nosplit函数里调用fmt.Sprintf等堆分配函数，都会立刻崩溃 - cgo 边界调用不受控：C 函数使用系统栈，Go 运行时无法干预，混用时极易因栈指针错位 panic
//go:nosplit 的真实适用场景只有三类
它不是性能优化开关，而是运行时底层代码的“安全隔离区”。普通业务代码几乎不该用。
- runtime 包内极短路径函数，如
atomicload64、gogo、morestack自身——这些函数必须在栈不扩容前提下完成上下文切换或原子操作 - 汇编实现的底层函数，如 Plan9 汇编写的
·memmove，全程无函数调用、无局部大变量、无逃逸 - 中断/信号处理入口（极少数嵌入式或 OS-like 场景），要求确定性执行时间，不能被栈搬家打断
和内核栈限制的关系其实很浅
Go 本身没有“内核栈”概念。所谓“内核栈限制”常被误用于描述两类东西：
- Goroutine 栈上限（默认 1GB）是用户态软限制，由
runtime.stackalloc控制，和//go:nosplit无关 - 真正意义上的内核栈（如 Linux 的 16KB per thread）只影响 cgo 调用中的 C 函数——Go 不管理它，
//go:nosplit也管不了 - 如果你在写类似
os/user或 syscall 封装，误以为加//go:nosplit能绕过内核栈限制，那是错的；该 panic 还是会 panic，只是错误信息变成runtime: goroutine stack exceeds 1000000000-byte limit而非signal SIGSEGV
真正难处理的是：//go:nosplit 函数一旦调用链中混入任何可能触发栈检查或堆分配的操作，panic 位置往往远离实际问题点——因为检查被跳过了，错误表现是栈指针非法或内存踩踏，调试时得靠 go tool compile -S 看汇编帧大小，而不是看 panic traceback。
