windows下堆栈基地址需读teb的stackbase字段（x64为__readgsqword(0x38)，x86为__readfsdword(0x18)），而非rsp/esp；linux应解析/proc/self/maps中[stack]行起始地址或用pthread_getattr_np；两者均非跨平台标准方案。
Windows下用 GetThreadContext 无法直接拿到堆栈基地址
很多人尝试调用 GetThreadContext 想从 CONTEXT 结构里读 Rsp 或 Esp，以为这就是“堆栈基地址”——但这是当前栈顶指针（stack pointer），不是基地址（stack base）。Windows 线程创建时通过 CreateThread 的 dwStackSize 参数或系统默认值预留一段虚拟内存，其起始地址才是堆栈基址，它不随函数调用动态变化。
真正能获取该地址的方式是读取线程环境块（TEB）的固定偏移：
- 在 x64 下，TEB 起始地址可通过
__readgsqword(0x30)获取（gs段寄存器指向 TEB） - 堆栈基地址位于 TEB + 0x8（
StackBase字段），即__readgsqword(0x30 + 0x8) - x86 下用
__readfsdword(0x18)（TEB + 0x18 是StackBase）
Linux下必须解析 /proc/self/maps 或用 pthread_getattr_np
Linux 没有公开稳定的 ABI 提供线程栈基址，内核也不导出该信息到用户态。常见误区是读 rsp 寄存器或 &some_local_var ——这只能得当前栈顶，不是分配边界。
可靠做法有两种：
- 调用
pthread_getattr_np（GNU 扩展），再用pthread_attr_getstack提取stackaddr和stacksize；注意stackaddr是栈底（最低地址），即“基地址” - 读
/proc/self/maps，找标记为[stack]的行，其起始地址就是栈基址（例如7fffec000000-7fffec021000 rw-p 00000000 00:00 0 [stack]中的7fffec000000） - 务必注意：主线程栈不可靠（可能被
mmap打断），且pthread_getattr_np对主线程返回的是初始栈，不是当前main()运行时的实际栈范围
跨平台封装要避开 __readgsqword 和 pthread_getattr_np 的可移植性陷阱
这两个 API 都非标准：前者是 MSVC/Clang 特定内联汇编封装，GCC x86_64 下需改用 __builtin_ia32_rdfsbase64（仅支持特定 CPU+内核）；后者是 GNU libc 私有扩展，musl 或 Android Bionic 不提供。
如果真需要跨平台获取，务实做法是：
- Windows：硬依赖
__readgsqword（x64）或__readfsdword（x86），并用#ifdef _WIN32隔离 - Linux：优先走
/proc/self/maps解析（纯 C 文件 I/O，无依赖），fallback 到pthread_getattr_np（加#ifdef __GLIBC__） - macOS：没有等效接口，
pthread_get_stackaddr_np返回的是栈顶附近地址，不可靠；实际项目中往往直接放弃获取“精确基址”，转而用pthread_stackseg_np（仅限 macOS 12+，且需 entitlement）
“堆栈基地址”在调试和内存扫描场景中极易误用
拿到所谓“基地址”后直接遍历到当前 rsp 并假设中间全是有效数据？危险。现代栈有 guard page、hot/cold 分区、以及编译器插入的栈保护填充（如 -fstack-protector 的 canary 前空隙），真实有效数据区域远小于 base → rsp 区间。
更关键的是：线程栈在运行中可能动态增长（尤其 Linux 下按需 mmap），初始基址只反映创建时的预留起点，不代表当前实际可用范围上限。真要做栈扫描，应结合 getrlimit(RLIMIT_STACK, &r) 查软限制，并以当前 rsp 为界反向探测有效帧，而不是依赖静态基址。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
