GetThreadContext无法直接获取堆栈基址，其返回的Rsp仅为当前栈顶指针；堆栈基址固定存储于TEB中（64位偏移0x18→0x08），但需谨慎处理架构与系统版本差异。
Windows下用 GetThreadContext + CONTEXT_CONTROL 获取堆栈基址不可靠
直接调用 GetThreadContext 并读取 Context.Rsp（或 Rbp）得到的是当前栈顶指针，不是堆栈基地址。Windows线程的堆栈基址（即分配时的起始地址）不随函数调用变化，但系统不提供直接API返回它——它被记录在线程环境块（TEB）里，且位置因系统版本和架构而异。
常见错误是误把 Rsp 当作基址，结果在递归或深度调用后发现值不断变小，误以为“基址在动”。实际上堆栈基址固定，只是栈顶向下增长。
-
GetThreadContext仅适合调试器场景，需挂起目标线程，生产环境慎用 - 64位下 TEB 偏移为
0x18（指向NT_TIB），再偏移0x08得到StackBase字段（void*） - 32位下偏移不同（
0x1C然后0x04），且需确认是否启用 SEH（结构化异常处理）影响 TIB 布局 - 使用前必须
#include <windows.h>和#include <winternl.h>（后者非公开，但字段布局稳定）
Linux下通过 /proc/self/maps 解析主线程堆栈范围
Linux 没有“堆栈基地址”概念，只有“堆栈映射区间”，由内核在创建线程时通过 mmap 分配一段内存，并在 /proc/self/maps 中标记为 [stack] 或 [stack:tid]。当前线程的栈底（即最高地址）接近 rsp，栈顶（最低地址）才是“基址”意义的起点。
实操时不能只读一次 /proc/self/maps：多线程下各线程栈映射条目不同，且 self 总指主线程。要查当前线程，得用 /proc/self/task/<tid>/maps，其中 tid 用 syscall(SYS_gettid) 获取。
立即学习“C++免费学习笔记（深入）”；
- 解析时匹配含
[stack的行，提取首字段（如7fffe7ff9000-7fffe7fff000），低位即栈基址 - 注意：主线程栈可能标记为
[stack]，而 pthread 创建的线程标记为[stack:12345] - 该方法有轻微开销（文件 I/O + 字符串解析），不适合高频调用；调试或初始化阶段用更稳妥
- 若程序被
prctl(PR_SET_MM_MAP, ...)修改过内存布局，/proc仍可靠，但需跳过注释行和空行
跨平台可移植方案：依赖编译器内置宏与运行时约定
真正可移植的做法不是“获取基址”，而是“估算可用栈空间”——因为基址本身对应用逻辑极少有用，多数需求实际是防止栈溢出或做协程切换。Clang/GCC 提供 __builtin_frame_address(0) 返回当前帧地址，配合 getrlimit(RLIMIT_STACK, ...) 可粗略估算剩余空间。
-
__builtin_frame_address(0)返回当前函数栈帧起始地址（近似栈顶），类型为void*；传入更大数字（如 1）可向上追溯调用帧 -
getrlimit返回的是进程级栈大小上限（如 8MB），不是当前线程独占值；pthread 创建的线程默认继承该限制，但可通过pthread_attr_setstacksize覆盖 - 无法精确得出“基址”，但能算出从当前帧到栈底的距离：
base = (char*)__builtin_frame_address(0) + stack_rlimit.rlim_cur（仅作示意，实际需考虑栈向下增长方向） - MSVC 不支持
__builtin_frame_address，需用_AddressOfReturnAddress()替代，但后者返回的是返回地址而非帧地址，语义不同
为什么你不该在业务逻辑里硬取堆栈基地址
几乎所有声称需要“堆栈基地址”的场景，真实需求其实是栈空间监控、协程栈切换、或调试信息采集。硬编码 TEB 偏移或解析 /proc 在生产环境极易出问题：Windows 更新可能微调 TEB 布局（尽管极罕见），glibc 版本升级可能改变 /proc 格式，ASLR 启用后每次启动地址不同但基址不变——你拿到的只是虚拟地址，无法跨进程复用。
真正稳定的方案是：用 pthread_getattr_np（Linux）或 GetThreadStackLimits（Windows 10 1809+）这类封装好的接口，它们内部已处理好兼容性细节。如果项目要求支持旧系统，就接受“无法 100% 精确获取”的事实，改用保守估算加 guard page 检测。
