删除节点不能只用delete后置空指针，因为必须维持bst性质：左子树全小于根、右子树全大于根；若被删节点有两个子节点，需用中序后继（右子树最小值）替换并递归删除该后继，否则结构破坏导致查找错误或段错误。
删除节点时为什么不能只用 delete 后置空指针？
因为二叉搜索树（BST）删除后必须维持左子树全部小于根、右子树全部大于根的性质，直接 delete 节点而不调整结构会导致 BST 破坏。尤其当被删节点有两个子节点时，必须找替代节点（前驱或后继），并递归重构其原位置。
常见错误现象：segmentation fault 或后续 find 返回错误值，往往是因为删完没更新父节点的左/右指针，或者替代节点移动后没修正其子树连接。
- 若节点无子节点：直接
delete，并让父节点对应指针置为nullptr - 若节点仅有一个子节点：用该子节点“顶替”自己，重连父节点指针
- 若节点有两个子节点：取左子树最大值（中序前驱）或右子树最小值（中序后继），复制其值到当前节点，再递归删除那个叶子/单支节点
remove 函数里如何安全找到并替换后继节点？
推荐用右子树的最左节点（即中序后继），逻辑清晰且避免重复判断。关键不是“找”，而是“找完怎么搬”：只搬值（node->val = successor->val），再调用同一 remove 函数删掉后继节点——这样复用逻辑，不用额外写分支来处理后继的子树挂接。
容易踩的坑：successor 可能有右子树（但绝不会有左子树），所以删除它时只能走“无子”或“仅右子”分支；若错误当成叶子删，会漏掉其右子树。
示例片段（非完整类）：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
TreeNode* findSuccessor(TreeNode* node) {
node = node->right;
while (node->left) node = node->left;
return node;
}
<p>TreeNode<em> remove(TreeNode</em> root, int key) {
if (!root) return nullptr;
if (key val) root->left = remove(root->left, key);
else if (key > root->val) root->right = remove(root->right, key);
else {
if (!root->left) return root->right;
if (!root->right) return root->left;
TreeNode* succ = findSuccessor(root);
root->val = succ->val; // 只搬值
root->right = remove(root->right, succ->val); // 再删原后继
}
return root;
}</p>
为什么递归实现比迭代更不容易出错？
因为 BST 删除本质是局部重构：每次只改当前层的指针指向，而递归天然携带“返回新子树根”的语义，能自然承接子树变更后的根节点。迭代写法需手动维护父节点指针和方向（左/右），在双子节点场景下要模拟“找后继→摘下→拼回”三步，极易漏更新某处链接。
性能上无显著差异（都是 O(h) 时间），但可读性和调试友好度差一截。除非明确禁止栈空间使用（如嵌入式硬实时场景），否则优先递归。
- 递归版每个
remove调用都返回该子树新的根，上层直接赋值给left或right - 迭代版需额外记录
parent和is_left_child，删除后继时还要再跑一遍查找+断链+重连 - 所有主流 STL 容器（如
std::set内部）的平衡 BST 删除也基于递归思想展开
重构后树高可能突增吗？
标准 BST 删除不保证平衡，所以会。例如连续删掉所有左侧节点，剩下一条向右延伸的链，树高退化为 O(n)。这不是删除逻辑错了，而是 BST 本身没自平衡机制。
如果你需要稳定 O(log n) 性能，得换成 AVLTree 或 RedBlackTree，它们在每次 remove 后强制调用 rotate 和颜色翻转来恢复平衡。但纯 BST 的删除函数本身无需、也不该包含旋转逻辑。
真正容易被忽略的一点：即使你手写 AVL，remove 后的平衡操作必须从被删节点的父节点开始向上检查，而不是从根开始——否则效率直接变 O(n log n)。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
