去年 11 月，我给一个做家居收纳类目的卖家做旺季前诊断，他的店铺在一周内被连着下架了 14 条 listing。原因不是侵权，不是假货，也不是主图违规，而是他在半年前”顺手”把 20 个 UPC 反复分配给了 46 个 SKU。更麻烦的是，这 46 个 SKU 里有 11 个已经出单，2 个已经入仓，1 个已经积累了 30 多条真实评价。他问我：有没有一个 UPC 码管理模板，能让我以后别再犯这种错？我当时的回答是：模板本身不难，难的是你有没有把”重复码排查”当成一条每天在跑的流程，而不是一次性的表格整理。
这不是个例。我前后接触过三十多个跨境卖家的商品主数据，发现一个很反常识的规律：UPC 出问题的卖家，往往不是”没有表格”的那批人，而是”表格做得很漂亮”的那批人。他们有编号规则、有颜色标记、有各种字段，但表里没有任何一个机制去回答一个最基本的问题，这个码，之前有没有被用过？
所以这篇文章我不讲 UPC 是什么，也不讲怎么去 GS1 买码。我讲一件更具体的事：怎么用一份可落地的 UPC 码管理模板，把”重复码排查”做成一门标准化动作。文中会给出我实际在用的四张表结构、三条不可妥协的规则、三段可以直接抄的查重代码，以及我在一个六人铺货团队里跑了 12 周的数据观察。
先把结论摆出来，后面所有内容都是围绕这几条展开的。如果你只想要答案，看完这一节就可以去改表了。
绝大多数卖家的 UPC 表格，本质是”登记表”，记录这个码分配给了哪个 SKU。登记表解决的是”查得到”，但它不解决”防得住”。
真正的模板应该是一套排重机制：任何一个新码进入系统之前，必须经过至少三层校验；任何一次码与 SKU 的绑定，必须留下不可覆盖的记录。登记只是副产品。我见过太多团队把 90% 的精力花在字段设计上，却在”重复码怎么被拦住”这一环上一片空白。
这是我这几年最强烈的一个判断。重复码被发现的时点，直接决定了处理成本，而且是数量级的差异。
在码申请环节发现重复，你只需要换一个码，成本接近于零。在已经出单、已经入仓、甚至已经产生评价之后发现重复，你要面对的是下架、移除库存、申诉、重新刊登、评价清零，甚至账号层面的风险记录。同一个问题，发现时点不同，成本能差 50 倍以上。
很多人一听”标准化管理”就想到上系统、上中台、上主数据平台。我的经验恰恰相反：在月上新 500 个 SKU 以下，四张表格加三条规则就能覆盖 95% 的重复码风险。
四张表分别是：码池表、分配表、商品主表、排查日志表。三条规则是：一码一 SKU 不可复用、校验位本地重算、变体父子不共享 UPC。这四张表和三条规则，我会在第四节完整展开。
这是我踩过的一个坑。三年前我帮一个团队做数据治理，我们盯着”字段填完率”看了两个月，从 78% 提到了 96%，结果重复码该出还是出。因为填得全，不代表填得对。
后来我把考核指标换成两个：UPC 重复率（重复码条数 / 活跃码总数）和重复码平均发现时长（从绑定时点到被发现的天数）。第一个指标衡量存量风险，第二个指标衡量流程是否真的前置了。换成这两个指标之后，第三个月重复率就降到了 1% 以内。
重复码不是一个”失误”，它是流程缺口的必然产物。要设计出有用的模板，得先搞清楚重复是从哪儿冒出来的。我把这几年见过的情况归成五类，并按我的观察排了占比。
这是占比最高、也最隐蔽的一类。铺货型卖家的 SKU 更替极快，一个品测不出来就下架，新的品马上顶上。早期为了省成本，很多团队会买一批码，反复分配给不同的 SKU。
问题在于，平台并不认为”这个 SKU 已经下架了，码就可以回收”。UPC 一旦和某个 ASIN 建立过绑定关系，这条绑定在平台侧是有历史记录的。你把它分配给新 SKU，很可能触发”该产品 ID 已被使用”的提示，或者更糟，系统匹配到了旧 ASIN，造成两个完全不同的商品被合并。
我的判断是：UPC 不存在”回收”这个概念，只存在”退役”。退役的码应该被永久标记为不可用，而不是回到码池等待下一次分配。这一条如果写不进模板的规则里，模板就是废的。
变体是第二条高频踩坑路径，也是最容易被误判为”合规”的一条。很多卖家的理解是：既然是同一款商品的不同颜色，那共享一个 UPC 应该没问题。
这是错的。在主流平台的商品模型里，父体是虚拟的聚合节点，不参与销售，因此不需要 UPC；每一个子体都是独立销售单元，必须拥有自己独立的 UPC。父体和子体共用一个码、或者两个子体共用一个码，都属于规则层面的硬性冲突。
我遇到过一个典型case：卖家把同一款水杯的 5 个颜色建成 5 个子 ASIN，但只买了 1 个 UPC，想着”反正是同一款”。结果上架时只有第一个子体成功，后面 4 个反复报错，客服来回沟通了两周才发现是码的问题。
做多平台的团队，最容易在码表上失控。运营 A 在 Amazon 后台建一次档，运营 B 在 Walmart 后台又建一次档，两边各自维护一套 Excel。半年之后，两份表里的同一款商品可能已经有三个不同的 UPC 记录。
这类问题的根源不在操作，而在主键缺失。只要团队内部没有定义一个跨平台唯一的商品主键（通常是内部 SKU 编码），码表就一定会漂移。我的做法是：内部 SKU 编码优先于任何平台编码，UPC 只是内部 SKU 的一个属性，而不是反过来。
很多人以为重复码最坏的结果就是”上架失败，改一下就行”。真实的连锁反应要长得多，我用一个真实案例的时间线来说明。
某卖家在 3 月把 UPC-A 分配给了 SKU-1001，7 月 SKU-1001 因为销量不佳下架，运营把 UPC-A 复用给了新 SKU-1088。8 月 SKU-1088 上架成功，出单正常。9 月平台做数据校验，发现 UPC-A 存在两条历史绑定，触发了商品信息审核。结果是：SKU-1088 被暂停销售 6 天，期间产生的 47 个订单被取消，账号收到一次信息准确性警告，店铺整体流量权重在接下来的三周里下滑了约 12%。
从”复用了一个码”到”三周流量下滑”，中间隔了整整五个月。这就是为什么我说重复码排查必须前置，因为你根本不知道它什么时候会爆。
这一节我讲得直接一点。下面五种做法我在不同团队里都见过，它们的共同点是：做的人觉得自己已经在管了，但实际上风险敞口一点没变小。
条件格式的 COUNTIF 只能发现”字符串完全一致”的重复。而我在真实数据里看到的重复，超过三分之一是”看起来不一样、实际是同一个码”。
典型情况有三种：一种是前后带空格的 ” 012345678905″，一种是全角连字符或非断行空格混入，还有一种是供应商把最后一位校验位手抄错了，这时码在字符串层面确实是唯一的，但在业务层面它是错的。这三种情况，条件格式一个都抓不到。
这是我特别想纠正的一个认知偏差。重复码一旦进入实物环节，影响会溢出到库存和财务。
两个 SKU 共用同一个 UPC 时，如果供应商贴标也用了同一个码，入仓扫码就会出现歧义，系统可能把 A 商品的库存记到 B 商品名下。等你在财务上做库存对账时，会发现有一批货”凭空消失”，另一批货”凭空多出”。这类问题的排查成本极高，因为它不报错，只是数字慢慢对不上。
我见过最夸张的一份 UPC 表格有 47 列，包括”负责运营””供应商联系人””首次上架国家”等等。结果是运营平均填一行的耗时超过 4 分钟，填完就开始跳过，跳过三次之后整个表就没人维护了。
我的判断标准很朴素：一个字段如果不能参与排重、不能参与追溯、不能参与责任归属，就不该出现在第一版模板里。第一版我建议控制在 12 到 15 列，跑顺了再按需要加。
正规渠道能保证这个码在全局范围没有被别人买走，但它保证不了你内部不重复分配。我处理过的重复案例里，有相当一部分用的是完全合法合规采购的码。
同样，正规采购也保证不了校验位一定对，因为校验位是人工或工具在录入环节写进表格的，抄错一位，它就不再是那个码了。所以校验位必须本地重算，永远不要相信别人给你的第 12 位。
这是最危险的一种。有人在表里发现重复码，第一反应是去重，删掉多余的行。但如果那两行背后已经各绑定了一个在售 SKU，你删掉一行，等于在表里抹掉了这个事实，而平台上两个 ASIN 依然共用着一个码。
正确的动作是：不删除，只标记。把冲突记录下来，进入人工处置队列，等两个 SKU 的归属确认清楚之后再更新状态。表里的历史，就是这个团队的审计日志。
这一节是全文最有实操价值的部分。因为在讨论技术实现之前，你得先想清楚一个问题：我们要查的”重复”，到底包含哪几种情况？
两个 SKU 的记录里 UPC 字符串完全一致。这是最容易发现的一种，也是唯一一种用条件格式就能解决的问题。判定方式：直接字符串相等比较。
字符串不完全一致，但去掉空格、统一全半角、去掉连字符之后完全一致。判定方式：先做标准化清洗，再比较。我用的是把非数字字符全部剔除、只保留数字串的方式，简单且不容易出错。
前 11 位相同、只有第 12 位不同。这种情况往往是同一个人连续录入时抄错了校验位，或者是同一批码被拆开卖给了两拨人。判定方式：截取前 11 位做分组统计，任何一组的记录数大于 1 就告警。
码值本身在全局是唯一的，但父体和子体、或者两个子体之间共享了同一个码。判定方式：把商品关系表 join 进来，沿着父子链路检查码的唯一性。
同一个 UPC 在两个平台上被绑定到了两个不同的商品主体。这种情况在单平台视角下永远发现不了，只有在做跨平台主键对齐时才会暴露。判定方式：按 UPC 分组，检查其关联的内部 SKU 编码是否多于一个。
一个常见的错误设计是：只要发现重复就直接阻断流程。这在实操中会带来大量误杀，运营会开始想办法绕过规则，规则就失效了。
我用的是一套三级响应机制，你可以直接抄：
下面这四张表是我线上一直在用的结构，字段做过几轮删减，目前是”够用且填得动”的状态。
| 表名 | 作用 | 核心字段 | 关键约束 |
|---|---|---|---|
| 码池表 upc_pool | 记录所有采购到的码及其状态 | upc、batch_no、purchase_date、status | upc 为主键，status 取值为 free/bound/retired |
| 分配表 upc_assignment | 记录码与 SKU 的绑定历史 | upc、internal_sku、bind_time、unbind_time、operator | unbind_time 为空表示当前有效绑定 |
| 商品主表 product_master | 商品基础信息与变体关系 | internal_sku、parent_sku、platform、site、category | internal_sku 全局唯一，跨平台共用 |
| 排查日志表 upc_audit | 记录每次排查的结果与处置 | check_date、check_rule、hit_upc、level、action、owner | 只增不改，作为审计依据 |
规则一：一码一 SKU，绑定不可覆盖。允许解绑，但解绑后原码进入 retired 状态，不回到 free 池。这条规则是整套体系的地基，破了它后面全白搭。
规则二：校验位必须本地重算。无论码是谁给的，入库时都用同一段逻辑重新计算第 12 位，不一致的直接标记为”待核”。我用的是下面这段 Python，二十行不到，跑一万条不到一秒。
def upc_a_check_digit(eleven_digits: str) -> str:
"""根据 UPC-A 前 11 位计算第 12 位校验位"""
if len(eleven_digits) != 11 or not eleven_digits.isdigit():
raise ValueError("必须传入 11 位纯数字")
total = 0
for idx, ch in enumerate(eleven_digits):
weight = 3 if idx % 2 == 0 else 1
total += int(ch) * weight
return str((10 – total % 10) % 10)
使用示例
code = "01234567890"
print(code + upc_a_check_digit(code)) # 012345678905
规则三：变体父子不共享 UPC。在写入分配表之前，先用商品主表查出该 SKU 的父体和所有兄弟 SKU，检查拟分配的码是否已被其中任何一个占用。这一步是很多团队缺失的，也是变体类重复码的唯一有效拦截点。
如果你暂时没有系统，只有数据库或者只有 Excel，下面三段够你起步了。
SELECT a.upc, COUNT(*) AS bind_cnt, GROUP_CONCAT(a.internal_sku) AS sku_list FROM upc_assignment a JOIN product_master p ON p.internal_sku = a.internal_sku WHERE a.unbind_time IS NULL AND a.upc IS NOT NULL GROUP BY a.upc HAVING COUNT(*) > 1 ORDER BY bind_cnt DESC, a.upc;
这段 SQL 的关键在 WHERE a.unbind_time IS NULL 这一行。它只查当前有效的绑定关系，把历史解绑记录排除掉。很多团队漏掉这一行，结果报表里全是已经处理完的历史重复，噪音大到没法用。
SELECT SUBSTR(REPLACE(REPLACE(upc, ' ', ''), '-', ''), 1, 11) AS prefix11, COUNT(DISTINCT upc) AS variant_cnt, GROUP_CONCAT(DISTINCT upc) AS code_list FROM upc_pool WHERE status <> 'retired' GROUP BY prefix11 HAVING COUNT(DISTINCT upc) > 1;
假设 A 列是 11 位码身，B 列是填写好的 12 位完整码，那么：
校验位重算（C2）：
=MOD(10-MOD(SUMPRODUCT(MID(A2,ROW(INDIRECT("1:11")),1)*{3;1;3;1;3;1;3;1;3;1;3}),10),10)
校验位是否一致（D2）：
=IF(TEXT(C2,"0")=RIGHT(B2,1),"一致","待核")
是否重复（E2，针对规范化后的 B 列）：
=IF(COUNTIF($B$2:$B$100000,B2)>1,"P0-重复","")
是否与前11位同源（F2）：
=IF(SUMPRODUCT(--(LEFT($B$2:$B$100000,11)=LEFT(B2,11)))>1,"P1-同源","")这五列加起来，就覆盖了字面重复、规范化重复（前提是你先用清洗列替换掉空格和连字符）和校验位同源三类风险。配合一张商品关系表做 VLOOKUP，变体关系也能查。
前面讲的都是方法。这一节我把方法放回一个真实的执行环境里，看看它到底跑成什么样。
这是一个做家居与户外类目的铺货团队，六个人，其中两个运营负责上新，一个人兼做采购和物流，剩下三个人做客服和广告。当时的状态是：月上新 400 到 600 个 SKU，分布在三个平台、五个站点，UPC 记录散落在七份 Excel 里。
他们给我的第一份数据是：活跃码 14,300 个，能找到重叠绑定的重复码 1,247 个，重复率约 8.7%。其中已经上架在售的重复码 186 个，已经出单的 61 个。
整个过程分三步，没有上任何重型系统，核心动作是把散落的码表收敛到一个主数据源上。
这里我想专门说一下为什么在第一步选了数跨境。原因很实际：那批卖家的商品分散在多个平台多个店铺，我需要一个能把多店铺商品数据汇总到一处的地方，才能谈得上”按内部 SKU 做跨平台对齐”。数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）在商品与 SKU 主数据这块的管理能力，让我在两天内拿到了原来一周都拼不齐的清单。
工具本身的界面和字段会随版本迭代，我不做具体功能承诺，但从”先把主数据收敛、再做排重”这个顺序来看，这是我认为最合理的起点。
下面是我按周记录的三个指标。前两周数据很难看，因为全量排查会把历史遗留问题全部翻出来，指标反而会先恶化再改善。
几个我认为值得记下来的观察：
负责人最关心的还是这个。我按他们的实际客单价和流量水平做了一个成本拆解，下面这张图是修复前后月均成本的对比。
方法不能一刀切。我按我见过的团队规模，把建议分成三档，你可以直接对号入座。
这个量级完全不需要系统。一张 Excel，A 到 L 列，加上第四节的校验位公式和重复标记公式，就够用了。
唯一要额外做的一件事是：把这张表放在共享盘里，而不是某个人电脑桌面上。我见过太多团队的问题不是公式不够好，而是表格存在个人本地，换个人就找不到。
到这个量级，手工比对开始出错了。建议做三件事：第一，把码池和分配拆成两张表，码池用来自动分配；第二，把第四节的 SQL 或 Python 脚本跑起来，每周固定时间执行一次；第三，把排查结果写进日志表，作为审计线索。
这个档位的关键不是工具，而是把排查变成日历上的固定动作。我建议固定在每周一上午，因为周末通常有上新，周一排查能覆盖周末产生的风险。
这个量级必须有一个统一的主数据源，而且必须在上架接口提交之前做预校验。校验不通过就不允许提交，把风险挡在平台之外。
我的建议是先在数跨境这类工具里把跨平台商品主数据管住，再在这个基础之上叠加排重规则。原因是：没有统一主键，任何排重都是局部的、会有盲区。先把主数据收敛到一处，再谈规则，顺序不能反。
代运营团队有一个特殊风险：多个客户共用一套码表。如果隔离没做好，A 客户的码可能被分配到 B 客户的商品上，这是合同层面的严重问题。
我的做法是：码池表加一个 client_id 字段，所有查询强制带 client_id 过滤条件，并且在数据库层面用视图做隔离。不要依赖操作者自觉加条件，人一定会忘。
如果你的店铺现在已经有重复码导致的在售问题，按这个顺序处理：
这一节讲的是我在实际项目里反复权衡的几组矛盾。它们没有标准答案，取决于你的业务节奏和风险承受能力。
很多团队的顺序搞反了，先看系统多少钱，再决定做不做。正确的顺序是：先算清楚重复码一年给你造成多少损失，再拿这个数字去对比系统成本。
如果年化错误成本不到 2 万元，自研或纯表格就够了。如果超过 10 万元，那采购一个能管主数据的工具是明显划算的。中间地带最纠结，我的建议是先用模板加脚本撑住，同时把错误成本持续记录下来，攒够数据再做决策。不要凭感觉拍。
严格拦截的好处是风险低，坏处是误杀会激怒运营。软提醒的好处是灵活，坏处是提醒会被无视。我个人的做法是在 P0 级别严格拦截，在 P1、P2 级别只告警，并且明确告诉团队：P1 告警必须在 24 小时内处置，超时自动升级为 P0。
这条”超时升级”的规则很关键。它让软提醒有了牙齿，同时又不至于在第一时间卡住业务。
集中采购的好处是码池统一、容易管理，坏处是采购周期长，旺季可能会卡住上新。分散采购的好处是快，坏处是码池失控。
我的建议是：码池必须集中，采购动作可以分散。也就是说，不管是哪个运营去买的码，买完都要统一登记到同一个码池表里。这样既保留了灵活性，又不会失控。
全量排查很痛苦，尤其是码表已经积累了几年的时候，跑一次可能要一两周。但不做全量，你就永远不知道脚下的地雷在哪。
我的判断是：必须做一次全量，但可以分批做。先查在售商品，再查近 12 个月有出单记录的商品，最后查历史归档。按风险优先级排，而不是按时间顺序排。
写到这里，我把整篇文章的核心判断收一下，顺便给你一个可以明天就动手的清单。
第一，UPC 管理模板的成败，取决于它有没有排重机制，而不取决于它有多少字段。一份 47 列的表格救不了你，一份 12 列但能在绑定前拦住重复码的表格可以。
第二，重复码的成本不是线性的，而是随发现时点呈指数上升。申请环节发现的成本是 0.3 人时，旺季出单后发现的成本是 26 人时，中间差了近 90 倍。所有投入都应该往”前置”这个方向加。
第三，跨平台重复是最容易被忽略的一类，也是主数据不统一才会产生的一类。如果你的商品分散在多个平台，先把主键收敛起来，再谈排重，否则永远有盲区。
我最后想说的一点是：UPC 重复码问题，本质上不是数据问题，而是责任问题。
几乎所有我见过的重复码，追根溯源都能找到一个共同的成因，没有人为”这个码能不能用”这件事负责。运营认为采购该负责，采购认为运营该检查，两边都觉得模板会自动处理。结果就是没人真正看过一眼。
所以模板里最重要的一列，可能不是你想象的 UPC 本身，而是 operator 这一列，谁绑定的、什么时候绑定的、依据是什么。把责任落到具体的名字上，比任何一条查重规则都管用。
如果你是多平台运营，我建议把”主数据收敛”这一步单独拎出来先做。可以先在数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）这类工具里把跨平台商品主数据统一管起来，拿到一份以内部 SKU 为主键的完整清单，再在此基础上叠加排重规则。有了这份清单，后面所有排查才有共同的语言。
最后提醒一句：模板上线后的前两周，重复率指标大概率会变差。那不是失败，那是你第一次真正看清了自己的库存底数。撑过那两周，后面就是持续变好。
我手上有一张从ERP导出的商品表，五千多行，平台陆续提示‘该UPC已被使用’。我试过用Excek排序然后肉眼扫，扫到第三遍就眼花了，还漏了两条。后来我想知道有没有一套固定的排查口径和公式，能一次把重复码全揪出来。
先把数据洗干净再比对，否则你查到的一半是假重复。第一步统一格式：UPC是12位数字，必须存成文本格式，如果在Excel里是数值格式，前导零会被吃掉，000123456789会变成123456789，跟另一个真实的9位码撞在一起，这是最常见的误判来源。
第二步用公式定位：在空白列写=COUNTIF(B:B,B2)>1，向下填充，TRUE的就是重复项；再用条件格式把TRUE标红，一眼能看到。
第三步分口径统计：按‘同一UPC出现次数≥2’算重复记录，同时单独统计‘同一UPC对应不同SKU’的数量，后者才是真正需要处理的硬重复，前者可能只是同一SKU在多个店铺各录了一次。最后把结果按平台、店铺、负责人分组导出，重复率=硬重复UPC数÷总UPC数，超过1%就说明录入流程有漏洞，不是运气问题。
我在某项目管理平台里自己搭了一张UPC登记表，字段是拍脑袋加的，结果上架旺季发现查不到‘这个码是谁什么时候申请的’‘现在还在用吗’。想知道一张能真正支撑重复码排查的模板，字段应该怎么分层设计。
按三层设计，缺一层排查就会卡住。第一层是标识层：UPC（文本格式12位）、校验位是否正确、SKU、ASIN、变体主题（颜色/尺码），这一层决定‘码和商品能不能唯一对应’。第二层是归属层：所属店铺、所属平台、供应商、申请日期、申请人、是否GS1官方购买，这一层决定‘出了问题找谁’。
第三层是状态层：状态（待上架/在售/已下架/冻结）、首次上架日期、最后核对日期、核对人、备注，这一层决定‘这个码现在还能不能用’。实际使用中还要加一个‘已占用UPC池’视图，把下架商品释放出来的码单独隔离，不直接回收到可申请池，至少观察90天，因为平台侧的历史记录不会因为你下架就立刻清除。
字段不用多，但这三层一个都不能省，缺了状态层，排查出来的重复码你根本不知道该保留哪一条。
我们三个店铺两个人同时上架，A同事申请过的码B同事根本不知道，等平台报错才发现撞了。我更担心的不是已经重复的，而是每周还在新增重复，排查做得再勤也是白搭。
防新增的核心是‘单一数据源+申请前置’，不是靠事后排查。具体做法：第一，UPC登记表只保留一份，放在所有人都有权限的某项目管理平台或在线表格里，禁止任何人本地另存一份再改，本地副本是重复码的最大来源。
第二，把申请动作变成流程而不是自由操作：上架前必须先在登记表里搜一次UPC和SKU，搜不到才走申请，申请提交后由一个人统一分配，分配时用公式或脚本自动查一次是否已存在，存在就驳回。
第三，预留分段管理，如果你们自己买码段，按店铺或品类把码段切开，比如A店铺用000-499区间、B店铺用500-999区间，物理上就不可能撞。第四，每周做一次增量核对，只查本周新增的行，比全量核查快得多，也更容易坚持。判断标准很简单：如果你们每周新增重复数为0且连续四周成立，说明流程封住了。
查到有几条重复，但情况不一样，有的是同一款商品在两个店铺各上了一次，有的是两个完全不同的SKU撞在一起，还有的是老品下架后码被新品复用了。我不确定哪些必须改，哪些可以放着不管，怕改错了影响已有销量和评价。
先分类再动手，四类处理方式完全不同。第一类‘同商品跨店铺重复’：如果两个链接同款同码，属于平台明确禁止的重复铺货，保留销量和评价更好的那条，另一条下架，不要试图改码保留，改了就是两套UPC对应同一实物，后续对账会更乱。
第二类‘不同SKU硬撞’：必须尽快处理，给其中一个换新码，优先给新上架、销量低、评价少的那条换，换码后重新提交平台审核，老链接的排名和评价留在原码上，损失最小。第三类‘老品下架后码被复用’：如果平台侧已彻底释放，可以继续用，但要在登记表里把它标记成‘二次使用’并记录原商品，避免以后对账对不上；
如果平台还留着历史记录导致新链接报错，就只能换新码。第四类‘录入错误导致的假重复’：比如前导零丢失、多了空格、同一行重复录入，直接改表不改链接。处理完一定要回写登记表，把处理方式、处理人、处理日期记上，否则三个月后同样的问题会再出现一次，而没人记得上次是怎么解决的。
读者评论
关于“UPC 只退役不回收”这条我深有同感。去年我们也踩过复用旧码的坑，当时以为 SKU 下架了码就空出来了，结果新链接上架两周后突然被合并到旧 ASIN 下面，评价全串了。后来我们是直接在码池表里加了一列“冻结日期”，任何码一旦绑定过就永久锁定，宁可多买一批码也不敢再复用。这个动作看起来笨，但半年下来确实没再出过事。
文章给的成本对比图挺直观，但想确认下样本量。21 个卖家的访谈推演值，落到不同类目差异其实很大。做铺货的月上新几百个 SKU，可能一个月就撞一次重复；做精品的一年才几十个 SKU，重复率天然就低。把这两类混在一张图里算平均，容易让人误判自己团队的紧迫程度。建议按上新频率分个层，参考价值会更高。
四张表三条规则这套逻辑我认，但对铺货团队来说落地最大的阻力不是建表，而是谁在什么时候执行校验。我们试过让运营在上架前手动查重，前两周还行，一到旺季上新节奏上来就全乱了，最后还是得靠脚本在提交前拦。想请教下，如果团队没有开发资源，只靠表格加人肉流程，有没有什么低成本的方式保证校验不被跳过？光靠制度约束我觉得不太现实。