BST删除节点时，为何可传入仅含目标账号的新建CustomerAccount对象作为参数

删除代码的实际运行链路 #

• 流程起点：程序读取控制台输入的目标账户号字符串后，会立刻用该字符串实例化一个仅填充accountNumber字段的轻量CustomerAccount对象。这个对象没有携带客户姓名、账户余额等其他业务字段的真实值，本质是一个用于携带查找凭证的“探针对象”。
• 探针对象传入records.remove()方法后，该方法直接调用BST的标准递归删除逻辑，全程不会将这个探针对象存入树结构。
• 递归删除的执行过程完全复用BST的查找逻辑：从根节点开始遍历，每到一个树节点就将当前节点存储的真实客户记录和传入的探针对象做键值比较，直到定位到accountNumber匹配的目标节点，再按照BST删除规范（叶子节点直接移除、单分支节点用子节点替换、双分支节点用中序前驱/后继节点替换）完成删除，最终返回被删除的真实节点引用；remove方法通过判断返回值是否为null，确认删除操作是否执行成功。

为什么可以传入新建的空壳CustomerAccount对象 #

这种写法能够正常运行的核心逻辑，和BST的底层设计强绑定：

• BST从构建、查找、到删除的全链路，依赖的是键值的大小比较逻辑定位节点，而非对象引用相等、或是对象全字段相等的判定。只要CustomerAccount类正确实现了BST排序依赖的比较规则（要么实现Comparable接口的compareTo方法，要么BST初始化时绑定了基于accountNumber字段的专用比较器），那么两个对象哪怕其他字段完全不同，只要accountNumber的比较结果相等，就会被判定为同一个目标节点。
• 你传入的新建对象从来不需要和树里存储的真实客户记录是同一个实例，它的唯一作用就是把“要删除的账户号”这个查找信息，包装成BST删除方法能识别的入参格式，让BST可以顺着自身的排序规则快速定位目标节点，不会因为是新建对象就出现匹配失效的问题。

这种实现是否属于BST节点删除的标准方案 #

这就是Java生态中有序集合类删除操作的通用标准实现：

以JDK内置的TreeSet为例，其删除操作的设计逻辑完全一致：调用者传入一个同类型的键对象，集合内部不会校验该对象的全字段属性，只会沿着红黑树（平衡BST实现）的查找路径，通过比较逻辑定位键值匹配的节点，直接删除节点中存储的真实元素，调用者传入的临时对象本身全程不会被存入集合结构。

这种设计的优势非常明显：可以避免为了执行单条删除操作，提前从持久层读取完整的业务对象、生成冗余实例的开销，仅靠携带核心匹配键的轻量对象就能完成操作。

需要注意两个容易踩的实现坑：

• 必须保证比较逻辑的一致性：如果CustomerAccount的比较规则混入了非accountNumber字段的判定，这个轻量探针对象因为其他字段为空，会出现永远匹配不到目标节点的问题。
• 当前代码存在逻辑不匹配：你写的deleteCustomer方法捕获了ElementNotFoundException，但目前给出的remove实现是靠delete返回值是否为null判断结果，全程没有抛出该异常的逻辑，实际运行中这个异常捕获块永远不会触发。

内容的提问来源于stack exchange，提问作者TorusWithSprinkles