Windows下应使用GetCurrentThreadStackLimits获取堆栈基地址（即LowLimit），该API自Windows 8起可用，比解析TEB更可靠；Linux主线程可通过/proc/self/maps中[stack]行的起始地址获得基址，非主线程需查/proc/self/task/TID/maps。
Windows下用GetCurrentThreadStackLimits获取堆栈边界
Windows提供了官方API直接读取当前线程的堆栈范围，比手动解析TEB更可靠、兼容性更好。该函数从Windows 8 / Server 2012起可用，返回低地址（栈底）和高地址（栈顶），其中栈底即为堆栈基地址（stack base address）。
-
GetCurrentThreadStackLimits参数是两个ULONG_PTR*指针，分别接收LowLimit（栈底，即基地址）和HighLimit（栈顶） - 注意：栈是向下增长的，所以
LowLimit < HighLimit，且当前栈指针（如&i）应落在这个区间内 - 若在旧系统（如Win7）上运行会调用失败，需先检查OS版本或fallback到TEB读取（见下节）
- 示例片段：
ULONG_PTR low = 0, high = 0; if (GetCurrentThreadStackLimits(&low, &high)) { // low 就是堆栈基地址 printf("Stack base: 0x%llx\n", (unsigned long long)low); }
Linux下通过/proc/self/maps解析主线程堆栈段
Linux没有直接API返回当前线程堆栈基址，但主线程（main thread）的堆栈段会在/proc/self/maps中标记为[stack]，其起始地址即为堆栈基地址；对pthread创建的线程，则需读取/proc/self/task/TID/maps并找[stack:TID]行。
- 主线程可直接读
/proc/self/maps，匹配含[stack]的行，取首字段（十六进制起始地址） - 非主线程需先调用
syscall(SYS_gettid)获取TID，再拼路径：/proc/self/task/<tid>/maps - 注意：该文件每行格式为
start-end perm ... name，[stack]段的start就是基地址，不是end - 不可依赖
pthread_attr_getstack——它返回的是创建时指定的栈空间，而非当前实际使用的基址
跨平台不推荐依赖TEB/TCB结构体硬编码偏移
有人尝试通过__readgsqword(0x30)（x64 Windows TEB）或__builtin_frame_address(0)加启发式推算来“猜”基址，这类做法风险极高。
- TEB结构未公开且随系统版本变动（例如Win11已调整部分字段布局），
0x30在某些更新后不再指向StackBase - gcc/clang对
__builtin_frame_address的行为无保证，优化级别变化可能导致返回值失效 - glibc的
pthread内部TCB布局也无ABI承诺，sizeof(struct pthread)或偏移量不可移植 - 即便临时work，也会在ASLR启用、不同libc版本或musl环境下彻底失效
为什么GetThreadContext + Rsp不能得到基地址
常见误解是“栈指针Rsp就是栈底”，实际上Rsp只是当前栈顶位置，离真正的堆栈基地址可能差几MB——尤其在线程刚启动、尚未大量使用栈时。
立即学习“C++免费学习笔记（深入）”；
-
GetThreadContext能读到当前寄存器状态，但Rsp值随函数调用实时变化，和基地址无关 - Windows堆栈默认预留1MB（可配置），其中只有一小部分被提交（committed），基地址指向预留区起点，而非已用区域起点
- 试图用
VirtualQuery((void*)rsp, &mbi, sizeof(mbi))向上遍历找MEM_RESERVE区域起点，效率低且易受栈Guard Page干扰
GetCurrentThreadStackLimits，Linux走/proc/self/maps解析。其它所有“绕过API”的技巧，在生产环境里迟早出问题——尤其是当你的代码跑在容器、WSL或新版本发行版上时。 
