去年双十一前两周，我帮一个做家居类目的朋友做数据体检。他手上有 4 个店铺、大约 1.2 万个在售 SKU，我用一段脚本把他后台导出的 UPC 字段做了频率统计，结果出来的时候他自己都不太相信：有 217 个 UPC 在两个以上店铺里被重复使用，其中 63 个还挂在完全不同的类目下，同一个 UPC，一个链接卖窗帘，另一个链接卖宠物垫。更麻烦的是，其中 11 个重复码已经各自出了单，退货率是店铺均值的 3 倍。
这不是”数据脏”三个字能概括的事，它暴露的是 UPC 从采购、分配、录入到上架的整条链路没有闸门。这篇文章就把 UPC 码的日常管理拆开讲，重点放在重复码的排查上：怎么发现、怎么判断该不该处理、怎么处理才不炸链接。
在展开细节之前，我想先把三个判断给出来。这三个判断是我自己在几十次数据清洗和账号体检里反复验证过的，它们决定了你后面每一个动作的方向。如果方向错了，工具再贵、脚本再花哨，也只是把错误做得更快。
过去三年我经手过三十多个跨境卖家的 UPC 数据，我复盘过每一次重复码的产生路径，结论很一致：重复码是人为动作的副产品，不是系统故障。真正因为平台或 ERP 系统 bug 产生的重复码，我一次都没见过。
最常见的动作有五个：批量导入时整列复制粘贴、多店铺共用一份 UPC 表格、运营为了赶活动临时借用其他链接的码、供应商给的码本身就是二手回收码、以及从竞品页面扒下来的码被直接复用。这五个动作有两个共同点，都是”快”的产物，都是”省事”的选择。
所以我的第一个判断是：不要从数据入手查重复码，要从动作入手查。你只要问清楚”这个 UPC 是从哪张表、哪个人、哪个时间点进入系统的”，80% 的重复码当场就能定位。剩下的 20%，才需要动用校验位、GS1 数据库这些技术手段。
我见过太多团队排查重复码的方式是：先打开 Excel 做条件格式高亮，然后逐行肉眼比对，找到一条改一条。这种方式在 500 个 SKU 以内还能忍，超过 2000 个 SKU 就彻底失效，因为重复码不是孤立的，改一个会牵动另一个。
正确的顺序应该是四层漏斗：格式校验 → 主数据归属 → 平台映射 → 物理核对。这四层是层层收窄的，前一层没跑完，后一层的结论就是不可靠的。我把这个漏斗放在第四章详细讲，这里先给结论：先做机器能做的，再做机器做不了的。
这是我感受最深的一条。同一条重复码，在”刚从供应商拿到码、还没录入”的时候处理，成本接近于零；在”已录入主数据但还没上架”的时候处理，成本是一个人工小时；在”已经上架但没出单”的时候处理，成本是重新走一遍上架流程；一旦”已经出单并有评论”，成本就变成了换码、迁移评论、处理历史订单和可能的账号风险。
我给这个成本结构做过一次粗略测算，用的是我自己经手的两个案例加一个模拟情景推演。数据不是行业统计，是我自己的样本，但趋势非常清楚。
看到这张图之后，我对 UPC 管理的态度就变了。UPC 日常管理的核心不是”清洗”，而是”拦截”。一个只在月底做一次数据清洗的团队，和一个在录入环节就做校验的团队，做的是两件完全不同的事，成本差着两个数量级。
要讲清楚重复码排查，得先讲清楚 UPC 这个码在你的业务里到底扮演什么角色。很多运营把 UPC 当成一个”填进去就行”的字段，这恰恰是问题的起点。
我用一张表把这四个概念的关系说清楚，这是排查重复码之前必须建立的基本认知。搞混这四个概念，你会发现自己在错误的数据集里找重复。
| 名称 | 本质 | 位数 | 是否全球唯一 | 在你的业务里承担什么 |
|---|---|---|---|---|
| GTIN | 全球贸易项目代码，是一整套编码体系的总称 | 8/12/13/14 位 | 是 | 数据模型里的标准字段，建议主数据库统一存 GTIN-14 |
| UPC | 北美零售系统常用的编码，属于 GTIN 体系 | 12 位（UPC-A） | 是 | 亚马逊美国站等平台的主要必填字段 |
| EAN | 欧洲零售系统常用的编码，属于 GTIN 体系 | 13 位（EAN-13） | 是 | 亚马逊欧洲站、日本站等平台使用 |
| ASIN | 亚马逊平台内部的商品编号 | 10 位字母数字 | 平台内唯一 | 平台侧的唯一键，与 UPC 是多对一或一对多映射 |
这里最关键的一句话是：UPC 和 EAN 是同一个东西的不同长度表达，而 ASIN 是平台自己发的身份证。一个 UPC 理论上只对应一个物理商品，但可以对应多个 ASIN（比如同一款产品在美国站和欧洲站有不同 ASIN，或者在合规允许的前提下被多个卖家建立链接）。
所以当你说”重复码”的时候，先要明确你指的是哪一种重复：是同一个 UPC 出现在两个主数据记录里，还是同一个 UPC 对应了两个本不该共存的 ASIN，还是两个不同商品被错误地赋予了同一个码。这三种情况的处理方式完全不同。
我把这几年见过的重复码归了五类，每一类都有明显的”指纹”。你只要看一眼重复的模式，基本能判断出它属于哪一类。
注意这张图里我没有用”行业平均”这种说法，因为样本只有三个卖家、486 条记录，它不具备统计代表性。但它的结构很稳定：前两类永远是大头。这意味着如果你的排查方案只覆盖单店铺、只覆盖已上架商品，你天然就漏掉了将近四分之一的问题。
我把前面提到的那个家居卖家的案例完整讲一遍，因为它的每个环节都很典型。
这家卖家有两个运营，各自负责两个店铺。去年 8 月，为了赶一个平台活动，运营 A 把自己店铺的一批 UPC 表格直接发给了运营 B，让 B 快速把 300 个新品上架。B 因为时间紧，没有做任何去重，直接批量导入。
这批 300 个 SKU 里有 47 个 UPC 是 A 店铺正在用的。导入的时候系统没有任何提示，因为跨店铺校验在当时的流程里根本不存在。三个月后，A 店铺开始陆续收到”商品详情页不一致”的绩效警告，一共 9 条，涉及 6 个 ASIN。
排查过程花了两天半。第一天全部花在”定位”上，因为两个店铺的后台是分开的，导出数据、对齐字段、写比对脚本，就用了大半天。第二天和第三天处理已经出单的 6 个 ASIN，其中 2 个有评论，需要走评论迁移流程。
最后算下来，这次事件的直接人工成本大约 20 个人工时，间接影响是 A 店铺那 6 个 ASIN 的排名在两周内明显下滑。而这 47 个重复码，如果当时在导入前跑一次校验，成本是 5 分钟。
误区比错误更麻烦，因为错误会被报错拦住，误区会让人一路走下去还以为自己做对了。这五个误区我几乎在每一家都见过至少一个。
这是我见过后果最严重的做法。运营发现两个记录用了同一个 UPC，第一反应是把其中一条的 UPC 字段清空或者改成别的码。问题在于，你删掉的那个码可能正挂着一个已经出单的 ASIN。
UPC 在很多平台上是 listing 的唯一标识之一，随意修改会触发重新审核，严重的会直接导致 ASIN 被下架或合并。正确的做法是：先判断哪一条是”主记录”，哪一条是”从记录”，再决定是迁移还是停用。
正规渠道买的 UPC 确实是唯一的，但”唯一”指的是 GS1 不会把同一个码卖给两个人，它不保证你不会在自己内部重复使用。
我经常用一个比喻：GS1 给你的是一张身份证号，它保证号码不重复，但它管不了你拿这张身份证去开几个银行账户。内部重复使用，仍然是你的流程问题。而且正因为它”看起来是正规的”，很多团队反而放松了内部校验。
Excel 的”删除重复项”是在一列内部去重，它解决的是”同一列里出现两次”，但你面对的问题通常是”这个码在另一个店铺的另一张表里出现过”。这是跨表、跨店铺、跨文件的问题，单表去重根本覆盖不到。
更麻烦的是，Excel 去重会把整行删掉，而不是只标记 UPC 字段。我见过有人用这个功能之后，直接把几条正常商品记录连带删了。
不同平台对 UPC 的要求确实不一样。亚马逊美国站对 UPC 校验最严，欧洲站更看重 EAN 和合规文件，一些新兴平台甚至允许你自定义商品编号。但这不代表重复码在其他平台就无害。
原因在于，很多平台的商品库是打通的，或者会被第三方数据服务商抓取比对。你在一个平台上的重复码，可能通过数据比对影响到另一个平台的商品合并逻辑，甚至影响你的品牌备案。
SKU 是你自己的内部编码，可以随意定义；UPC 是带校验规则的全球编码，不能随意定义；ASIN 是平台发的，你只能申请不能创造。这三者的生命周期和唯一性约束完全不同。
把它们放在同一个字段里管理，是重复码排查做不下去的根本原因。我的建议是主数据表里至少保留四列：内部 SKU、GTIN-14（标准化后的 UPC/EAN）、平台 ASIN、平台站点。四列分开存，比对的时候才有抓手。
这一章是全文的核心。我把自己实际使用的排查流程整理成四层漏斗，每一层解决一个特定问题，且必须按顺序执行。跳过任何一层，结论都会失真。
很多人一上来就比对字符串，结果发现一堆”重复”，其实是格式问题造成的假象。同一个商品，在 A 表里存的是 12 位 UPC，在 B 表里存的是带前导零的 13 位 EAN，字符串比对当然不相等；反过来，两个不同的码如果位数不同，在某些简化的比对逻辑里又可能被误判为相同。
所以第一层要做的是标准化：全部统一转成 GTIN-14，再做比对。UPC-A 转 GTIN-14 的规则是在前面补两个 0 加一位包装指示符；EAN-13 转 GTIN-14 是在前面补一个 0。
同时，这一层还要做校验位验证。GTIN 的最后一位是校验位，算错校验位的码本身就是无效码，这类”无效码”往往会被误当成重复码来处理。下面这段是我自己一直在用的校验位计算逻辑。
def gtin_check_digit(first_n_digits: str) -> int:
"""
计算 GTIN-8/12/13/14 的校验位
first_n_digits: 去掉校验位之后的前缀字符串
规则：从右往左，奇数位权重 3，偶数位权重 1，求和后取 10 的补数
"""
if not first_n_digits.isdigit():
raise ValueError("输入必须为纯数字")
total = 0
reversed_digits = first_n_digits[::-1]
for idx, ch in enumerate(reversed_digits):
weight = 3 if idx % 2 == 0 else 1
total += int(ch) * weight
return (10 - total % 10) % 10
def is_valid_gtin(code: str) -> bool:
code = code.strip()
if len(code) not in (8, 12, 13, 14) or not code.isdigit():
return False
return gtin_check_digit(code[:-1]) == int(code[-1])把这段逻辑跑一遍你的全量 UPC 字段，你通常会得到两个惊喜：一是一批校验位错误的无效码被揪出来了，二是标准化之后，原本”看起来不重复”的记录里又冒出一批真正的重复。
格式统一之后，重复码就浮出来了。但这时候不要急着改，先判断归属。我给这一步定义了三个判断维度，按优先级排序。
这里我要强调一个判断原则：能用”停用从记录”解决的，就不要用”改码”解决。改码会触发平台侧的重新校验，而停用一个已经不产生价值的链接，几乎没有任何副作用。
很多重复码问题到这里才真正变复杂。因为在你的主数据里显示”不重复”的两个 UPC，在平台侧可能已经被映射到了互相冲突的 ASIN 上。
这一层要查三件事：同一个 UPC 是否对应了多个在售 ASIN、同一个 ASIN 是否被多个 UPC 指向、以及是否存在品牌备案层面的冲突。我通常会用一段聚合查询先把可疑清单拉出来。
SELECT
upc_normalized AS gtin14,
COUNT(DISTINCT sku) AS sku_cnt,
COUNT(DISTINCT shop_id) AS shop_cnt,
COUNT(DISTINCT asin) AS asin_cnt,
GROUP_CONCAT(DISTINCT shop_id) AS shop_list,
GROUP_CONCAT(DISTINCT category) AS category_list,
SUM(has_orders) AS ordered_listing_cnt
FROM listing_master
WHERE status IN ('active', 'pending')
GROUP BY upc_normalized
HAVING COUNT(DISTINCT shop_id) > 1
OR COUNT(DISTINCT asin) > 1
ORDER BY ordered_listing_cnt DESC, shop_cnt DESC;这段查询的排序方式很关键：把”已经出单的重复码”排在前面。因为它们是成本最高、最需要优先处理的一批。我在实际使用中会把结果分成三档：已出单的多 ASIN 冲突、已上架未出单的重复、未上架的重复，处理顺序就是这个顺序。
前三层都在你自己的数据里查，第四层要跳出系统。这一层专门对付供应商二手码和码段回收复用这两类问题。
具体动作有三个：向供应商索要码段的原始购买凭证、用 GS1 官方或第三方查询工具核对码的注册主体、以及对可疑码段做整批停用而不是单条修改。码段回收复用型的问题，往往是成片的而不是单点的，单条处理只会让你在三个月后重新遇到它。
这一层的结论通常不是”哪条该改”，而是”哪一批码不能再用了”。这个判断会直接影响你的采购流程，所以我在实际项目里会把这一层的发现单独出一份备忘，交给采购负责人，而不是只交给运营。
前面讲的是方法论。这一章我把方法落到具体工具上，讲一次我实际怎么操作的。这里我用的是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys），它在跨境商品数据管理这块的多店铺聚合和字段对比能力，正好对上第二章说的”跨店铺重复”这个最难查的场景。
前面说过，单店铺后台永远查不出跨店铺重复。原因很直白：两个店铺的数据在物理上是隔离的，你不把它们拉到同一张表里，任何比对都无从谈起。
我早期的做法是手工导出、手工对齐字段、写脚本。这个方式能解决问题，但有两个硬伤：一是每次导出都要重新对齐字段名，不同平台导出的列名不一致；二是数据是快照，你今天查完，明天新上架的又不在里面了。
数跨境这类工具解决的正是这两点，把多店铺、多平台的数据统一到一个数据模型里，并且是持续更新的。这就把”事件驱动的排查”变成了”常态化的巡检”。
以那个家居卖家为例，我的操作顺序是这样的。
第 5 步是最容易被忽略但最重要的一步。排查是一次性的，校验是长期的。我见过太多团队做完一次大扫除，三个月后重复码又回到原来的水平，因为他们只解决了存量，没解决增量。
这里有个细节值得单独说：接入多店铺数据的时候，字段标准化这一步不能省。我那次接入时，4 个店铺里有两个平台的 UPC 是 13 位、一个是 12 位、还有一个干脆混着存。如果不先统一成 GTIN-14，后面的频率统计会把同一批商品算成两批，重复码数量会被严重低估。
我用三个不同规模的卖家做了个对比：2 个店铺的卖家平均 43 条重复码，4 个店铺的卖家平均 217 条，7 个店铺的卖家平均 611 条。店铺数从 2 到 4 翻了一倍，重复码数量翻了 5 倍；从 4 到 7 翻了不到一倍，重复码数量又翻了近 3 倍。
原因不难理解：店铺之间两两组合的数量是 n(n-1)/2。店铺越多，需要比对的组合越多，而人工比对的能力是不变的。所以当店铺数量超过 3 个，人工排查就不再是一个可行选项。
我统计过被处理掉的 217 条重复码，从产生到被发现的中位时间是 47 天。其中在 7 天内被发现的只有 31 条，7-30 天的有 62 条，超过 30 天的有 124 条。而超过 60 天才发现的 38 条里，有 21 条已经出单并产生了评论。
这组数据说明一件事：你的排查周期决定了你的问题性质。如果你每月排查一次，你处理的永远是”已经付出代价”的记录；如果你在录入环节校验，你处理的是”还没产生代价”的记录。
这个观察挺反直觉的。我原本以为重复码本身就会导致退货，但数据看下来，真正拉高退货率的是”跨类目重复”。同一个 UPC 被用在窗帘和宠物垫上，买家点进来看到的详情页和预期严重不符，退货几乎是必然的。
那个卖家样本里，跨类目重复关联的 ASIN 退货率是店铺均值的 3.1 倍，而同品类重复关联的 ASIN 退货率只比均值高 0.4 倍。所以我在排优先级的时候，会把”跨类目”作为一个独立的加权项，优先级甚至高于”是否出单”。
方法一样，但不同规模、不同模式的卖家，落地路径差别很大。我按四种典型情况给建议，你可以直接对号入座。
铺货型卖家的特点是 SKU 数量大、上新频率高、单个 SKU 价值低。这类卖家做全量清洗的性价比很低，因为清洗完第二天又被新数据污染了。
我的建议是：不追求把存量清干净，只追求新增不再产生。具体做法是在导入模板里加一列校验，用条件格式或者一段简单脚本，在导入前自动标红重复项。存量部分按”是否出单”筛一遍，只处理已出单的那一小部分。
这个策略的取舍很明确：你会长期带着一批未清理的低风险重复码，但它们对应的都是没出单、没流量的链接，实际风险可控。
精品型卖家 SKU 少、单 SKU 价值高、链接生命周期长，重复码一旦出问题影响就很大。这类卖家应该做一次彻底的全量清洗，并把结果沉淀成一张主数据表。
主数据表至少包含：内部 SKU、GTIN-14、原始 UPC/EAN、对应 ASIN、站点、创建时间、当前状态、是否有订单、是否有评论。这张表建好之后，以后所有的重复比对都在这张表上做，不用再临时导出。
我要额外提醒一点：这张表要有明确的唯一责任人。我见过主数据表建得很漂亮，但没人维护，三个月后表里的状态和实际完全对不上，排查时反而误导判断。
店铺数超过 3 个、平台数超过 2 个，人工方式基本不可行。这时候需要一个能把多店铺数据统一到一个模型里的工具。
选工具的时候，我最看重的三个点是：能不能统一字段口径（特别是 UPC/EAN 混存的处理）、能不能做跨店铺的频率统计、能不能设置常态化的巡检提醒。数跨境在这三点上是我目前用下来比较顺手的，尤其是字段标准化那一步，省掉了我以前手工对齐列名的大量时间。
不过我也要说清楚边界：工具解决的是”发现”和”持续监控”，解决不了”判断”。哪条该保留、哪条该停用、哪些码段要整批废弃，仍然需要人来决策。指望工具一键搞定所有重复码，是不现实的。
如果你是品牌方或者工厂，UPC 是自己申请和分配的，那你最大的优势是可以从采购端就开始管。我强烈建议在这个环节做三件事。
这三件事做下来，你的重复码问题会在源头上消失，而不是靠后期排查。
治理重复码不是越严越好。任何校验都会带来摩擦成本，摩擦成本最终会转嫁到上新速度上。这一章讲清楚不同场景下应该怎么权衡。
彻底清洗的好处是干净，坏处是耗时长、需要停下手上的活、而且清洗期间业务照常运转会产生新的重复。
我的判断标准是：如果你的存量重复码里”已出单”的比例超过 15%，做一次彻底清洗是值得的；如果低于 5%，持续小步治理更划算。因为已出单比例低说明你的问题主要在增量，清洗存量治标不治本。
那个家居卖家的已出单比例是 11/217≈5%，我当时的建议其实是不要做全量人工清洗，而是集中处理那 11 条加跨类目的 63 条。但对方坚持要全清，结果是花了两天多处理了一堆零风险记录。
自建脚本的优势是自由、可控、不依赖外部服务；劣势是要自己处理字段对齐、多平台差异、数据更新，维护成本会持续存在。
我的经验是分水岭在店铺数。1-2 个店铺、单平台，自己写脚本完全够用，甚至 Excel 加一点公式就能覆盖。3 个店铺以上或者跨两个以上平台，字段标准化和持续同步的工作量会迅速超过脚本本身的价值，这时候用工具更划算。
前置校验最大的副作用是：运营在导入时会频繁被拦下来，尤其是当校验规则设得太严，把一些合理情况也判为重复时。
我踩过这个坑。早期我给一个团队设的规则是”UPC 只要重复就拦截”，结果同款产品的不同包装规格被大量误拦，因为供应商给这批货的时候，同一款不同规格用了同一个码的前 11 位、只有校验位不同，而我的标准化逻辑处理不当，把它们判成重复。运营抱怨了一周。
后来我把规则改成了分级：完全相同的 GTIN-14 直接拦截；仅前 11 位相同但校验位不同的，标记为警告但不拦截。这样既保住了核心风险，又减少了对正常业务的干扰。
这是最难的一类决策。两条链接都出了单，你只能保一条。
我的判断顺序是：先看评论数量和评分，再看历史销量和退货率，最后看这条链接在公司战略里的定位。如果一方明显占优，直接弃用另一方，把这个 ASIN 库存合并过去。
如果两边差不多，我会倾向于保留创建时间更早、评论更稳定的那条，因为迁移评论在多数平台上是一个不确定的过程，存在丢失风险。宁可损失一部分销量，也不要冒评论丢失的风险，因为评论是长期资产，销量是短期变量。
写到这里，我想把全文最核心的那个观点再强调一次，因为它和大多数人处理重复码的直觉是相反的。
大多数人把重复码当成一个”数据质量问题”，所以他们的解法是清洗数据，找出来、改掉、结束。但从我经手的案例看，重复码从来不是数据质量问题，它是流程没有闸门的结果。你清洗一百次，只要闸门没装上，第一百零一次还会发生。
这也是为什么我一直坚持”四层漏斗”必须按顺序执行，且第四层要跳出系统去做。前三层是技术，第四层是流程和供应链，两者缺一不可。只做前三层，你解决的是症状；加上第四层，你才可能解决原因。
另一个我希望你带走的反常识判断是：重复码的优先级不取决于它是不是重复，而取决于它距离”出单”有多远。一条躺在待上架列表里的重复码，风险接近于零；一条已经积累了两百条评论的重复码，风险是前者的几百倍。把这两者放在同一个待办清单里按顺序处理，是效率最低的做法。
下一步你可以做三件事，按我给建议的顺序来。
UPC 码不是一个大问题，它是一个小问题被流程漏洞放大之后的结果。把它当成流程问题来治，你会发现它比想象中好解决得多。
我们做铺货的，SKU上千，运营甩过来一张表说好像有重复码，我肉眼翻了两小时眼睛都花了。而且我怀疑不光是完全一样的才算重复，有些码看着不一样但可能是同一个，这种到底算不算？
分两步走，先标准化再查重，直接肉眼比对一定会漏。第一步把原始码统一成14位GTIN文本：先确认那一列是文本格式而不是数字，Excel会把12位数字的前导0吃掉，变成11位，这时候你查重查出来的是假的。
新增一列标准化公式，把空格、连字符清掉再左补0到14位，比如用TEXT(RIGHT(REPT(0,14)和SUBSTITUTE(A2,连字符,空)与SUBSTITUTE(结果,空格,空)拼起来取右14位的方式处理（网上搜GTIN14标准化公式，改一下列号就能用）。
第二步查重，在标准化列旁边加一列COUNTIF，公式写成IF(COUNTIF(标准化列区域,B2)>1,1,0)，筛选出1的就是重复。这里有个判断口径要分清：原文完全一致的是硬重复，必须处理；
原文不同但标准化后一致的是格式重复（前导0、空格、大小写、UPC-A和EAN-13混填），也要处理，但要先确认哪个写法才是GS1后台登记的正式写法，不能随手改。另外建议再加一列校验位验证，GS1校验位算法是从右往左奇数位乘3、偶数位乘1求和，取模10的补数。
校验位不对的码属于无效码，它跟另一个有效码撞上，说明是抄错了，不是真重复，处理方式完全不同。数据量口径：1万条以内Excel够用，超过10万条COUNTIF会明显卡顿，转Power Query分组计数或者Python的duplicated更快，几分钟跑完全表。
我一直以为只要不手动重复填写就不会出问题，结果上个月盘点发现十几个重复码，我完全不知道它们是怎么冒出来的。是不是我用的系统有bug？
绝大多数重复不是系统bug，是流程漏洞，按来源打标签一查就清楚。最常见的五类：一是回收复用，老SKU下架后把码挪给新品用，但老listing、ERP档案、历史订单里还挂着这个码，系统层面就变成了两个SKU共享一个码；
二是多来源录入，运营从供应商拿一批码、从GS1买一批、又从第三方转手买一批，三张表合并时没人做去重；三是格式不统一造成的假重复，同一产品运营填UPC-A、工厂填EAN-13、包装部门填带包装指示符的GTIN-14，本质是一个东西被写成三种样子；四是组合装和单品共用码，变体关系没有在编码层面区分开；
五是手抄错一位，恰好撞上了另一个已存在的码，这种在你集中采购同一码段时发生概率并不低。判断依据很简单：把重复码按采购批次、录入人、录入时间做个透视表，如果80%集中在一批采购或一个人身上，那是流程问题，改流程就行；如果分散在各批次各人身上，那是规则问题，说明你缺一张唯一的主表，得先建主表再谈排查。
上架的时候直接报错说这个UPC已经被用了，还有一次更离谱，我的商品莫名其妙跟一个陌生卖家的详情页合并在一起，评价全是别人的，销量数据也乱了。这种情况严重吗，要不要直接换个码重上？
后果分三档，别一上来就换码。轻的是上架报错UPC已被使用，商品上不去；中等是两个不同商品被并成同一个详情页，评价、评分、销量互相污染，你的新品顶着别人的差评卖；重的是被平台判定为UPC滥用或伪造，listing被移除，严重的会影响账号。
处置顺序是：第一，先确认这个码是不是你自己历史上用过的，去ERP和GS1后台查分配记录，如果是自家旧SKU遗留，走品牌方或GS1的权利主张流程解绑，成本最低；
第二，确认是别人盗用，如果你手里的码是从GS1正规买的前缀，那就是你公司独有的资产，凭GS1证书、公司信息、码段授权记录向平台申诉，这是最硬的证据，胜率很高；
第三，如果码是第三方转手来的，你拿不出GS1授权记录，申诉基本必败，这时候别硬耗，立刻换新码重新上架，老listing的权重用变体关系或广告承接，把损失压到最小。
预防口径：所有UPC必须登记进一张主表，字段至少包含码、SKU、GS1前缀、采购批次、分配人、分配日期、状态（在售/停用/归档），停用的码永久封存，绝不复用，否则下一次被盗用的时候你连自证的材料都拿不出来。
每次都是出事了才救火，查一遍修一遍，过两个月又冒出来几个。我想问有没有办法从源头管住，别再靠人盯人，团队小、没有专职数据岗的情况下怎么落地？
把UPC当资产管，不是当填写项管，四个卡点卡住就基本不会再有重复。第一，入库唯一入口：所有新码只能由一个人或一个系统录进主表，禁止运营各自从Excel贴码，多人多入口是重复的头号来源。第二，分配即锁定：码一旦分配给某个SKU，状态立即改成已占用，谁都不能改；
SKU停售时状态改归档而不是删除，归档码永久不再分配，这条是防回收复用的关键。第三，上架前自动校验：在上架工具或ERP里加一道拦截，用脚本比对上架表与主表的码，命中重复或状态不是已占用的直接拦下来不让提交，宁可卡一下也别放过去。
第四，定期巡检：每月跑一次全表查重加校验位验证，每季度核对GS1后台的已授权码数量与实际使用数量是否对得上。这里给一个可量化的健康指标：主表里的码总数应该等于GS1已授权数量，且每个码的状态唯一、每个SKU对应的有效码只有一个。
如果两个数字对不上，差额就是流失、盗用或重复的码，顺着差额去找，比全表翻查快得多。经验上做到这四步，重复码基本只在合并、收购、换ERP这类大变动时才会冒出来，而且一查就能定位到具体环节，不用再全网救火。团队小的话，四个卡点里第二和第三条性价比最高，先上这两条，能挡掉大部分问题。
读者评论
我这边也是四五个店铺，去年查出过跨店重复码，但没到文章里那种程度。实际走下来最麻烦的不是评论迁移，是有些平台换码后老ASIN评论还在但权重全没了，等于重新养链接。所以我现在宁可新链接先在测试店铺验证码，也不愿意事后改。
成本倍数那张图方向我认同，但数字容易让人焦虑。真正卡住小卖家的不是成本，是根本没人专门管UPC，采购、运营、仓储各管一段。我试过在采购表加校验列，坚持两个月就没人填了，最后还是靠月底脚本兜底。流程前置得先把责任人定下来。
供应商二手码我踩过。第三方买的便宜码用了半年没事，后来新链接上架时平台直接报已被使用，去GS1查才发现注册主体不是我们。文章给这类13%我觉得在中小卖家里可能更高，而且平台报错前基本没征兆，建议补一下平时怎么核验码的归属。