平衡因子是节点左子树高度减右子树高度的值，必须通过缓存height字段并在插入/删除后自底向上实时更新来维护，不可递归重算高度，否则时间复杂度退化为O(n)。
平衡因子是什么，为什么不能靠递归临时算
平衡因子（Balance Factor）是节点左子树高度减右子树高度的值，BST 平衡性判断（如 AVL 树）全靠它。但很多人一上来就写 getBalanceFactor(node) 用递归反复算左右子树高度——这会导致每次插入/删除后调用一次，时间复杂度退化成 O(n)，完全失去 AVL 的 O(log n) 优势。
真正可行的做法是：在每个节点里**缓存高度值**（height），并在结构体中直接存 balance 或按需即时计算（只用两个子节点的 height 字段）。关键不是“怎么算”，而是“谁来维护、何时更新”。
节点结构必须带 height 字段，且只允许自底向上更新
AVL 节点定义里缺 height 就没法实时算平衡因子。别用 int balance 单独存——它容易和 height 不同步，出错难调试。推荐统一存 height，需要平衡因子时当场算：node->left->height - node->right->height。
更新时机严格限定在旋转之后、回溯路径上：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 每次插入/删除完成递归返回时，重新计算当前节点
height = 1 + max(left->height, right->height) - 旋转操作（
rotateLeft/rotateRight）内部必须显式重设涉及节点的height - 绝不在任意地方调用全树遍历式
getHeight()函数
旋转后 height 更新顺序极易写反
以 rotateLeft 为例：新根是原右孩子，原根变成其左孩子。此时若先算原根的新高度，它依赖的左子树（即新根的左子树）可能还没被修正；而新根的高度又依赖原根——顺序错了就会得到错误 height，进而导致后续平衡因子全错。
正确顺序（以 node 为旋转前根，newRoot = node->right）：
- 先更新
node->height = 1 + max(node->left->height, node->right->height)（注意此时node->right还是旧指针，但它的子树已调整完） - 再更新
newRoot->height = 1 + max(newRoot->left->height, newRoot->right->height)
常见错误是把这两步颠倒，或漏掉其中某一个 height 更新——结果就是某次插入后树看起来平衡，但下一次操作触发错误旋转，甚至崩溃。
insert/delete 后不触发 rebalance 就等于没算平衡因子
就算你每个节点都存了 height、每次旋转都更新对了，如果插入后没检查并执行 rebalance，那平衡因子只是“存在”，不是“生效”。典型疏漏：
- 递归插入返回后，只更新了当前节点
height，但没算它的balance值是否超出 [-1,1] - 发现失衡后，只做了旋转，但没继续向上回溯检查父节点是否也失衡（AVL 需要最多一次旋转，但实际实现中常需多层 rebalance）
- 删除节点时，回溯路径更长，漏掉某一层的
height更新或rebalance判断，导致后续插入行为异常
最稳妥的做法：在 insert/delete 递归返回的每一层，都做三件事——更新 height → 计算 balance → 若 |balance| > 1 则调用 rebalance 并用其返回值更新父指针。少一步，整个平衡逻辑就断链了。
