去年 11 月，一个做家居收纳的跨境卖家凌晨给我发来截图：新上架的 6 个 SKU 被平台批量驳回，理由是 UPC 已被占用。他第一反应是”平台抽风”，第二反应是”是不是要重新买码”。我让他先别买，把全部 SKU 和 UPC 对照表导出来发我。十分钟后答案出来了：这 6 个 SKU 用的并不是同一个码，但它们和他半年前另一条 listing 里的老品共用了 3 个码，供应商给的码表复用了同一份数据。
真正的问题不是”码不够”，而是”码没人管”。
这件事之后我把过去几年经手的 UPC 问题做了一次复盘，一共 100 例，其中 61 例的根因是重复码或身份混淆，而不是”没有码”。更值得说的是处理时长：一个在上架前被发现的重复码，平均 2 小时能闭环；一个已经出单、已经进仓、已经投过广告的重复码，平均要 60 小时以上才能收拾干净。这篇文章不讲 UPC 怎么申请、多少钱、哪个渠道便宜，那些内容网上已经很多。我要讲的是：怎么判断一个码是不是重复码、怎么把它查出来、查出来之后该换码还是该申诉、以及怎么让这件事不再发生。
我先把我最核心的三个判断放在前面。如果你只读这一段，也应该能拿走一套可用的决策框架。
缺 UPC 是一个单点问题：补一个码就结束了。重复 UPC 几乎从来不是单点问题，因为一个码被复用，往往意味着整批码表都来自同一份未经核验的数据源。你发现 1 个重复码，背后通常还躺着 5 到 20 个同类问题。
我统计过自己处理的 34 起重复码事故，中位数是单次牵连 9 个 SKU，最多的一次牵连 47 个。这也解释了为什么我不建议”发现一个改一个”，你改完这一个，下周还会遇到下一个。
很多人把”平台驳回”当成重复码的起点，其实是终点。在平台报错之前，这个码可能已经在你的 Excel 里被复制粘贴过、在供应商的码表里被分配过、在 ERP 里被录成过商品主档、在仓库里被贴到过箱子上。平台只是最后一个说”不行”的人。
我的判断是：重复码排查不应该发生在”上架被驳回之后”，而应该发生在”码被录入主数据的那一刻”。这是入门和进阶的分水岭。入门玩家在救火，进阶玩家在装烟感。
我复盘那 100 例问题后发现，只有约 18 例是外部原因（供应商码表复用、低价码包撞码），其余 80 多例的第一责任方都是卖家自己：多店铺操作时复制粘贴、父子 SKU 关系搞混、换品牌不换码、为了省码一码多平台。
这意味着一个反常识的结论：与其花时间去找”更靠谱的买码渠道”，不如先花半天时间建一张 SKU-UPC 主数据表。后者的收益确定性高得多。
抽象的道理不如一次完整复盘。我把刚才提到的那次事故按时间线拆开讲，你会发现每一个环节都有可以提前拦截的机会。
他找供应商要了一组 UPC，供应商发来一个 Excel，20 个码，备注”已注册，可用”。他直接复制进商品表，没有做长度检查，没有做校验位检查，也没有和已有码做比对。这一步的耗时如果做了，是 15 分钟。
6 个 SKU 一起被驳回，报错是”该 UPC 已被其他商品使用”。他登录后看，发现占用方不是别人，是他自己 5 个月前的一条老 listing。这时候问题性质已经变了：不是”码来源有问题”，而是”码分配有问题”。
我们一起做了三件事：把全部历史 SKU 和 UPC 拉平比对，找到所有重复；把 6 个新 SKU 里冲突的 3 个码替换成新码；把新码同步到 listing、ERP、WMS 和包装标签。看起来简单，但第三件事花了整整一天，因为仓库里已经有一批货贴好了旧码标签。
最终 6 个 SKU 全部上架成功，但比原计划晚了 9 天，预售期已经过了。他的原话是：”我一直以为买码是最大的门槛，结果是管码。”
很多人对”损失”没有感觉，因为它是分散的。我按他当时的实际数据做了折算，你可以对照自己的情况估算。
事故收尾之后，我建议他不要再依赖”人记得核对”这种方式。他的 SKU 数量在 800 左右，跨了 3 个平台、2 个店铺，靠 Excel 手工比对已经不可靠了。
我们采用的是把数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）作为多平台数据的汇总层：从各平台后台和 ERP 里把商品表统一拉进来，做一次字段映射（SKU、UPC、ASIN、店铺、状态），然后在上面建三张基础视图，UPC 出现次数视图、UPC 跨店铺对照视图、异常码池视图。
这样做的价值不是”工具更高级”，而是把查重从”一次性动作”变成”常驻视图”。他现在的日常动作是：新品录码前先在这张视图里搜一次，10 秒出结果。这个动作本身不产生任何业绩，但它把上架驳回的概率压到了接近零。
需要说清楚的是，工具只解决”看得见”的问题，它不会自动告诉你这个码是不是正规渠道来的。来源合规性仍然需要人工核实，参照的是 GS1 官方和各平台最新政策。
在讲具体方法之前，我想先把误区拆掉。因为如果认知是错的，后面的 SOP 执行起来也会变形。
这是最高频的误解。UPC 标识的是”商品”这个层级，也就是同一款、同一规格、同一包装的所有件，共用同一个 UPC。它不区分”第 1 件”和”第 1000 件”，那是序列号（SN）的职责。
为什么这个区别重要？因为它直接决定了”一码多用”的边界：同一商品的所有批次用同一个 UPC 是对的；不同商品用同一个 UPC 是错的；同一商品的不同规格（比如红色 M 和红色 L）用同一个 UPC 通常也是错的。
“扫得出来”只证明这个码在结构上合法，不证明它在全球范围内唯一、也不证明它归属于你。低价码包和批量生成码最常见的问题就是分配冲突，同一个码可能被卖给了多个买家。
我不主张把所有非官方渠道一棍子打死，但你要清楚风险等级。我的建议是：任何不是通过 GS1 或明确可追溯授权链路获得的码，都必须当作”待核验码”处理，逐一查重后再使用。
这是最危险的一个误区。Excel 的删除重复项有三个致命盲区。
012345678905 和 12345678905，在它眼里是两个不同的值。正确的做法是”先标准化，再比对，最后人工确认业务含义”。三步少一步都不行。
位数只能证明格式，校验位才能证明结构自洽，而这两者都不能证明归属。一个由生成器批量产出的 12 位数字，完全可以通过校验位验证，但它可能从未被任何组织分配过。
所以完整的验证是四层：结构层（位数）→ 校验层（校验位）→ 归属层（前缀来源）→ 业务层（是否与已有商品冲突）。入门玩家通常只做了第一层。
UPC 这个数字在你公司内部至少出现在 6 个地方：平台 listing、平台目录与变体关系、ERP 商品主档、WMS 库存与库位、广告与再营销关联、实体包装与条码标签。改一个地方，其他五个地方就会对不上。
我见过最典型的后果是：listing 换了新码，但 ERP 还是旧码，导致平台订单回传时匹配不到商品，订单堆在”待处理”里没人发现，等发现时已经超时。
上架被驳回只是最显性的一种。更隐蔽的后果是数据污染：两个商品共用一个码，平台的销量、评论、广告数据会互相串。你看到某款商品”转化率突然变好”，可能只是另一款的数据被合并进来了。
基于这个判断，我把重复码的来源和排查线索整理成下面这张表，你可以直接用来做内部培训材料。
| 来源场景 | 典型表现 | 风险等级 | 第一排查线索 |
|---|---|---|---|
| 手工录入 / 复制粘贴 | 同一人操作多店铺时，粘贴沿用上一行的码 | 中 | 查同一操作人、同一时段的录入批次 |
| 供应商或代运营重复提供 | 码表与半年前老品高度重合 | 高 | 把新码表与历史全量码做交集比对 |
| 低价码包 / 转售码遗留 | 成批出现冲突，且无法提供来源证明 | 高 | 按码段分组，看是否集中爆发 |
| 多平台 / 多店铺共用 | 不同渠道同一码对应不同商品 | 中 | 跨店铺对照视图，按 UPC 聚合看店铺数 |
| 变体与父子 SKU 误用 | 父体与子体共用码，或子体之间共用码 | 中 | 导出父子关系表，单独校验子体码唯一性 |
| 换包装 / 换品牌未更新码 | 新品牌商品沿用旧品牌的码 | 中 | 按品牌分组，检查码是否跨品牌复用 |
这一节是全文方法论的核心。我把它设计成四层递进，每一层都能独立拦截一批问题，越往前成本越低。
先做最粗糙的过滤。这一步的目标不是判断真伪，而是把明显不合格的记录挑出来扔进异常池。
需要注意的坑是 Excel 的前导零。UPC 里出现以 0 开头是非常正常的（北美大量商品使用 0 作为系统位），但 Excel 会把 012345678905 读成数字 12345678905，位数从 12 变 11，直接污染整批数据。
处理方式是在导入时就把该列设为文本格式，或者在清洗阶段统一补足位数。校验公式很简单：
=IF(LEN(TEXT(B2,"0"))<>12,"位数异常","")
校验位是 UPC 的最后一位，由前面所有位按固定权重算出。它的作用是防止扫描时误读，不是防伪。这一点必须说清楚，否则很多人会误以为”校验通过=合法码”。
我给团队写的校验脚本是这样的，直接传数字串即可，UPC-A、EAN-13、GTIN-14 都覆盖：
def gtin_check_digit(digits: str) -> str:
"""传入不含校验位的数字串，返回应有的校验位。
GTIN-12 传 11 位，GTIN-13 传 12 位，GTIN-14 传 13 位。
规则：从右往左编号，奇数位权重 3、偶数位权重 1，交替计算。
"""
body = [int(c) for c in digits]
total = 0
for idx, d in enumerate(reversed(body), start=1):
weight = 3 if idx % 2 == 1 else 1
total += d * weight
return str((10 - total % 10) % 10)
def is_valid_gtin(code: str) -> bool:
code = code.strip()
if not code.isdigit() or len(code) not in (8, 12, 13, 14):
return False
return gtin_check_digit(code[:-1]) == code[-1]验证
print(is_valid_gtin("036000291452")) # True
print(is_valid_gtin("4006381333931")) # True
print(is_valid_gtin("036000291453")) # False，末位被改动
在 1 万条样本里，这一层通常能筛掉 70 到 150 条记录。数量不大，但这些都是”结构性错误”，如果不挑出来，它们会混进后面的重复比对里制造噪音。
UPC-A 的 12 位通常可以拆成三部分：系统位、公司前缀、商品参考号，最后一位是校验位。公司前缀代表”这个码段归谁使用”，是判断归属的核心依据。
公司前缀的长度并不固定，美国和加拿大常见为 6 位左右，实际长度由 GS1 成员组织按申请量分配。这意味着你不能用”固定第 2 到第 7 位”这种方式去切分，只能拿官方记录来比对。
实操建议只有一条：如果你是通过正规渠道申请的，把 GS1 提供的分配记录存成一份内部台账，查重时以它为基准。如果没有这份记录，说明你的码来源不可追溯，应该整体按高风险处理。
前三层都是技术判断，第四层才是业务判断，也是最容易出错的一层。因为”重复”这个词在业务上有两种完全不同的含义。
一种是同一商品多码：同一款商品因为历史原因存在两个 UPC，比如换过供应商、换过包装版本。这种情况可能被平台允许，处理方式是保留一个主码，另一个做备注或废弃。
另一种是不同商品同码：两个完全不同的商品共用了一个 UPC。这种情况通常必须拆码，没有商量余地。
区分方法很简单，但必须做：把重复的 UPC 拉出来，看每个码下挂的 SKU 名称、品牌、品类、规格是否一致。名称高度相似但有细微差异的，要特别小心，这往往是变体误用。
另外，UPC 和 GTIN 的层级关系也经常被搞混，下面这张表可以直接贴到团队文档里。
| 类型 | 常见位数 | 典型场景 | 与查重的关系 |
|---|---|---|---|
| UPC-A | 12 位 | 北美零售单品 | 最常见的被复用对象，查重主战场 |
| UPC-E | 8 位（压缩形式） | 小包装、窄标签 | 与 UPC-A 可互转，转换后必须重新查重 |
| EAN-13 | 13 位 | 欧洲及全球零售 | 与 UPC-A 常用前导 0 互转，转换即视为新码 |
| GTIN-14 | 14 位 | 箱规、托盘等外箱层级 | 与单品码不是同一层级，混用会造成系统性冲突 |
关于 UPC-E 有一个必须记住的限制：它不是所有 UPC-A 都能压缩。只有当公司前缀符合特定规则时，UPC-A 才能无损转成 UPC-E。如果你的 ERP 或者某个工具随手做了转换，很可能转出来的码是无效的。转换后一定要重新走一遍四层判定。
四层跑完，你会得到一份带标记的记录表。我建议直接按风险分成三档，因为不同档位的处理成本差异很大，混在一起处理会浪费人力。
下面这张图是我对不同来源码的风险分布做的统计（样本为经手的 100 例问题记录，属于经验性推演数据，不是行业统计）。
前面讲的是判断逻辑，这一节是执行流程。我把它拆成 8 步，每一步都写明目的、操作、输出物和最容易踩的坑。这套流程我在不同规模的团队里跑过，从 200 个 SKU 到 3 万个 SKU 都适用。
目的：确保比对基准是完整的，而不是”我以为的完整”。
操作：从所有平台后台、ERP、供应商码表三个方向分别导出，每份都带上 SKU、UPC、品牌、品类、店铺、状态这几列。不要只导正在售的商品，已下架的也要导，因为重复码往往出现在”新码和老下架品冲突”的场景。
输出物：一个至少包含三份来源数据的合并表。
常见坑：只导主店铺不导子店铺；只导当前在售不导历史。这两点会造成大量漏检。
目的：让不同来源的数据具备可比性。
操作：统一做四件事，去首尾空格、去掉不可见字符、把列设为文本格式、补齐前导零到目标位数。
输出物：一列”标准 UPC”，后续所有比对只用这一列。
常见坑：清洗完直接覆盖原始列。我强烈建议保留原始值和标准值两列，否则一旦清洗出错，你连回溯的依据都没有。
目的：把结构性错误挑出来，避免污染后续比对。
操作：先跑长度检查，再跑上一节的校验位脚本。两条检查都通过的进入主流程，不通过的进异常池。
输出物：异常池清单，通常占总量的 1%，2%。
常见坑：把异常池直接删掉。正确处理是保留并单独处理，因为这批记录里往往藏着”有人手动编过码”的线索。
目的：拿到第一份核心结果。
操作：在 Excel 里用条件格式标记，公式是：
=COUNTIF($B:$B, $B2) > 1
数据量大时更推荐用数据透视表或 SQL：
SELECT upc, COUNT(*) AS dup_count, GROUP_CONCAT(sku) AS sku_list FROM sku_master WHERE upc IS NOT NULL AND upc <> '' GROUP BY upc HAVING COUNT(*) > 1 ORDER BY dup_count DESC;
输出物：重复码清单，含每个码对应的全部 SKU。
常见坑：只看到”有重复”就急着删。必须进入第四层业务判定，确认是同商品多码还是不同商品同码。
目的：发现单表比对查不出来的冲突。
操作：把第四步的重复码清单，按”UPC + 店铺”和”UPC + 站点”两个维度再聚合一次。同一个码出现在两个店铺，或者出现在美国站和欧洲站，都属于需要单独判断的情况。
输出物：跨渠道冲突清单。
常见坑：忽略站点维度。同一个 UPC 在美国站合规，在欧洲站可能因为 EAN 规则不同而产生问题。
目的：判断这些码的归属是否清晰。
操作：把码和三类外部记录比对，GS1 的分配记录（如果你有）、平台商品目录（搜一下这个码对应什么商品）、供应商的码表原始版本。
输出物：每个重复码的归属判定结论。
常见坑：拿平台目录当唯一真相。平台目录里可能存在其他卖家误填的记录，它会误导你。
目的：把有限的人力投到最该处理的地方。
操作：按”是否正规来源 + 是否不同商品 + 是否已出单 + 是否跨渠道”四个维度打分，分成高、中、低三档。
输出物：带优先级排序的处理工单。
常见坑：不分级，从第一条开始处理。结果是高风险问题被埋在低风险问题后面，错过了最佳处理窗口。
目的：把排查结果变成可追踪的动作。
操作：每条高风险记录生成一个工单，字段至少包括：问题 UPC、涉及 SKU、冲突类型、建议动作（换码/申诉/保留）、责任人、截止时间、同步范围。
输出物：可跟踪的工单列表。
常见坑：工单只写”处理重复码”，不写具体动作和同步范围。这样执行的人还是会漏掉 ERP 和 WMS。
把这 8 步跑完，1 万条记录的收敛结果大致是这样的：
查出问题之后，决策比执行更难。我见过太多团队在”该不该换码”上争论一周，最后还是靠拍脑袋。这一节给一套可复用的判断树。
不管什么情况，先按顺序问三个问题，答案会直接把你导向唯一合理的动作。
保留一个主码，另一个在系统里标注”废弃”，不要直接删除，否则以后回溯历史数据会断链。
保留主码，把旧码设为”历史码”，并在 ERP 里建立新旧码映射关系。这样历史订单回传时还能匹配到商品。
立刻给其中一个（通常是新品）换新码，换完立刻跑一遍完整查重。这是最简单也最该果断处理的情况。
这是最麻烦的情况，需要分两步：先冻结相关 SKU 的新增上架和广告投放，避免数据继续污染；再规划换码和同步方案。同步范围参照下面这张图。
有些情况下你确实可以走申诉，但我的判断是：只有当你手里有明确的、可追溯的 GS1 分配记录，且冲突方明显是误用时，申诉才值得投入时间。
其余情况申诉的成功率低，而且会拖延处理窗口。更务实的做法是直接换码，把时间用在换码同步上。换一个码的成本通常是几十到几百元，而拖延一周的成本是上万元级别的上架延误。
修完一次问题不算本事，让它不再发生才算。这一节讲的是机制设计，面向的是团队而不是个人操作。
码池的核心不是”存码的表”，而是四个明确的状态：未分配、已分配未使用、使用中、已废弃。每个码在同一时间只能处于一个状态，状态变更要有记录。
关键规则只有一条：分配动作必须由系统完成，不能由人从表里挑。人一旦可以自由选码，复制粘贴的错误就会回来。
门禁的作用是让错误”提交不出去”。我建议至少设置四条硬性检查。
这四条里，第三条最容易被忽略，但它的拦截效果最好。因为它能发现”同一个码在另一个店铺已经被用了”这种仅靠内部表看不出来的问题。
门禁只能拦住新录入的数据，历史遗留问题需要靠定期审计。我建议按季度跑一次全量查重，重点看四类异常：新增重复、跨渠道冲突、来源标签为空、长期处于”已分配未使用”状态的码。
从我的观察看，审计频率和重复码发生率之间有明显相关性。下面是基于团队实际运营数据做的推演对比，能看到机制叠加带来的增益。
如果 UPC 由供应商或代运营提供，一定要在协议里明确两条：一是供方保证所提供条码在全球范围内唯一且未被使用；二是因条码重复导致的平台处罚、下架、返工成本由供方承担。
这两条不是摆设。我见过至少三次，正是因为协议里有这条，返工的标签成本最终由供应商承担了。
方法论是通用的，但投入强度必须和业务规模匹配。用一套 3 万 SKU 才需要的流程去管 200 个 SKU，是浪费；反过来则是灾难。
很多团队问我”到底要不要上工具”。我的回答是：先看你的短板在哪一层，再决定要不要上。
手工 Excel 的强项是”单表内的完全重复”，弱项是跨渠道和对历史数据的追溯。平台后台能告诉你”这个码有没有被占用”，但它看不到你自己内部两个 SKU 之间的冲突。主数据中台（例如前面提到的数跨境这类把多平台数据汇总起来的工具）的强项是跨渠道整合和持续监控，但它不解决来源合规性。
不要买工具。把精力放在两件事上：统一用正规渠道获取码，建立一张 SKU-UPC 主数据表并且每次录码前搜一次。这两件事的成本接近零，但能解决大部分问题。
这时候人已经不可靠了。建议把多平台数据汇总到一个统一的地方，建立 UPC 唯一性视图和异常预警。选工具时不要看功能列表，先看它能不能稳定拉取你所有店铺的数据，数据接不进来，功能再多也没用。
重点不在查重工具，而在码的分发机制。你需要决定：哪些码给自营、哪些给分销、哪些留给新品。同时要把唯一性条款写进所有合作协议，并且定期抽查分销商是不是在违规复用码。
下面这些问题来自我实际被问到的最高频疑问，我按”能直接行动”的标准来回答。
不是。UPC 标识的是”商品”层级，同一款同规格的所有件共用同一个 UPC。序列号标识的是”单件”，每件不同。如果你想追踪单品，需要的是序列号或批次号，不是 UPC。
常见的是 UPC-A，12 位。此外还有 UPC-E，8 位，是压缩形式。与之相关但不同的还有 EAN-13（13 位）和 GTIN-14（14 位，常用于外箱）。判断位数时切记不要把 Excel 丢失前导零后的结果当真。
通用路径是通过所在国家或地区的 GS1 成员组织申请公司前缀，再基于前缀自行分配商品码。各地规则、费用和前缀长度差异较大，具体以当地 GS1 官方页面为准。英国公司应通过 GS1 UK 申请，不能套用美国流程。
部分平台对已备案品牌提供 GTIN 豁免通道，但政策会调整，且豁免通常有条件限制和审核流程。不要把豁免当成默认路径，以平台最新政策为准，并事先确认你的品类是否在可豁免范围内。
处罚形式因平台和情节而异，可能包括上架驳回、Listing 下架、销售权限限制等，严重情况下可能影响账号健康。我不建议用”一定会封店”这类说法来吓人，但也不建议赌平台不查。正确的心态是：重复码首先影响的是你自己的数据质量，平台处罚只是其中一种后果。
从结构上，很多生成器产出的码能通过校验位验证，扫码也能扫出来。但从归属上，它没有被任何组织分配给你，全球唯一性无法保证。我的建议是当成高风险处理，如果已经在用，做一次全量核验，确认没有冲突再决定是否保留，同时准备替换方案。
不建议重新启用。正确的做法是在码池里把旧码标记为”已废弃”并保留映射关系，让历史订单和库存数据仍能匹配到商品。重新启用废弃码，等于人为制造新的重复风险。
最后，我把全文压缩成两份可以直接用的清单。第一份是上架前的自查，第二份是发现问题后的处理顺序。
这 10 项全部通过的，基本可以放心提交。任何一项存疑，先解决再上架，这个顺序不要反过来。
写到这里，我想回到最开始那个判断：UPC 管理的分水岭，不在于你从哪个渠道买码，而在于你有没有把”码”当成一项需要持续管理的数据资产。
入门玩家关心的是”怎么拿到码”，进阶玩家关心的是”怎么保证这个码只用一次、用在对的地方、并且随时能查出来”。这两个问题的难度不在一个量级，但后者带来的收益是确定的：更少的上架驳回、更干净的销量数据、更短的周转周期。
如果你现在就要动手，我建议的顺序是：今天先导出全部 SKU 和 UPC，跑一遍完全重复比对，看看自己有没有藏着问题。这一步通常一小时以内就能完成，而它可能帮你避免下一次凌晨的报错截图。
我们是做家居类目的，UPC基本都是运营助理从供应商发的码包Excel里一行行粘进后台，最近上架老提示商品编码已被占用，我怀疑是内部撞码了。可一张表三百多行，肉眼看根本看不出哪两个一样，又不想为了这点事去装什么条码软件，想找个当天就能跑完的办法。
可以，前提是先把数据标准化，再比对。第一步，从各平台后台导出全量SKU-UPC数据，合并成一张表，字段至少包含SKU、UPC、渠道、状态、来源。第二步，把UPC列整列设成文本格式再粘贴，否则Excel会把12位数字变成科学计数法，前导零也会被吃掉，这一步没做的话后面查出来的重复全是假的。
第三步，做归一化：去掉首尾空格、去掉中间的全角空格和连字符、统一补足到12位。第四步，用COUNTIF或者条件格式把完全相同的值标红，这是最确定的重复。第五步，如果还怀疑有隐形重复，可以只取前11位（不含校验位）再做一次比对，因为改过校验位的复制品往往只差最后一位。
需要注意的是，比对口径必须是归一化之后的12位字符串，不要用数值口径；如果你的表里混有8位的UPC-E，要先转成12位UPC-A再比，否则同一商品会漏检。
我们有两个Listing共用一个UPC，一个是去年上架的老链接，有评论有销量，另一个是今年新开的，几乎没动静。运营说把新的那个换掉就行，但我担心换完之后老链接的历史数据、库存同步会不会出问题，也怕平台那边不认。
先做一道判断，再决定换谁。第一层判断：这两个SKU是不是同一个实体商品（同款、同色、同尺码），只是重复建档。如果是，通常不需要两个码，保留一个、把另一个下架或合并，重复的Listing并存反而会分散流量和评论。
第二层判断：如果不是同一商品，那就是真正的撞码，必须拆开，保留哪一个可以参考五个维度打分，历史销量、评论数量和质量、已铺渠道数、现有库存（尤其在平台仓的库存）、是否已被平台目录锁定。分数高的那个保留原码，另一个换新码，因为动老链接的代价通常更大。
换码前必须先确认平台是否允许你直接改后台的UPC：有一部分平台改编码后会重新匹配目录，可能生成新的商品ID甚至拆掉原有的变体关系，这一步要在测试账号或非主推SKU上先验证。
另外，如果旧码已经被平台仓库收货、包装上印着旧码，别急着后台一改了事，要留出标签和包装的过渡期，具体规则以你所在平台的最新政策为准。
上次我们换码，运营只在后台改了一个数字，结果一个月后财务对账发现SKU映射全乱了，仓库那边扫旧标签也扫不出来，广告报表里的数据直接断层。我现在想搞清楚，一个码换掉之后，到底牵动了多少地方。
后台改掉只是第一步，真正容易出事的是后面的同步。建议按这个顺序走：先改平台后台的商品编码和变体关系；再改ERP或进销存的商品档案，这一步决定采购、库存和财务能不能对上；再改WMS和条码标签模板，包括海外仓和平台仓的入仓标签；然后检查广告活动、优惠券、报表里按SKU或ASIN做的关联是否需要重建；
最后回头改供应商合同和采购单上的物料编号，以及包装印刷和说明书上的条码图形。有一个动作必须做：换码当天就登记一张“旧码，新码，生效时间，操作人”的映射表，历史订单和库存数据靠这张表回溯，不然对账时会找不到对应关系。已经贴了旧标签、进了平台的库存不要硬换，优先自然消耗完或者走平台允许的重新贴标流程。
整个链条里，后台改动是可逆的，标签和包装是不可逆的，所以顺序上先动系统、后动实物。
我们刚开始做跨境，一整套正规渠道的码对我们来说成本不低，就在网上买了一批很便宜的码，卖家说是正规可查的。但我心里一直不踏实，网上有人说这种码会被回收、被卖给好几个人，我拿到手也没法验证，就想知道有没有自己能做的自查动作。
有三个动作你自己就能做。第一，验证位数和校验位。以UPC-A为例，它是12位，最后一位是校验位，算法是：取前11位数据，从最右边一位开始交替乘以3和1（最右位乘3），求和后取个位，校验位等于10减去这个个位再取个位。
举个例子，前11位是03600029145，加权求和是58，个位是8，10减8等于2，所以完整码是036000291452，最后一位必须是2。如果卖家给你的码连校验位都对不上，那不用再往下看了。第二，看公司前缀。
UPC的前缀是GS1分配给注册主体的，不是你想编就能编的，你可以拿前缀去GS1的官方渠道核实是否属于某个真实主体，如果查不到、或者前缀明显不在正常分配范围内，就是风险信号。第三，看在平台上能不能正常识别，以及该码是否已经绑定了别人的品牌信息。
需要说清楚的是，转售码和生成器码的风险不在于它一定违法，而在于它可能被回收后重复售卖、前缀不属于你，导致你和别人撞码，或者平台在核验时认不出来，不同平台的容忍度不一样，具体以平台最新政策为准。
实操建议是：把码的来源作为一个必填字段记进主数据表，做风险分级，先替换主推SKU上的高风险码，不要用生成器码去补缺口，缺码优先走GS1或授权渠道申请。
读者评论
做过跨境运营的会有共鸣：UPC重复往往不是差一个码，而是码表来源和分配没人管。Excel删除重复项确实容易漏前导零和跨表重复，文章建议先标准化再比对，比较实用。我们后来也是先建SKU-UPC主数据表，上架驳回少了很多。
从多店铺卖家角度看，平台驳回通常已经晚了。文章提到换码要同步listing、ERP、WMS、包装标签和广告关联，这点很真实。我们之前只改listing，结果订单回传匹配不上，处理成本远高于上架前查一次。
文章把重复码成本拆成上架延误、库存占用和返工，能说服团队把查重前置。不过看板只能解决“看得见”，码的来源是否合规、是否归属自己，还是得回到GS1和平台政策人工核验，低价码包要谨慎。