客户删除后又被导入：如何堵住数据回流

客户点了删除，列表里也确实消失了。可下个月导入预约系统的文件时，姓名和手机号又回来了。作者遇到的问题是：删除操作成功了，整条数据链路却没有记住这次删除。

这篇短文值得读的地方，是把「按钮能用」和「功能兑现承诺」之间的差距讲得很具体。它给出的修复方向包括导入排除名单、手机号指纹和定时清理，也坦诚留下了一个尚未完成的安全配置。

删除为什么会被下一次导入撤销

作者最初测试了两个按钮：删除客户后，客户从列表消失；导出数据后，系统生成文件。于是，他认为工作已经完成。

后续审查沿着另一条路径检查：读完删除代码，再读导入代码。问题就在这里，导入流程根本不检查某个人是否曾经被删除。

上游的沙龙预约软件仍然保存着客户信息，店主每个月都会导出文件。应用再次导入时，会把已删除的客户当成新客户创建，姓名和手机号一并恢复。

删除是否有效，要看数据再次进入系统时会发生什么。

作者明确描述的是代码审查发现的问题，没有交代是否完整复现了客户数周后重新出现的过程，也没有提供自动化测试结果。这个区分要保留，但缺陷路径已经足够清楚：只检查删除后的页面状态，覆盖不了下一轮导入。

为什么删掉客户后，还要留一份排除记录

修复方案需要保留一点记忆，否则系统无法区分「第一次出现的客户」和「曾经要求移除的客户」。

作者选择建立排除名单。客户被删除，或发送 STOP 时，应用只保存手机号的指纹，不保留其他客户资料。以后导入文件，每一行都先检查名单，匹配就跳过。

这里的指纹，可以理解为根据手机号计算出的匹配值。为了让同一个号码始终得到相同结果，计算前要先统一成国际号码格式。文件中有空格、短横线，或者写着 +39，都不应干扰匹配。

但第二个问题紧接着出现：普通哈希能用于匹配，却不保证手机号难以被还原。

作者指出，意大利手机号的候选空间有限，拿到名单的人可以枚举号码、逐个计算哈希，再与名单比对。

应用因此增加了混入服务端秘密值的能力，这个值不与数据一起存储。不过，作者写作时尚未完成配置；秘密值缺失时，应用仍会退回普通哈希。原文没有给出具体算法，不能据此判断其密码学实现是否可靠。

我的判断

我认同作者把测试单位从按钮扩展到完整生命周期。删除、重新导入、再检查，这个顺序很短，却能发现单看页面和删除接口时漏掉的问题。

相比每次导入前由人工清理文件，导入流程统一检查排除名单，更容易持续执行。但它依赖几个前提：所有导入入口都经过检查，号码规范化规则保持一致，而且手机号能够承担匹配身份的作用。号码变更或重新分配后怎么办，原文没有说明。

排除名单也留下了需要继续设计的问题：保留多久、谁能访问、秘密值更换后如何维持匹配，作者都没有展开。不能仅凭「只存指纹」就认定问题已经彻底解决。

另外，系统会在最后一次预约过去 24 个月后匿名化客户记录，12 个月后清除消息正文；技术日志则被描述为「再过 12 个月」清理。这里日志期限的起算点没有说清。店主可以在限制范围内调整期限，cron 任务每晚执行，但原文没有提供清理结果或方案对照数据。

这是一份具体的缺陷复盘，适合借鉴检查方法，还不足以作为完整的数据治理方案照搬。

能拿来做什么

• 给客户管理或批量导入功能补一条完整验收路径：创建客户、删除客户、再次导入原文件，确认姓名和手机号不会重新出现。
• 在 Node 导入流程中集中处理号码规范化和排除检查，并用含空格、短横线、+39 的输入验证同一号码能否稳定匹配。
• 用 AI 审查这类功能时，把删除、导入和定时清理代码一起提供，要求它追踪数据如何重新进入系统，而不是只检查按钮对应的接口。