婚礼名单里删掉一个重名条目，为什么未必等同于合并

婚礼名单出现两条似乎属于同一个人的记录，最直观的想法可能是删掉其中一条，让人数看起来恢复正常。但Joy的Merge Duplicate Guests帮助页将合并与删除分开讨论，原因不只是列表少一行：记录里还可能带有答复以及邮件跟踪信息。[1]

原页用Michael与Mike说明重复怎样发生：策划者手工录入一个名字，宾客回复时采用另一个名字，名单便留下两个条目。这是厂商给出的示例，不是让整理者把所有昵称、同名或相似拼写自动认定为同一个人。对于尚未确认的两条记录，姓名近似本身仍不能替代实际身份关联。

在合并说明中，Joy特别把已有RSVP答复的条目与保留答复联系起来，指出选取记录的先后会影响它们能否留下。这个条件说明，合并处理的不只是显示姓名，还包括记录已经承载的回应。本篇只解释其资料含义，不提供真实名单的点击、合并或删除步骤，也没有验证某个答复是否已经保存。

电子卡片与邮件历史提供了另一项区别。该页说，删除已经发送过eCard或邮件的宾客，会失去相应跟踪信息；合并则保留这类信息。若一份工作交接只写“重复已去掉”，接收者仍不知道原来的通信记录发生了什么。列表外观看起来更短，不足以证明保留了需要继续跟进的历史。

Joy的Guest List Overview把这层关系放回个人资料：宾客profile可查看RSVP答复、邮件跟踪历史及联系资料，重复合并则将同一人两条记录连为一条。[2] 因此，它不同于将两个真实宾客归成一个家庭邀请组。前者处理同一人的重复条目，后者仍包含不同的人；不能为了得到较小人数而把两种关系混在一起。

假设一份仅用于说明的交接备注写“确认是同一人的两个条目，原有回应与通信历史需对照”，它比“删一个名字即可”多保留了问题所在。这是本文的阅读分析，不是Joy规定的表格，也没有处理个人信息。两页分别标示2025年8月8日与2026年3月26日，本篇不将显示日期扩作每个功能首次上线时间。它不执行名单清理、发信或隐私合规判断，只说明为何记录合并需要关注所保留的信息，不能由行数减少代替这项核对。