只要接了两个以上接口，重复数据就一定会出现：同一部电影在不同源里叫同一个名字、挂不同 ID。去重不是可选项，而是多源运营的基本功，好在苹果CMS对此有内建机制。
重复数据从哪来
三个来源：不同源收录了同一部片，这是主因，各源的数据结构背景见资源采集原理科普；同一源的不同镜像域名都接了，等于重复采集；旧数据换源重采时没有清理旧记录。多源并行是常态，问题不在源多，而在没做判重设计，多源的搭配见影视资源采集站大全。
判重的基本逻辑：名称加年份
跨源判重最可靠的锚点是影片名称加年份：名字相同的电视剧，只要年份一致基本就是同一部。只按名称判重会把翻拍版误杀，只按 ID 判重则完全无效——不同源的 ID 体系毫无关联，不能互相比对。
实际操作中可以给名称做一层预处理再比对：去掉「HD」「国语」「4K」这类修饰后缀、繁体转简体、全半角统一，然后再拼上年份比对。只靠程序默认的精确匹配会漏掉这些变体，人工抽查时优先挑热播片，抽二十条就能判断当前判重规则够不够用。
苹果CMS内置的去重机制
苹果CMS在采集时会按名称比对已有数据，命中则更新而不重复插入，这也是「更新模式」能跟更的原因。但内置机制主要覆盖单源场景，多源并行时如果各源命名不规范（加后缀、繁简混用），判重就会漏，此时要在选源阶段就避开命名混乱的源。
已入库重复数据怎么办
重复已经入库的清理办法：后台按名称关键词筛选，人工合并或删除冗余条目，保留数据最全的那条；批量处理前先备份数据库，处理结果可用监控看板核对总量变化。长期靠源头治理——从接口层减少重复引入，比事后清理省力得多。
清理时还要留意两组关联数据：收藏与评论挂在影片 ID 上，删除重复条目前先把 ID 迁移关系理清，否则用户收藏会批量失联，播放记录同理。删除操作安排在低峰期执行，清完立即核对影片总数与播放页可用性。
与轮询策略的配合
轮询容错场景下，同一分类会在主备源之间切换，重复风险更高，判重规则要在切源前就设计好，整体框架见多采集源轮询策略。原则是宁可少收一部，不要重复一堆。