本文深入解析BST节点删除操作中parentNode参数的关键作用，阐明为何在递归调用remove()时必须显式传入当前节点作为父节点，而非使用null——这关系到子树中最小值节点能否被准确定位并安全断链。
本文深入解析bst节点删除操作中`parentnode`参数的关键作用，阐明为何在递归调用`remove()`时必须显式传入当前节点作为父节点，而非使用`null`——这关系到子树中最小值节点能否被准确定位并安全断链。
在二叉搜索树（BST）中删除一个具有两个子节点的节点时，标准策略是：用其右子树中的最小值（即中序后继）覆盖该节点的值，再递归删除该最小值节点。你的代码正是遵循这一逻辑：
if (currentNode.left !== null && currentNode.right !== null) {
currentNode.value = currentNode.right.getMinValue(); // 复制值
currentNode.right.remove(currentNode.value, currentNode); // 删除副本
}关键疑问在于：为什么第二行必须写成 currentNode.right.remove(..., currentNode)，而不是 currentNode.right.remove(..., null)？
答案在于 remove() 方法依赖 parentNode 完成“物理删除” —— 即将目标节点从其父节点的左/右引用中彻底移除（置为 null 或替换为子节点）。该方法本身不回溯查找父节点，而是全程依赖调用时传入的 parentNode 引用来执行最终的指针重连。
考虑如下典型场景：
假设要删除节点 A（值为 10），其右子树结构为：
A(10)
/ \
... B(15)
/
C(12)
/
D(11) ← getMinValue() 返回 11此时 A.right.getMinValue() 返回 11，A.value 被更新为 11，接着执行 B.remove(11, A)。
- 若传入 A 作为 parentNode：当递归进入 B 后，算法发现 11
- 若错误传入 null：当递归到达 D 时，parentNode 仍为初始的 null。尽管 D 是叶子节点（无子节点），但 remove() 的逻辑会进入 else if (parentNode === null) 分支——它会尝试将 D 的值“上提”到根节点（即试图修改 this 自身），这完全违背了删除 D 的意图，且会导致树结构损坏（例如 B 的子树被意外覆盖）。
因此，parentNode 不是“可选的辅助参数”，而是删除操作的必要上下文。它确保：
- ✅ 在任意递归深度，都能精准定位并修改目标节点的父级引用；
- ❌ 避免因 parentNode === null 触发根节点误修改逻辑；
- ✅ 支持任意形状的子树（包括右子树直接以最小值节点为根的情况，如 B 的左子节点就是 D）。
最佳实践总结：
- 每次对子节点调用 remove() 时，必须将当前节点作为 parentNode 显式传入；
- 切勿假设“方法内部会自动找到父节点”——BST 删除是自顶向下的单向遍历，无回溯能力；
- parentNode = null 仅合法于首次调用（即用户主动调用 root.remove(x)），表示操作起点是整棵树的根。
