Linux下最可靠方式是调用pthread_getattr_np(pthread_self(), &attr)配合pthread_attr_getstack获取栈基址，其中stackaddr为栈底（高地址），需配对调用pthread_attr_destroy释放资源，且该函数非异步信号安全、不适用于主线程。
Linux下用pthread_getattr_np获取线程栈基址最可靠
在Linux上，pthread_getattr_np是标准glibc提供的非POSIX但广泛支持的接口，能安全拿到当前线程的栈地址范围。它比直接读/proc/self/maps更轻量，也比依赖__builtin_frame_address(0)推算更准确——后者容易被编译器优化干扰或栈帧布局变化影响。
实操要点：
- 必须先调用
pthread_getattr_np(pthread_self(), &attr)，不能传NULL或未初始化的pthread_attr_t - 用
pthread_attr_getstack提取栈起始地址和大小，返回的stackaddr是**栈底（高地址）**，即栈向低地址增长时的起始位置 - 调用完必须用
pthread_attr_destroy(&attr)释放资源，否则有内存泄漏风险 - 注意
stackaddr通常不是页对齐的起始地址，而是实际分配给该线程栈的内存块首地址
Windows上用GetCurrentThreadStackLimits而非NtQueryInformationThread
Windows 8+提供了GetCurrentThreadStackLimits这个简单可靠的API，直接填入ULONG_PTR*类型的LowLimit和HighLimit即可。它返回的是当前线程用户态栈的边界：其中LowLimit是栈底（可写区域起始），HighLimit是栈顶（保护页起始），所以栈基地址就是LowLimit。
别碰NtQueryInformationThread加ThreadBasicInformation这条路：它返回的StackBase字段在x64上常为NULL，且文档明确说明“仅供系统内部使用”，行为不稳定。
立即学习“C++免费学习笔记（深入）”；
关键细节：
- 函数在
processthreadsapi.h中声明，需链接kernel32.lib - 返回值为
VOID，不检查失败；若在旧系统（如Win7）上调用会静默失败，LowLimit保持未初始化值 - 该API获取的是当前线程的栈，无需手动生成
HANDLE或做权限判断
跨平台封装要注意栈方向与对齐差异
不同平台栈增长方向一致（向下），但起始地址含义不同：Linux的stackaddr是分配块首地址，可能含未使用的高位空间；Windows的LowLimit是真正可写的最低地址。直接把两者等同会导致越界访问。
常见误操作：
- 用
reinterpret_cast<char>(stackaddr) + stacksize</char>算栈顶——这在Linux上大概率越界，因为栈实际只用了部分stacksize - 假设栈基地址一定是页面对齐的——实际上glibc默认栈分配不强制页对齐，
stackaddr常落在页内偏移处 - 在信号处理函数中调用
pthread_getattr_np——它不是异步信号安全函数，可能导致死锁
建议封装时统一返回std::pair<void size_t></void>，其中first为可用栈底地址（即当前栈指针向下可安全写入的起点），second为保守估计的可用字节数（比如取报告大小的1/2）。
调试时别信backtrace或__builtin_frame_address的地址
backtrace返回的是返回地址数组，__builtin_frame_address(0)返回的是当前栈帧基址，二者都不是栈内存块的起始地址。它们受编译器优化（如-tail-call、-fomit-frame-pointer）、内联、栈探测指令影响极大，同一段代码在-O2和-O0下结果可能差几KB。
真实需求场景（比如实现自定义栈溢出检测或协程栈切换）中，依赖这些值等于拿运行时快照当静态布局用——看似能跑，上线后一压测就崩。
如果只是想看栈布局用于调试，cat /proc/self/maps | grep stack最直观，输出里[stack]行的起始地址就是glibc报告的stackaddr，可交叉验证。
