递归遍历嵌套结构必须明确定义终止条件、合理选择传参方式、防范栈溢出、用编译期机制处理异构类型，并厘清所有权语义。
递归遍历嵌套结构时，必须明确定义终止条件
没有清晰的 base case，递归会无限深入或崩溃。比如处理 std::vector 套 std::vector、或自定义结构体含 children 成员，得先判断当前层级是否“到底”——是空容器？是叶子节点？还是 nullptr？
常见错误是把 size() == 0 当成唯一终止条件，但嵌套中可能有非空但无子结构的中间节点（如含元数据但无 children 的树节点），这时应检查 children.empty() 或 children == nullptr，而非仅看容器大小。
- 对
std::vector<node></node>：用nodes.empty()判断是否跳过循环 - 对指针型子节点（如
Node* left,Node* right）：必须先判if (node == nullptr) return; - 对支持范围 for 的容器，避免在递归前调用
.size()再用下标访问——若结构在递归中被修改，下标易越界
传参方式决定是否需要深拷贝或引用保护
递归函数参数用值传递、引用或 const 引用，直接影响性能和行为。嵌套结构通常较大，值传递会触发多次拷贝；但若递归中要修改局部副本，又不能直接传 const&。
典型场景：遍历并收集所有叶子值到 std::vector<int></int>。此时应把结果容器以 std::vector<int>&</int> 传入，避免每层都拷贝；而被遍历的结构本身，只要不修改，就用 const auto&。
- 读操作为主 → 参数用
const std::vector<t>&</t>或const Node& - 需修改子结构（如重排 children）→ 用
std::vector<t>&</t>，并在递归调用前确认线程安全或所有权明确 - 绝对不要把临时对象（如
getChildren()返回值）以非 const 引用传入递归函数，会导致 dangling reference
栈溢出比想象中更容易发生
C++ 没有尾递归优化保证，深度超过几百层就可能炸栈，尤其在默认栈大小（Linux 默认 8MB，Windows 可低至 1MB）下。嵌套 JSON、AST、DOM 树等真实数据很容易超限。
不是所有嵌套都适合纯递归。例如解析深度达 2000 层的 YAML，即使逻辑简洁，parse(node) 每层占几百字节栈帧，也会 crash。
- 用
sizeof估算单层栈开销：含局部变量、返回地址、寄存器保存区 - 编译时加
-Wstack-protector（GCC/Clang）可捕获部分风险，但不防溢出 - 替代方案：显式用
std::stack<node></node>模拟递归，把“调用栈”移到堆上
模板递归处理异构嵌套时，SFINAE 或 concepts 更可靠
当嵌套结构类型不统一（比如 std::variant<int std::vector>, std::map<:string data>></:string></int>），靠运行时 type_info 分支既慢又易漏。C++17 起，用 if constexpr + std::is_same_v 或 C++20 concepts 能在编译期裁剪无效分支。
例如写一个通用 visit_all 函数：对 int 直接处理，对容器递归，对 std::string 忽略——若不用 if constexpr，编译器会尝试实例化所有分支，遇到 value.begin() 对 int 就报错。
- 避免在模板递归中写
auto x = value.begin();这类泛型代码，除非确保所有可能类型都支持 - 用
requires约束容器类型：requires std::ranges::range<t></t>比手动 SFINAE 更直观 - 调试时加
static_assert：比如static_assert(!std::is_same_v<t void>);</t>防止意外推导出 void
实际写的时候，最常被忽略的是递归路径的「所有权语义」：你是在遍历只读数据，还是在转移、释放嵌套资源？前者可以放手用引用，后者必须厘清谁 delete、谁 move、谁保持有效。一不留神，double-free 或 use-after-move 就藏在第 5 层递归里。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
