//go:nosplit 是栈检查移除器而非扩容开关，禁用 CMP SP 检查但不改变 2KB 初始栈，超限即 fatal error；仅适用于 runtime 极简函数、汇编叶子函数及中断入口三类确定性场景。
//go:nosplit 不是栈扩容开关，而是栈检查移除器
加了 //go:nosplit 后函数仍会 panic: stack overflow，这不是 bug，是设计使然。它不改变 Goroutine 初始栈大小（2KB），也不触发栈扩容逻辑，只是跳过 runtime.morestack 调用前的 CMP SP, stackguard0 检查。
一旦当前栈剩余空间（含 guard 区）不足以容纳函数帧，CPU 直接访问非法地址，运行时 fatal error —— traceback 里甚至看不到调用链，因为栈指针早已错位。
- 常见误踩点：
var buf [8192]byte声明即占栈，哪怕没读写；闭包捕获大结构体导致隐式栈增长 - 调用
fmt.Sprintf、append、任何带逃逸或堆分配的操作，都会立刻崩溃 - cgo 边界调用完全不受控：C 函数用系统栈，Go 运行时无法干预，混用极易 panic
哪些函数真能用 //go:nosplit？三类且仅三类
它不是性能优化指令，而是 runtime 底层代码的“确定性执行隔离区”。普通业务代码加了基本等于埋雷。
-
runtime包内极短路径函数：如atomicload64、gogo、morestack自身——必须在不扩容前提下完成上下文切换或原子操作 - 汇编实现的叶子函数：如 Plan9 汇编写的
·memmove，全程无函数调用、无局部大变量、无逃逸 - 中断/信号处理入口（极少数嵌入式或 OS-like 场景）：要求执行时间严格可控，不能被栈搬家打断
注意：//go:nosplit 函数里调用任何 Go 标准库函数（哪怕只是 len() 或 cap()）都可能隐含逃逸或栈检查，风险极高。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
怎么验证你写的 //go:nosplit 函数是否安全？
不能靠跑通测试，得看编译器生成的栈帧大小和实际调用行为。
- 用
go tool compile -S yourfile.go查看汇编输出，找text ·funcname(sb), nosplit, $N中的$N—— 这是编译器计算出的栈帧字节数 - 确保
$N < 2048（2KB），并留出至少 256 字节 guard 区余量 - 用
go tool objdump -s funcname binary确认没有call指令指向非nosplit函数（尤其是 runtime 内部函数） - 禁用内联：
//go:noinline+//go:nosplit组合可防止编译器把 unsafe 代码塞进其他函数里
和其他 //go: 指令混用时的关键约束
//go:nosplit 是最危险的编译器指令之一，与其他指令组合时边界极窄。
-
//go:noescape可配对使用（如memmove），但前提是参数确实不逃逸、不触发堆分配；若声明错误，panic 位置会远离问题源 -
//go:norace可以加，但竞态检测关闭 ≠ 线程安全 ——//go:nosplit函数若操作共享状态，崩溃更难定位 -
//go:noinline强烈建议配合使用，避免被内联到非nosplit上下文中，导致栈检查意外恢复 - 绝对不要和
//go:nowritebarrierrec等 GC 相关指令随意组合，写屏障缺失 + 栈不可扩容 = 极高概率内存踩踏
真正难调试的从来不是 panic 本身，而是 panic 发生时栈指针已失效、寄存器被覆盖、traceback 失效——这时候你得靠 go tool compile -S 和汇编级分析，而不是日志或断点。
