getrlimit(RLIMIT_STACK, &rlim)获取的是进程级默认线程栈软限制（单位字节），非当前线程已用栈大小；rlim.rlim_cur表示最大可用栈空间，超限触发SIGSEGV，不反映实时占用。
Linux 下用 getrlimit 查看栈大小限制
系统对每个线程栈的默认分配大小，实际由进程的 RLIMIT_STACK 资源限制决定，而非编译器或 C++ 标准规定。主线程栈大小受此限制约束，新线程（如 std::thread 创建的）通常也继承该值，但具体取决于 pthread 实现和创建时是否显式指定栈空间。
直接读取当前限制最可靠的方式是调用 getrlimit：
#include <sys/resource.h>
#include <iostream>
rlimit rl;
if (getrlimit(RLIMIT_STACK, &rl) == 0) {
std::cout << "Stack soft limit: " << rl.rlim_cur << " bytes\n";
}
注意：rl.rlim_cur 是软限制（单位字节），多数 Linux 发行版默认为 8388608（8 MiB）。该值影响 pthread_create 在未指定 attr.stacksize 时的行为。
Windows 下没有统一的“默认栈大小”概念
Windows 不通过资源限制机制管理线程栈，而是依赖可执行文件头中的 SizeOfStackReserve 字段（链接时设定），以及 CreateThread 的 dwStackSize 参数。主线程栈大小由 PE 文件头决定（VC++ 默认 1 MiB），而 std::thread 在 MSVC 中底层调用 CreateThread，若未传栈大小，则使用 0 —— 此时系统按主线程栈大小分配，但不保证一致。
立即学习“C++免费学习笔记（深入）”；
无法在运行时跨进程/跨工具链可靠获取该值，唯一可行路径是：
- 查当前模块的 PE 头：用
ImageNtHeader+OptionalHeader.SizeOfStackReserve - 或用 Windows API
GetThreadContext结合栈指针粗略估算（不可靠，仅作参考）
实践中，Windows 用户应主动控制线程栈：MSVC 提供 /STACK:reserve[,commit] 链接器选项，C++ 侧可用 std::thread 构造前手动调用 SetThreadStackGuarantee（仅影响后续线程）。
std::thread 不暴露栈大小，别试图从它反推
标准 C++ 没有提供任何接口查询某个 std::thread 对象的栈信息。std::thread::id 或句柄本身不含栈元数据；std::this_thread::get_id() 更不能用于推导内存布局。
常见误操作包括：
- 用
&some_local_var和栈顶地址差值估算——失败率高，因编译器可能优化掉变量、插入填充、或启用栈保护（-fstack-protector） - 依赖
pthread_getattr_np获取属性后读stacksize——该函数非 POSIX 标准，glibc 版本间行为不一，且对std::thread创建的线程不一定返回创建时真实值
若需精确控制，请始终显式传入 pthread_attr_t（Linux）或 dwStackSize（Windows），不要依赖“默认”。
为什么不能只看 ulimit -s 就认为万事大吉
ulimit -s 显示的是 shell 当前的 RLIMIT_STACK 值，但它可能被子进程覆盖（例如通过 setrlimit）、被容器 runtime 重设（Docker/K8s 中常设为 unlimited 或极小值），甚至被 systemd service 文件中 LimitSTACK= 覆盖。
更隐蔽的问题是：即使 RLIMIT_STACK 是 8 MiB，真实分配的栈页数仍受 mmap 分配策略和 VM_MAX_MAP_COUNT 影响；某些嵌入式 libc（如 musl）对线程栈处理逻辑与 glibc 不同；Android NDK 的 bionic 则强制将新线程栈限制为 1 MiB，无视 RLIMIT_STACK。
真正需要栈大小感知的场景（比如协程、自定义调度器、深度递归防护），必须结合平台检测 + 运行时探测 + 容错兜底，不能只信一个数字。
