平衡因子定义与实时计算的矛盾点在于：若不缓存height字段，又每次调用都递归求高，则时间复杂度退化为O(n)，破坏AVL树O(log n)性能；真正实时计算依赖插入/删除路径上balance factor的链式更新与旋转时的固定赋值规则，而非现场递归。
平衡因子定义与实时计算的矛盾点在哪里
平衡因子本质是左子树高度减右子树高度，但“不依赖记录高度”意味着不能存 height 字段，也不能每次调用 get_height() 递归算——后者时间复杂度 O(n)，完全破坏 AVL 树的 O(log n) 操作前提。
真正的实时计算，必须在结构变更（插入/删除）过程中，仅靠局部节点信息推导出当前节点的平衡因子，且全程不查子树高度。这只有在维护过程中同步更新时才可行——换句话说，“不存高度”不等于“不隐含高度信息”，而是把高度差信息压缩进平衡因子本身，并利用旋转时的固定变化规律来传播。
插入后如何只靠平衡因子链式更新
AVL 插入后从插入点向上回溯到根，对路径上每个节点重新计算平衡因子。关键在于：你不需要知道左右子树绝对高度，只需要知道它们各自的平衡因子，以及哪边发生了变化。
- 若插入发生在左子树，且原左子节点平衡因子为
0→ 当前节点平衡因子变为1 - 若插入发生在左子树，且原左子节点平衡因子为
1→ 当前节点平衡因子变为2（需旋转） - 若插入发生在左子树，且原左子节点平衡因子为
-1→ 左子树被“拉平”，当前节点平衡因子变为0 - 右子树插入同理，符号相反
这个逻辑成立的前提是：每个节点的 balance_factor 始终准确反映其左右子树高度差，且插入只影响路径上节点的子树高度最多 ±1 —— 这正是 AVL 的结构保证。所以你根本不需要 get_height()，只需沿路径检查并按规则更新 balance_factor 字段即可。
立即学习“C++免费学习笔记（深入）”；
旋转时平衡因子怎么重置（最容易写错的部分）
单旋转（LL / RR）和双旋转（LR / RL）后，参与旋转的 2~3 个节点的平衡因子不能靠“重新计算”得出，必须按固定模式赋值。手写错一个符号，整棵树就失衡。
以 LL 旋转为例（右旋）：
设旋转前节点为 x，其左子为 y，y 的右子为 T2。
旋转后：y 成为新父，x 为右子，T2 接到 x 左侧。
此时新平衡因子为：
y->balance_factor = y->balance_factor - 1 - std::max(0, x->balance_factor)x->balance_factor = x->balance_factor - 1 + std::min(0, y->balance_factor)
但更稳妥、不易出错的做法是直接查表赋值：
// LL 旋转后 y->balance_factor = std::max(0, y->balance_factor - 1); x->balance_factor = std::min(0, x->balance_factor - 1);
而 LR 旋转（先左旋再右旋）涉及三个节点，标准做法是：先对 y（原 x 的左子）做左旋，再对 x 做右旋，最后根据旋转前 z（y 的右子）的 balance_factor 设置 x、y、z 的新值：
若 z->balance_factor == 0 → x 和 y 都设为 0；
若 z->balance_factor == 1 → x = -1, y = 0；
若 z->balance_factor == -1 → x = 0, y = 1；
然后 z->balance_factor = 0。
为什么不能在 get_balance() 里现场递归算高度
有人试图写一个不存 balance_factor 字段的“纯函数式”版本，每次调用 get_balance(node) 就递归算左右子树高度再相减。这看起来满足“不依赖记录高度”的字面意思，但实际完全不可行：
- 一次
insert()可能触发 O(log n) 次get_balance()调用，每次调用耗时 O(n)，总复杂度退化为 O(n log n) - 旋转判断逻辑需要快速响应（比如检测到
abs(balance_factor) == 2就立刻处理），延迟计算会导致条件判断失效 - 多线程环境下，若未加锁，两次连续调用可能因中间插入导致结果不一致
所谓“实时”，是指操作过程中每一步的平衡状态都确定、可验证、可干预。靠现场计算，就不是实时，是事后审计。
真正省掉的是显式 height 字段，不是省掉高度差的维护逻辑——它只是被编码进了 balance_factor 的更新规则里。漏掉某次更新，或旋转后没重置，树就 quietly 失衡了，debug 时连日志都难定位。
