必须先找后继（或前驱）替换，因为直接删除双子节点会破坏红黑树黑高一致性和路径黑节点数相等约束；后继最多一个子节点，可简化为0/1子节点删除情形，且仅当后继为黑色时才需调用fixUpAfterDelete修复。
删除节点时为什么必须先找后继（或前驱）来替换？
红黑树删除一个有两个子节点的节点时，不能像二叉搜索树那样直接删掉——因为直接删会破坏红黑树的结构约束（尤其是黑高一致性和路径上黑节点数相等）。标准做法是用它的中序后继（右子树最左节点）或前驱（左子树最右节点）来覆盖待删节点的值，再真正删除那个后继/前驱节点。这个后继节点最多只有一个子节点（否则它就不是“最左”了），从而把问题简化为「删除 0 或 1 个子节点的节点」这一可控情形。
实践中几乎都选后继（successor），因为右子树存在性有保障（原节点有两个子节点 → 右子树非空），且逻辑统一。注意：后继节点的值复制过去后，原节点的 color、left、right 等字段不变，只是 key 和 value 被覆盖；真正要处理平衡的是被删的那个后继节点。
后继节点被删后，什么情况下会触发红黑树再平衡？
只有当被删的后继节点是黑色时，才可能破坏黑高性质（删掉一个黑节点，导致某些路径黑节点数减 1）。如果它是红色，直接删掉不影响任何红黑规则，无需调整。
所以再平衡的入口条件很明确：仅当被删节点为黑色，且它被删后留下的“空缺位置”需要向上修复黑高。此时传入该节点原来的位置（即它父节点指向它的指针方向）作为 node 参数，交给 fixUpAfterDelete 处理。
常见误判点：
- 误对红色后继调用修复函数 —— 不需要，直接 return
- 误将原待删节点（非叶子）当作修复起点 —— 修复起点必须是实际被删的后继节点在树中的原位置（通常是叶子或单子节点）
- 忽略“被删节点是根且为黑”的边界：此时修复后若根变红，需手动染黑（但
fixUpAfterDelete通常已保证根最终为黑）
fixUpAfterDelete 的四种情况怎么对应实际指针状态？
该函数接收一个“双重黑色”的占位节点（即被删黑节点留下的空缺），通过旋转+ recolor 把双重黑“上推”或“抵消”。四种 case 本质由兄弟节点 sibling 及其子节点颜色决定：
假设当前待修复节点是 x（x 是空缺，x->parent 存在），sibling = x == x->parent->left ? x->parent->right : x->parent->left：
- Case 1：sibling 为红 → 必先左/右旋父节点，让 sibling 变黑、父变红，再进 Case 2/3/4
-
Case 2：sibling 黑，且两个子都黑（或为空） → 将 sibling 染红，
x上移到父节点，继续循环 - Case 3：sibling 黑，近侄子红、远侄子黑 → 对近侄子旋，转成 Case 4
- Case 4：sibling 黑，远侄子红 → 旋父节点，交换 sibling 与父颜色，并将远侄子染黑 → 终止
关键细节：near nephew 指与 x 同侧的 sibling 子节点（如 x 是左孩子，则 near 是 sibling->left）；far nephew 是另一侧子节点。很多实现错误源于没严格按此定义判断左右。
删除后继并修复时，如何避免空指针访问和内存泄漏？
实际编码中最容易崩在三处：
- 调用
successor(node)前未确认node->right != nullptr—— 后继只在右子树找，若右为空则逻辑错 - 在
fixUpAfterDelete中访问sibling->left或sibling->right前未判空，尤其nullptr节点的color在多数实现中定义为BLACK，但解引用前仍需检查是否为空指针 - 删除节点后未释放内存，或释放后仍保留野指针（如
parent->left = nullptr后，没置deleted_node->left = deleted_node->right = nullptr）
推荐防御写法：if (sibling && sibling->left) 再取 sibling->left->color；释放节点前先保存其子指针，再 delete，最后将父指针置 nullptr。C++ 中建议用智能指针管理，但手写红黑树通常裸指针，这点必须手动盯死。
动态平衡本身不涉及新内存分配，所有旋转和 recolor 都是原地指针操作。真正的开销在于查找后继（O(log n)）和修复过程（最多 O(log n) 次旋转）。没有特别隐蔽的性能陷阱，但递归实现修复函数易栈溢出，务必用迭代。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
