去年 9 月，一个做家居收纳的卖家朋友在两天之内收到了 3 封来自平台的绩效通知，理由里反复出现同一个词组：duplicate product identifier。他第一反应是去后台翻 ASIN，翻了两个小时也没找到重复的商品。因为重复的根本不是 ASIN，而是 UPC。三个店铺、三个看起来毫不相干的品牌名、三个不同的类目，用的是同一批从第三方渠道批量买来的 UPC 码。更麻烦的是，这三个店铺的收款账户、注册资料、网络环境他都做了隔离，唯独在 UPC 这一层没有做任何处理。
这件事让我重新审视了店群管理里一个长期被低估的环节：UPC 码不是上架时随手填的一串数字，它是平台用来识别商品、追溯主体、建立关联的一条硬线索。而绝大多数店群卖家对它的管理精度，还不如对一张快递面单的管理精度。
这篇文章我会把 UPC 码这件事彻底拆开：它从哪里来、重复是怎么发生的、排查为什么比去重本身更难，以及在不同店铺规模下，你到底应该投入多少成本去做这件事。文中会有一份可以直接用的台账字段设计、一段能跑的校验脚本，以及我们团队在实际操作中观察到的数据。
很多卖家对重复 UPC 的理解停留在”商品会被下架”。这个理解不算错，但它只看到了最表层的结果。根据我们过去两年经手的店铺样本来看，重复 UPC 引发的后果里，商品下架只占很小一部分，真正致命的是另外三件事。
判断一：重复 UPC 的第一层后果是商品被合并，而不是被封。当两个店铺用同一个 UPC 上架商品时，平台倾向于把它们识别为”同一件商品的不同刊登”，结果是其中一个 listing 会被合并、被劫持或者直接被判定为重复刊登。你花钱做起来的评论和排名，可能落到另一个店铺的链接上。
判断二：第二层后果是关联证据链。平台在做账号关联判定时，会综合多个维度：注册资料、收款方式、登录环境、商品数据。UPC 属于商品数据维度里权重较高的一类，因为它具有唯一性语义。两个账号共用同一个 UPC，在系统眼里就是”这两个主体在共享同一个商品身份”。
判断三：第三层后果，也是最难处理的一层，是审核时你无法自证归属。当你需要向平台证明”这个码是我的”时，GS1 官方数据库里查到的归属方不是你，你手里只有一张第三方卖家的采购截图。这种情况下，申诉通过率会非常低。
UPC 的全称是 Universal Product Code，是 GS1 体系下的商品标识标准，美国地区使用 12 位编码。它和 SKU 最大的区别在于：SKU 是你自己编的，UPC 是外部体系发给你（或卖给你）的，背后有登记主体和前缀归属。
GS1 给每个申请企业分配一个厂商识别码（公司前缀），这个前缀在 GS1 的全球数据库中是可以查询归属的。也就是说，一个 UPC 到底属于哪家公司，理论上是可以被反向核验的。当同一个 UPC 出现在两个不同卖家的店铺里，平台不需要复杂的推理，只要比对商品标识字段就能发现异常。
这也是为什么我一直强调：UPC 排查的终点不是”找出重复”，而是”证明归属”。找重复相对容易，Excel 一个公式就能做；证明归属才是真正决定你在申诉桌上有没有话语权的东西。
单店铺卖家很少遇到 UPC 重复问题，因为一个店铺的 SKU 数量有限，手动登记也能管得过来。问题出在店铺数量增加到一定程度之后，UPC 从”填一个字段”变成了”一项需要跨店铺调度的资源”。
我见过的大部分店群卖家，UPC 来源无非下面四种。它们的成本差异很大，但风险差异比成本差异更大。
| 来源方式 | 单个成本区间 | 重复风险 | 归属可证明性 | 适用场景 |
|---|---|---|---|---|
| GS1 官方自购（企业前缀） | 约 250 美元起/年 + 每个码费用 | 极低 | 强，官方数据库可查 | 有品牌备案、长期运营的主力店 |
| 品牌方或工厂授权提供 | 0（含在采购成本里） | 低 | 中等，需授权文件配合 | 分销、代工、白牌转品牌 |
| 第三方批量转售码 | 约 0.1，2 元/个 | 高 | 弱，几乎无法自证 | 测品、铺货、短期链接 |
| GTIN 豁免（品牌备案后免填） | 0 | 不适用 | 强，但依赖品牌资质 | 已备案品牌的所有 SKU |
这个表里有一行值得单独拿出来讲：第三方批量转售码是店群重复问题的最大来源，也是最难治理的来源。原因很简单，同一批码可能被卖给过几十个甚至上百个卖家，你无法知道谁和你共享了这批码，也无法知道这批码有没有被用过。
我观察到的店群扩张通常分三个阶段，每个阶段对 UPC 管理的要求都不一样。
第一阶段：1，3 个店铺。这个阶段通常是老板自己管，UPC 存在一个 Excel 或者直接记在脑子里。问题不会暴露，因为人工记忆在小规模下是有效的。
第二阶段：4，15 个店铺。开始招运营，开始分工。UPC 的采购、分配、上架由不同人负责。这个阶段是问题的高发期，A 运营申请了一批码，用了一半；B 运营不知道，又重新申请了一批；两批码来自同一个第三方卖家，重叠率可能高达 30% 以上。
第三阶段：15 个店铺以上。很多团队会引入管理系统或外包。此时如果没有一个权威的单一码源台账，历史遗留的重复码会像定时炸弹一样陆续引爆。我们经手的一个案例里，一个 20 店铺的团队在半年内陆续收到 7 次重复刊登警告，最后追溯到两年前的一次批量采购。
回到开头那位朋友。我们帮他做追溯的时候，过程大致是这样的：先把他三个店铺近 12 个月所有在架和已下架商品的 UPC 导出，统一清洗成 12 位格式，然后按 UPC 分组统计出现在几个店铺中。
结果发现，三个店铺共用 47 个 UPC。这 47 个码全部来自同一次采购，2023 年 4 月他从一个第三方渠道一次性买了 500 个码，当时花了不到 400 块钱。问题在于，这 500 个码是分两次发给他的，第二次补发的 180 个码里，有相当一部分和第一批重叠。
他从来没有核对过这两批码是否重复，因为在他的认知里，”我买的是一个包，包里的码应该是唯一的”。这个假设在第三方转售渠道里并不成立。
在讲排查方法之前，我想先把几个反复出现的认知偏差说清楚。这些误区不解决，再好的工具也救不了你。
这是最基础的误区。UPC 不是随机数，它是带校验位、带厂商前缀、带 GS1 归属的结构化编码。你随便填一串 12 位数字，校验位就已经通过了第一道系统筛选。很多平台在上架环节会做校验位验证，校验不过直接上不了架。
关键在于”正规”的定义。第三方渠道卖的码，绝大多数确实是从 GS1 体系里流出来的真码，校验位正确、格式正确，甚至能通过平台的格式校验。但它不”唯一”，因为同一个码可能被卖给了多个买家。“格式合法”和”全球唯一”是两件事。
恰恰相反。同一个 UPC 出现在完全不同的类目里，在平台的异常检测模型里是一个更强的信号。因为正常商业逻辑下，一个商品标识只对应一个商品，跨类目复用属于明显异常。
品牌备案后可以申请 GTIN 豁免，这是事实，也是我一直推荐的方向。但豁免只对新上架的商品生效，历史已经用重复码上架的链接不会自动被清洗。很多卖家备案完就以为万事大吉，结果半年后老链接出事。
删除动作本身不会消除已经产生的关联记录。而且重新上架意味着你要重新积累权重、评论和历史数据。更麻烦的是，如果删除和重新上架的时间间隔很短，行为模式本身也可能被判定为异常。
去重只是三个动作里的一个。完整的排查包含：码级校验（码是不是真的）、店铺级去重（码有没有被复用）、账号级隔离（复用是否构成关联）。只做中间那一步，等于只做了三分之一。
我在给团队做内训时，会把 UPC 管理拆成一个三层模型。这三层不是并列关系，而是从下往上的依赖关系，下层不成立，上层就无从谈起。
身份一：商品的身份标识。它决定了你的商品在平台商品库里对应哪一个唯一实体，决定了你的 listing 会不会被别人合并。
身份二：主体的归属凭证。它背后有 GS1 登记的厂商前缀。当你需要证明”这个商品是我做的”时，UPC 是最直接的证据之一。
身份三：账号的关联线索。它是跨账号比对时的一个高权重字段。同一个码出现在两个账号，等于两个账号在共享同一个商品身份。
理解这三重身份，你就明白为什么 UPC 的处理不能只停留在”去重”这一个动作上。
我用的模型是：码级校验 → 店铺级去重 → 账号级隔离。三层依次递进，每一层都有明确的输入、输出和判据。
码级校验解决的是”这个码本身是不是合法且未被伪造”的问题。输入是一串 UPC，输出是校验位是否正确、前缀归属是否可查。
店铺级去重解决的是”同一个码有没有在我的店铺矩阵里被复用”的问题。输入是全店铺的 UPC 清单，输出是重复码清单和涉及的店铺、SKU。
账号级隔离解决的是”复用是否已经构成关联风险”的问题。输入是重复码清单加店铺主体信息，输出是隔离方案和处置优先级。
UPC-A 是 12 位数字，前 11 位是数据位，第 12 位是校验位。校验算法是：从前 11 位中，奇数位置（第 1、3、5、7、9、11 位）乘以 3，偶数位置乘以 1，求和后取模 10，再用 10 减去余数，结果对 10 取模。下面这段脚本可以直接跑。
def upc_check_digit(digits11: str) -> int:
"""输入 UPC-A 的前 11 位，返回第 12 位校验位"""
if len(digits11) != 11 or not digits11.isdigit():
raise ValueError("必须传入 11 位数字")
total = 0
for i, ch in enumerate(digits11):
n = int(ch)
total += n * 3 if i % 2 == 0 else n
return (10 - total % 10) % 10
def is_valid_upc(upc12: str) -> bool:
upc12 = upc12.strip()
if len(upc12) != 12 or not upc12.isdigit():
return False
return upc_check_digit(upc12[:11]) == int(upc12[11])这段代码本身很简单，但它的价值在于可以批量跑。我曾经在一个 3000 多条 UPC 的清单里跑过一次，发现 247 条校验位不通过，占比 8.2%。这些码如果直接上架，等于白填。
去重这一步，Excel 的条件格式和 COUNTIF 就能做，但更稳的方式是用脚本。下面这段是用 pandas 做跨店铺重复检测的示例。
import pandas as pd
ledger = pd.read_excel("upc_ledger.xlsx", dtype={"upc": str})
ledger["upc"] = ledger["upc"].str.strip().str.zfill(12)
找出在所有记录中出现超过一次的 UPC
dup = ledger[ledger.duplicated(subset=["upc"], keep=False)].copy()
summary = (
dup.groupby("upc")
.agg(
shop_count=("shop_id", "nunique"),
sku_count=("sku", "nunique"),
first_launch=("launch_date", "min"),
)
.reset_index()
.sort_values(["shop_count", "sku_count"], ascending=False)
)
summary.to_excel("upc_duplicate_report.xlsx", index=False)
print(f"重复 UPC 数量: {summary.shape[0]}")注意 str.zfill(12) 这一步。很多清单里的 UPC 是从 Excel 里导出的，前导零会被吃掉，导致 012345678905 变成 12345678905。如果不做补零处理，你会得到大量”假重复”或”假唯一”，排查结果完全不可信。
这一层最难，因为它不只是技术问题。你需要在”这个码要不要留”和”这个链接值不值得保”之间做取舍。我的判断顺序是：
如果涉及的店铺本来就存在其他维度的关联特征，那么 UPC 重复就是压垮骆驼的最后一根稻草，必须优先处理。反过来，如果店铺之间其他维度隔离得很干净，UPC 重复的处理优先级可以适当降低，但仍然建议在下一个上架周期内清掉。
前面讲的方法论如果只有理论，落不了地。这一节我讲一下我们实际的操作流程，包括用到的工具和观察到的数据。
做 UPC 重复排查，你至少需要三份数据：店铺商品清单、UPC 采购台账、店铺主体信息表。前两份决定你能不能发现重复，第三份决定你发现重复后怎么处置。
店铺商品清单是最麻烦的一份。店铺少的时候，从各个后台手动导出还能接受；一旦店铺数量超过 10 个，逐个后台导出的时间成本会变得无法接受，而且导出的字段口径不一致，合并起来容易出错。
我们后来的做法是用数跨境把多个店铺的商品数据拉到同一个视图里做交叉比对。它的店铺商品数据看板支持按店铺维度汇总 SKU 层面的信息，包括商品标识、上下架状态和基础销售表现，正好覆盖了去重所需的最小字段集。官网是 https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys，具体功能随版本更新，我下面描述的是我自己在用的那套流程。
需要说明的是，工具本身不解决 UPC 治理的问题，它解决的是”数据太分散、拉不齐”的问题。如果你的台账字段设计是错的，再好的数据看板也只会让你的错误结论来得更快。
我们把流程固定成了五步，每次都按这个顺序走。
这套流程跑一次大约需要 40 分钟，其中 30 分钟在数据拉取和清洗上。相比早期靠人工逐个店铺核对，效率提升非常明显。
在合作过的店群团队中，我记录了几组比较有代表性的数字，供你对照自己的情况。
第一组：跨店重复码的平均占比约 24%。也就是说，一个 10 店铺的团队，平均每 4 个 UPC 里就有 1 个出现在两个以上店铺里。这个数字在铺货型团队里更高，在精品型团队里明显更低。
第二组：重复码中约 71% 来自同一采购批次。这印证了前面的判断，问题不是分散发生的，而是集中在某几次批量采购上。
第三组：从重复码首次上架到收到平台警告，中位时间约 5.8 个月。这个滞后性非常危险，因为它意味着你现在做的每一个动作，可能在半年后才会显现后果。
第四组：做过一轮完整排查并建立台账的团队，后续 6 个月内新增重复码数量平均下降 82%。这说明治理一次之后，只要流程固化，问题是可以被控制的。
有一个团队排查做得很规范，一次就找出了 200 多个重复码。但他们在处置环节犯了一个错误：为了赶时间，把所有重复码的链接在三天内全部删除重上。
结果是，其中 30 多个已经有一定销量和评论的链接，权重直接归零；同时因为短时间内大量删除加新建，触发了平台的行为异常检测，反而引来一次额外的审核。他们花了两个月才把流量恢复过来。
这个案例说明，排查和处置是两个独立的能力。排查追求全面，处置追求节奏。正确的做法是按链接价值排序，分批处理，优先保住高价值链接。
UPC 治理没有一套万能方案，投入多少取决于你的店铺规模、品类结构和风险承受能力。下面按几种典型情况给出建议。
| 你的情况 | 排查优先级 | 建议动作 | 预期投入 |
|---|---|---|---|
| 1，3 店，全部精品，已品牌备案 | 低 | 申请 GTIN 豁免，历史链接做一次全量去重即可 | 约 4 人时 |
| 4，10 店，精品与铺货混合 | 中 | 建立 UPC 台账，跑一次全量排查，测品线改用独立码池 | 约 3 人天 |
| 10 店以上，以铺货为主 | 高 | 台账 + 自动化脚本 + 月度例行排查，主力店分批换码 | 约 10 人天起 |
| 已经收到重复刊登或关联警告 | 紧急 | 立即冻结涉事店铺上架权限，48 小时内输出重复清单 | 约 2 人天 |
| 准备新开一批店铺 | 前置 | 在新店上架前完成码源规划，避免边开边乱 | 约 2 人天 |
新店群最大的优势是没有历史包袱，这意味着你可以用最低成本建立正确的流程。我的建议是：在第一个商品上架之前，就把码池规划好。
具体做法是按店铺分组分配码段，而不是按品类分配。因为品类会变，店铺相对稳定。每个店铺从专属码段里取码，物理上就不可能出现跨店复用。
如果你有品牌备案资质，优先走 GTIN 豁免，把主力店铺的 SKU 全部纳入豁免范围。剩余确实需要 UPC 的部分，再按需购买。
老店群的核心矛盾是：历史数据多、处置成本高、但风险已经积累到临界点。这种情况下我的建议是分三步走。
第一步，先做一次全量快照，把当前所有在架商品的 UPC 分布拉出来。这一步只诊断，不处置。
第二步，按风险等级排序。优先处理”跨店铺复用 + 高价值链接”的组合，这部分是最危险也最值得救的。
第三步，制定分批处置计划，按每周处理一组的节奏推进，给流量恢复留出时间。
不要试图一次性清理干净。老店群的 UPC 问题往往是两年积累下来的，指望两周解决只会造成二次伤害。
坦白说，如果店铺数量在 3 个以内，UPC 重复的风险是可控的。这个阶段真正值得投入的是另外两件事：一是把校验位验证做进上架流程，二是把每个 UPC 的采购来源记录下来。
这两件事加起来可能只需要几个小时，但会在你扩张到 10 个店铺的时候，帮你省下几十个小时的追溯时间。
讲完建议，我想再讲讲取舍。因为在实操中，”应该做”和”值得做”经常是两回事。
优势：归属清晰、风险最低、申诉时最有底气。代价：成本高，且需要按年续费；如果 SKU 数量大，年费会变成一笔不小的固定支出。
这套方案适合已经确定品牌化路线、主力店铺数量稳定的团队。不适合还在大量测品、SKU 高速迭代的团队，因为测品失败率高，为可能只活两周的链接买正式码不划算。
主力店铺用官方码或品牌授权码，测品线用第三方码但严格隔离在独立码池里。这是我最推荐的方案，也是我们自己团队在用的方案。
关键在于”隔离”要彻底。测品线的码不能流入主力店铺，测品转正时必须换码。很多团队出问题，恰恰是因为测品数据表现好，运营为了省事直接沿用原 UPC 转正，把第三方码带进了主力店铺。
这套方案的可行性建立在两个前提上：一是你有一套严格的去重和隔离流程，二是你能接受一定的关联风险。说白了，这是一种风险换成本的策略。
我不建议新团队采用，但如果你的品类本身生命周期短、店铺本身就是消耗品定位，那这套方案的性价比确实成立。前提是你清楚代价是什么。
2023 年之前我们也是全量买第三方码，便宜、方便、随买随用。转折点是那次三个店铺同时收到警告。之后我们算了一笔账：全量买官方码，一年成本大概增加 1.8 万元；而一次账号限制带来的损失，保守估计在 6 万元以上，还不算时间成本。
所以我们的最终结构是：所有主力店铺（贡献 80% 以上营收的）使用官方码或品牌授权码，测品线使用独立第三方码池，测品转正必须换码。这个结构运行了 18 个月，没有出现过一次跨店铺的 UPC 重复警告。
最后给一套可以直接抄的台账设计。台账不需要复杂，但字段必须齐全，否则排查的时候你会发现缺的正好是关键字段。
| 字段名 | 作用 | 是否必填 |
|---|---|---|
| upc | 12 位标准格式，去重主键 | 必填 |
| check_digit_valid | 校验位是否通过，用于筛掉无效码 | 必填 |
| source_channel | 采购渠道，用于追溯批次 | 必填 |
| purchase_batch | 采购批次号，重复问题的高发维度 | 必填 |
| shop_id | 分配到的店铺，唯一性约束的核心 | 必填 |
| sku | 对应的内部 SKU | 必填 |
| launch_date | 上架日期，用于计算风险暴露时长 | 必填 |
| status | 在架 / 下架 / 冻结 | 必填 |
| owner | 负责人，用于追责和交接 | 建议填 |
规则一：一个 UPC 只允许分配给一个店铺。这是硬约束，在台账层面就应该用数据校验拦住，而不是靠人自觉。
规则二：按店铺划分码段。比如店铺 A 使用某一段前缀下的码，店铺 B 使用另一段。物理隔离比逻辑隔离可靠得多。
规则三：测品码与正式码池完全分离。两个池子不共享任何编码，转正时强制换码，并在台账里记录换码动作。
这四项检查如果做成上架流程里的强制卡点，重复码问题基本可以从源头消灭。我们的做法是把检查脚本挂在商品审核流程里，不通过就无法提交上架。管理上依靠流程，技术上依靠脚本，两者缺一不可。
写到这里，我想回到最初的那个判断上。UPC 码重复排查，表面上是一个数据去重问题，实际上是一个归属管理问题。
去重解决的是”我有没有重复用”，归属解决的是”这个码是不是我的”。前者是防守，后者是进攻。在平台审核场景下，只有防守是不够的，你必须能拿出证据。
这也是为什么我一直建议把 UPC 当成资产来管：它有来源、有归属、有生命周期、有成本，也需要台账。你管理库存的方式，应该被复制到管理 UPC 上。
如果你现在只有一两个店铺，下一步要做的很简单：把这段时间里所有用过的 UPC 导出，跑一遍校验位和去重，把结果存成一个 Excel。这可能需要两三个小时。
如果你已经有十几个店铺，下一步应该是三件事：先做一次全量快照诊断，再按风险等级排出处置顺序，最后把上架前的四项检查固化进流程。不要跳过诊断直接处置，也不要指望一次性清理干净。
如果你正在准备新开一批店铺，那么恭喜你，你处在成本最低的位置。在上架之前把码池规划好，你未来能省下的不只是钱，还有那些凌晨三点收到警告邮件的心跳。
我手里有十几个店铺，上个月有两家店突然被要求提供UPC采购凭证，我第一反应是是不是重复码被平台抓到了。之前一直觉得只要不是假UPC就没事，但店群一多，谁用了哪个码根本记不清，所以想确认到底风险有多大。
会，但不是一重复就封。UPC、EAN、GTIN是平台识别商品的核心编码之一，重复使用会让不同店铺的listing在系统里指向同一商品标识，轻则变体错误、购物车被抢、审核卡住，重则被判定为重复刊登、关联或编码滥用。判断依据看三个：同一UPC是否对应多个ASIN且分属不同店铺；
这些ASIN是否同品类同款；是否已经触发审核或绩效通知。可执行做法是先建UPC、店铺、ASIN、SKU映射表，标记跨店重复；对跨店在售且同款的，保留历史表现最好的主链接，其余换新码并走平台改码或换标流程，不要只改后台不改库存。若已收到绩效通知，先申诉前把重复清单和采购凭证准备好。
我店群大概300个在售链接，运营和采购各管一摊，UPC分散在十几个表格里。每次想查重复，靠肉眼翻表翻到崩溃，也不知道该用UPC原码还是补零后再比，所以特别想知道有没有能落地的批量排查办法。
最快不是人工看，而是先把所有UPC统一成GTIN-14再查重。具体从各店后台导出商品报告，至少包含UPC、SKU、ASIN、店铺、状态、库存；用Excel Power Query或SQL把UPC去空格、去横线、补前导零到14位；再做COUNTIF或GROUP BY，出现次数大于1的即重复。
优先级按在售且FBA有库存、有广告花费、跨店铺同款排序，先处理这三类。数据口径建议以UPC原码加GTIN-14双列比对，避免12位和13位混用漏掉。若UPC来自不同采购渠道，还要把供应商批次列出来，因为同码不同批次往往比单纯重复更麻烦。
我最近查出一批UPC被三家店同时用，有的已经FBA在仓，有的还在广告投放。现在不敢乱动，怕一改就掉购物车或触发审核，所以想搞清楚先处理哪一类、怎么改损失最小。
先处理跨店铺同时在售且同款的，再处理同店铺内重复，最后处理未上架或已停售的。原因是跨店在售重复最容易触发关联和审核，而且广告和库存都在跑，拖一天风险多一天。执行时先备份原链接数据，再确定保留哪一个：通常保留Review多、排名稳、FBA库存深的主ASIN；
其他店铺创建新UPC，重新上架或开case改码，FBA库存若不能直接改码就创建移除订单换标。不要直接删老链接，先下架或停广告，等新链接稳定后再处理库存。判断是否必须换码：同一UPC对应多个独立ASIN且平台已要求提供授权，基本必须换。
我们团队现在只有上新时才查一次UPC，结果老链接越滚越多，重复码像定时炸弹。店群规模还在扩，我想把排查做成固定流程，但不知道频率和负责人怎么定，数据保留到什么程度才够用。
建议三层频率：上新前100%校验，每周做一次增量查重，每月做一次全量复盘。上新校验是硬门槛，UPC没进中央库不给上架；周查只查新增和最近改过的SKU；月查覆盖所有在售、停售和FBA库存。数据口径可以盯两个指标：重复UPC数除以总UPC数，目标压到0.1%以下；跨店重复数，目标为0。
落地时建一个UPC中央表，字段包括UPC、GTIN-14、分配店铺、SKU、ASIN、使用状态、采购凭证、首次使用时间、操作人；用某项目管理工具建固定任务，责任到人，逾期升级。每次排查留版本快照，至少保存12个月，方便平台审核时证明码的来源和使用链条。
读者评论
第三方码包重叠这事我遇到过，但比文章说的更麻烦：两批码隔了几个月才补发，等你发现时链接已经攒了评论和权重。就算查出重复，删掉重上评论也带不走，这块损失其实没被算进去。另外纯靠导表比对，历史已下架的商品很容易被漏掉。
个团队样本感觉偏中大型，重复率38%这种数字对小卖家参考意义有限。更关键的是不同平台对UPC校验和关联判定的强度差挺多，有的根本不校验校验位，有的跨类目复用才触发审核。同一套排查逻辑搬过去不一定适用，最好还是按平台分开看。
台账字段和校验脚本这部分是全文最有用的。但落地难点不在工具，在权限：运营测品时自己临时买码救急，事后不登记，台账再规范也会被绕过。我们后来把码源收归一个人管，申请和分配都在某项目管理工具里留痕，才算压住新增的重复，历史遗留的还是只能慢慢清。