因为递归DFS将每层函数帧压入系统调用栈，深度过大（如链状结构达10⁵）易触发栈溢出；迭代DFS用堆内存的显式栈（如std::stack），容量更可控、可手动管理状态与中断。
递归实现DFS时，为什么栈溢出风险比迭代高？
因为递归调用会把每层函数帧压入系统调用栈，树深度过大（比如退化成链表、10⁵节点）时容易触发 std::stack_overflow 或直接崩溃。迭代用自己管理的 std::stack，内存分配在堆上，容量更可控。
实操建议：
- 递归版本只适合深度明确可控的场景（如平衡二叉树、深度
- 必须写递归时，加深度计数器并提前退出：
if (depth > MAX_DEPTH) return; - 迭代版初始化栈：用
std::stack<:pair int>></:pair>可同时存节点和当前深度，方便做层级相关逻辑
迭代DFS用std::stack还是std::vector模拟？
std::stack 语义清晰、接口简洁（push()/top()/pop()），但底层默认用 std::deque，内存局部性略差；用 std::vector 手动模拟（push_back()/back()/pop_back()）性能稍好，尤其在大量节点时。
常见错误现象：混用 std::queue 导致变成 BFS —— 迭代 DFS 必须后进先出，std::queue 是先进先出。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 初学或逻辑复杂时优先用
std::stack，避免下标越界 - 高频调用场景（如游戏引擎中频繁遍历场景树）可换
std::vector，并预留空间：nodes.reserve(4096); - 注意空指针检查：迭代循环开头必须判
if (!node) continue;，否则解引用崩溃
前序/中序/后序遍历在迭代实现中，控制访问时机的关键在哪？
递归靠函数调用顺序天然区分；迭代必须靠「标记」或「多次入栈」来模拟调用栈状态。最常用的是三元组标记法：enum class State { VISIT, PROCESS }; 配合 std::stack<:tuple state>></:tuple>。
性能影响：多一次栈操作（比如后序需每个节点入栈两次），但避免了额外 vector 存储中间结果。
实操建议：
- 前序最简单：访问节点 → 压右子树 → 压左子树（注意左右顺序）
- 中序推荐「一路向左+栈回溯」模式，比三元组更省内存
- 后序若不用标记法，可用两个栈：第一个栈做根→右→左入栈，第二个栈倒序输出 —— 但空间翻倍，慎用
递归与迭代DFS的返回值设计为何不能直接套用？
递归天然支持「找到即返回」（比如搜索目标值），靠 return 向上透传；迭代必须显式 break + 清空栈，否则继续遍历浪费 CPU。
容易踩的坑：迭代版写成 while (!stk.empty()) { ... if (found) return true; } 看似正确，但没清栈 —— 下次调用时栈非空，逻辑错乱。
实操建议：
- 搜索类函数（如
bool exists(TreeNode* root, int target)）迭代版务必在return前加while (!stk.empty()) stk.pop(); - 若需返回路径，递归用引用参数
std::vector<int>& path</int>回溯；迭代则需额外存父节点映射（std::unordered_map<treenode treenode></treenode>），空间开销大 - 泛型考虑：模板函数中，递归版类型推导自然；迭代版若用
auto推导节点类型，需确保TreeNode有统一接口（如left/right成员）
真正麻烦的不是写法本身，而是判断该用哪一种——树形态未知时，别硬写递归；需要中断遍历或带状态回传时，迭代的控制粒度更实在。
