递归统计二叉树节点数最直观：空节点返回0，否则返回1 + countNodes(root->left) + countNodes(root->right)，代码简洁易验证，但链状退化树可能导致栈溢出。
递归统计二叉树节点数：简洁但要注意栈溢出
直接写 countNodes(root) 递归函数是最直观的做法：空节点返回 0，否则返回 1 + countNodes(root->left) + countNodes(root->right)。它天然匹配二叉树的结构定义，代码少、易验证。
但实际部署时得留心栈深度——链状退化树（比如只有左子树的 10⁵ 层树）会让递归调用栈爆掉，触发 std::stack_overflow 或段错误。GCC 默认栈大小通常仅 8MB，远不够。
- 适用场景：开发调试、树高可控（如平衡树、
height ）、或明确限制输入规模 - 避免写成
if (root == nullptr) return 0;后漏掉else分支——C++ 不强制要求所有路径有返回值，但未定义行为可能在优化后出错 - 别在递归里反复计算子树高度来“优化”，那只会让时间从
O(n)变成O(n log n)
迭代实现用栈模拟：控制内存但逻辑稍显冗余
用 std::stack<treenode></treenode> 显式维护待访问节点，每次 pop 一个节点，计数器加 1，再把它的非空子节点 push 进去。本质是手动展开递归过程，完全规避栈溢出风险。
关键点在于顺序无关——中序/前序/后序遍历都能统计总数，只要每个节点被访问且只被访问一次。所以不必纠结遍历类型，选最顺手的就行。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 示例核心片段：
int count = 0;<br>std::stack<TreeNode*> stk;<br>if (root) stk.push(root);<br>while (!stk.empty()) {<br> TreeNode* node = stk.top(); stk.pop();<br> count++;<br> if (node->right) stk.push(node->right);<br> if (node->left) stk.push(node->left);<br>} - 注意 push 顺序：先右后左，才能保证左子树先被处理（若模仿前序）；如果顺序反了，结果没错，但遍历路径不同
- 用
std::queue做 BFS 也可以，空间复杂度变成O(w)（w 是最大宽度），而 DFS 栈解法是O(h)（h 是树高），两者取舍看数据特征
为什么不用 Morris 遍历？它真能省空间但不值得
Morris 遍历能把空间压到 O(1)，靠临时修改指针建立线索，遍历完再还原。理论上适合嵌入式或内存极端受限场景。
但实际项目里几乎没人用：它破坏树结构（哪怕短暂），无法用于多线程环境；且一旦中途崩溃，树可能处于不可恢复状态；调试时指针乱跳，gdb 都难跟。
- 仅当明确约束为「必须 O(1) 额外空间」且树只读、单线程、可接受代码复杂度翻倍时才考虑
-
TreeNode若含 const 成员或被封装在类里，Morris 的指针改写会编译失败 - 现代 CPU 缓存友好性上，标准栈/队列比 Morris 的随机指针跳转更稳定
性能差异到底在哪？别被理论复杂度骗了
递归和迭代的时间都是 O(n)，但实测中递归往往更快——函数调用开销被现代编译器内联优化得差不多，而迭代要频繁调用 stack::push()/pop()，涉及内存分配器路径（尤其小对象频繁进出）。
真正影响性能的是缓存局部性：递归按深度优先走，内存访问更连续；迭代若用 std::stack（底层是 deque），节点地址可能分散，cache miss 更高。
- 若用自定义静态数组栈（比如
TreeNode* stack[1024]），迭代性能可反超，但需预估最大深度 - Release 模式下，Clang/GCC 对递归的 tail call 优化极少生效（因为有两个递归调用），别指望自动转成迭代
- 统计节点数这种纯遍历操作，CPU 时间占比极低；瓶颈常在树本身的构建或 I/O 上，过早优化意义不大
递归写起来快，迭代更稳，但真正该花时间琢磨的是：你传进来的 root 指针是否可能野指针，以及树结构是否在统计过程中被其他线程修改。
