windows 下 getthreadstacklimits 仅适用于当前线程，返回栈底（lowlimit）和栈顶（highlimit），结合 rsp/esp 可估算剩余空间，但需注意编译环境（winver≥0x0601）、参数为输出地址、不可跨线程调用，且实际可用空间小于计算值。
Windows 下用 GetThreadStackLimits 获取当前线程堆栈边界
Windows 不提供直接返回“剩余字节数”的 API，但能拿到当前线程的栈底（LowLimit）和栈顶（HighLimit），再结合当前栈指针（rsp 或 esp）就能算出已用/剩余空间。关键在于：必须在目标线程上下文中调用，跨线程读取无意义。
常见错误是在线程 A 中试图查线程 B 的栈限——GetThreadStackLimits 只对调用者自身有效，且仅支持当前线程（文档明确标注 “This function only works for the calling thread”）。
- 使用前需确认编译环境支持：
WINVER >= 0x0601（即 Windows 7+），头文件为processthreadsapi.h - 函数原型为
VOID GetThreadStackLimits(PULONG_PTR LowLimit, PULONG_PTR HighLimit)，注意参数是输出地址，不是返回值 - 计算剩余空间时，用
HighLimit - current_rsp（x64）或HighLimit - current_esp（x86），不能反着减，否则结果为负 - 实际可用空间比计算值略小，因编译器可能预留 guard page、函数调用帧开销未计入，建议留至少 4KB 缓冲
Linux 下通过 pthread_getattr_np + pthread_attr_getstack 查栈范围
Linux 没有等价于 Windows 的单点查询 API，得靠 pthread 非标准扩展获取线程属性，再从中提取栈起始地址与大小。注意：_np 后缀表示“non-portable”，glibc 支持，musl 不支持，跨平台项目慎用。
典型错误是忽略 pthread_attr_init 后未调用 pthread_attr_destroy，导致内存泄漏；或误以为 stackaddr 是栈顶——它其实是栈的**最低地址**（栈向下增长），所以剩余空间 = stacksize - ((char*)current_sp - (char*)stackaddr)。
- 必须用
pthread_getattr_np(pthread_self(), &attr)获取当前线程属性，传入其他线程 ID 会失败 -
pthread_attr_getstack(&attr, &stackaddr, &stacksize)返回的stackaddr是栈底（低地址），不是栈顶 - 获取当前栈指针推荐用内联汇编：
__builtin_frame_address(0)比直接读rsp更安全，兼容优化场景 - 主线程栈（main thread）不走 pthread 创建流程，其栈信息无法用此法获取，需改用
/proc/self/maps解析
跨平台可移植方案：依赖编译器内置函数与栈探针
真正可移植的“剩余栈空间”查询不存在。C++ 标准不定义栈布局，各平台 ABI 差异大。若需运行时防栈溢出，应转向主动防御策略，而非被动查询。
常见误区是试图封装一个统一接口，在 Windows 调 GetThreadStackLimits，Linux 调 pthread_getattr_np——这掩盖了语义差异：前者只对当前线程有效，后者需手动管理 attr 对象，且 musl 等 libc 完全不支持。
- 推荐用
__builtin_frame_address(0)（GCC/Clang）或_AddressOfReturnAddress()（MSVC）获取当前帧地址，作为基准点 - 对深度递归或大栈分配场景，在关键入口处插入栈探针（stack probe）：分配前先访问距当前指针 N 字节处的内存，触发缺页异常捕获（需配合 SEH/signal handler）
- 更实用的做法是限制递归深度、用堆代替大栈数组（如
std::vector替int arr[10000]），而非实时监控剩余量 - 若必须估算，可设保守阈值（如 8KB），在每次函数入口检查
current_sp与已知栈底差值，超阈则拒绝执行
调试阶段用 __chkstk 和编译器选项辅助定位栈耗尽点
运行时查剩余空间意义有限，真正有价值的是在栈溢出发生前预警。MSVC 的 /GS、GCC 的 -fstack-check 或 Clang 的 -fsanitize=stack 能在栈分配时插入检查，但性能损耗明显，仅适合调试。
容易被忽略的是：这些机制只拦截显式栈分配（如大数组、alloca），对无限递归无效。而 __chkstk（Windows）或 __stack_chk_fail（GCC）崩溃时的调用栈，往往已丢失原始溢出点。
- 启用
-fstack-protector-strong（GCC/Clang）可对局部变量加 canary，溢出时快速 abort，比查剩余空间更可靠 - MSVC 下开启
/RTCs（栈帧运行时检查）会在 debug 模式下自动插入栈边界验证，但 release 模式默认关闭 - 生产环境建议关闭所有栈检查选项，改用静态分析（如 clang++
-Wstack-protector）提前发现风险函数 - 若用 ASan，注意它会大幅增加栈用量（每个函数帧额外几百字节），反而可能诱发假阳性溢出
栈空间不是内存池，没有“剩余量”这个稳定可观测的状态。所谓查询，本质是拿当前栈指针和某个理论边界做减法，而边界本身受编译器、链接器、OS 分配策略共同影响。最易被忽略的一点：即使算出还有 16KB 剩余，一次 alloca(20KB) 仍会立即崩溃——因为栈是连续区域，不支持碎片化分配。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
