指针改递归不一定省空间，因其仅减少栈帧中指针变量大小（8字节），不减少所指堆内存，且栈深度由栈帧数量决定；真正降空间需迭代+显式栈或共享只读数据。
为什么用指针改递归不一定省空间
很多人以为“把局部变量改成指针就能减少栈占用”，其实不然。指针本身只占 8 字节（64 位），但若它指向堆上分配的大对象（比如 new int[100000]），空间只是从栈挪到了堆，总内存没少，还多了指针解引用开销和内存管理负担。真正影响栈深度的，是每次调用压入的栈帧大小——而栈帧里存的是参数、返回地址、局部变量（含指针变量本身），不是它指向的内容。
常见错误现象：std::vector 或 std::string 在递归函数里按值传递，内部缓冲区被反复拷贝；或递归中 new 一堆小对象却忘了 delete，造成堆内存泄漏而非栈溢出。
- 别在递归函数里声明大数组：
int buf[65536]直接吃掉约 256KB 栈空间 - 避免按值传递容器：用
const std::vector<int>&</int>替代std::vector<int></int> - 指针参数不自动降低栈压力——
TreeNode* root和TreeNode& root在栈帧里都只占一个指针宽度
什么时候指针真能帮上忙：共享只读数据
当多层递归需要访问同一份只读数据（如配置表、静态树结构、常量 lookup 表），用指针（或引用）传入可避免逐层拷贝。这不减少栈帧数量，但能压缩单帧大小。
使用场景：解析嵌套 JSON AST、遍历编译器 IR 树、回溯搜索时共享约束条件集合。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 把大只读数据放在全局/静态存储区，递归函数只传
const T*或const T& - 禁止在递归中通过指针修改共享状态——否则需加锁或复制，反而更重
- 对比：
void dfs(Node* root, const std::unordered_map<:string int>* config)</:string>比按值传config节省数百字节/帧
真正降空间的核心：消灭隐式栈帧
指针不是银弹，迭代+显式栈才是对抗栈溢出的可靠手段。你用 std::stack 或 std::vector 手动模拟调用栈，把本该压在系统栈上的帧数据挪到堆上，从而解除栈大小硬限制。
性能影响：堆分配比栈分配慢，但现代 std::vector::reserve() 预分配后，push_back/pop_back 接近 O(1)；且避免了栈溢出崩溃这种不可恢复错误。
- 树中序遍历迭代版里，
std::stack<:pair bool>></:pair>替代递归调用栈 - 用
std::vector代替std::stack更可控：调用v.reserve(10000)避免多次 rehash - 不要在循环里频繁
new/delete节点——统一用对象池或预分配数组管理
尾递归 + 指针参数的组合陷阱
写成尾递归形式（如 traverse(node->left, acc)）并传指针，不代表编译器一定优化。GCC/Clang 只在 -O2 以上且无异常、无虚函数、无析构逻辑时才可能把 call 换成 jmp。一旦函数里有 std::unique_ptr 或 try-catch，优化立即失效。
容易踩的坑：你以为加了指针参数就“轻量”了，结果函数仍因非尾位置调用或异常安全机制保留完整栈帧。
- 用
objdump -d your_binary | grep -A5 'factorial_tail'查看是否生成jmp而非call - 在入口加深度计数：
if (++depth > 5000) std::abort();，快速验证是否真复用了栈帧 - 对用户输入不可控的场景（如解析任意深度 XML），别依赖尾递归——直接上迭代
最易被忽略的一点：指针本身不解决栈溢出，它只是工具；真正决定空间复杂度上限的，是你选择把状态存在哪——栈上？堆上？还是寄存器里？而后者，只有编译器在尾递归成功时才可能做到。
