去年八月，一个做家居品类的卖家给我发来一张后台截图：七个店铺共用同一批 UPC 码，48 小时内连续被压下 11 条 listing，提示都是“商品详情页与已有 ASIN 冲突”。他第一反应是去平台后台搜码、逐条申诉，折腾三天，被压的 listing 从 11 条涨到 19 条。问题根本不在申诉速度，而在于他手上没有任何一张表能回答一句话：这个码，在哪个店、哪个站点、哪条 listing 上用过。
UPC 码店群管理里的重复码排查，起点从来不是平台后台，而是你自己的码库基线。
我先给结论，再给推理。UPC 重复排查的正确起点是建立一张以 UPC 为唯一主键的码库映射表，并在这张表里完成第一轮去重。平台通知、后台搜索、申诉工单都是下游动作，它们只能处理已经暴露的问题，处理不了还在潜伏的重复。
店群模式下，UPC 不是“商品属性”，而是“资产编号”。它必须像财务科目一样被登记、被索引、被审计。你如果没有把 UPC 当成主键来管理，那么无论你有多少个店铺、多少条 listing，本质都是一盘散沙。
我通常建议卖家先做一件事：把全店铺的 SKU 明细导出来，保留 UPC、店铺 ID、站点、ASIN、MSKU、创建时间、UPC 来源这七列，然后按 UPC 分组做 COUNT。这一步做出来，80% 的重复码当场现形，不需要连平台，不需要申诉，不需要等通知。
平台通知是结果，不是原因。当你收到第一条 UPC 冲突通知时，说明这个码已经在平台上被另一个 ASIN 占用了，可能是你自己的另一个店铺，也可能是别人的商品。此时你处在被动位置：要么申诉，要么换码，要么删建。
更麻烦的是时间差。平台侧的商品详情页合并、变体归并、品牌备案校验都有延迟，同类问题往往批量爆发。你处理的每一条 listing，都在消耗运营的时间；而新的重复还在源源不断地被上传。这就是为什么很多人“越申诉越多”。
排查顺序应该是：口径定义 → 码库基线 → 内部去重 → 平台映射核对 → 外部占用核验。顺序颠倒，成本至少翻三倍。
要排查重复，先得知道重复从哪来。我经手过十几个店群卖家的码库审计，UPC 重复的来源高度集中在五个渠道，而且每个渠道的重复机理完全不同，处理方式也完全不同。
（1）GS1 官方申请。这是最干净的一类，码段属于你自己公司，全球唯一，理论上不会重复。缺点是成本高、需要企业资质、申请周期长，很多店群卖家早期不愿意走这条路。
（2）供应商或工厂提供。工厂自己有品牌备案和 GTIN 豁免，提供给你的码通常也是唯一的。风险在于工厂可能同时供货给多个卖家，如果它把同一批码给了两家，你在别的店铺就会撞码。
（3）第三方批量采购。这是店群模式最主流的做法，也是最容易出问题的一类。市面上大量流通的“便宜码”，本质是回收码、二手码、失效注册码，已经被别人注册过商品信息，你买了之后建 listing 会直接映射到别人的 ASIN 上。
（4）内部复制粘贴。这是被严重低估的一类。运营用 Excel 批量导入时下拉填充、复制整列、跨店铺搬 listing 模板，都会造成同一个码被两条以上 SKU 使用。我见过的码库里，这类重复往往占大头。
（5）系统翻译错误。多站点铺货时，用工具把美国站 listing 一键翻译并复制到欧洲站，工具如果不换 UPC，就会出现同一站点内多条 SKU 共用一码的情况。
前面那位家居卖家，我帮他把时间线还原了出来。第一批被压的 11 条 listing，集中在两个店铺，都是当季主推款。他当时的处理方式是逐条申诉，每条约 40 分钟，包括截图、写说明、找采购发票。
到第 9 天，第二个店铺出现同类问题，被压 5 条。第 17 天，第三个店铺被压 6 条，同时有一条 listing 被合并到别人的详情页，主图和五点描述被覆盖。到第 26 天累计被压 19 条，直接损失的广告消耗约 1.8 万元，返工人工约 42 小时。
而真正的根因排查，用了一天半。我让他导出七店铺全部 SKU 的 UPC 列，按 UPC 做透视，发现 19 条被压 listing 中有 14 条共用了同一批 23 个码，这批码是他三个月前从第三方渠道一次性采购的 5000 个码中的一部分。
如果他三个月前就做了这份透视，损失可以压缩到接近于零。这就是“排查起点选错”的真实代价。
很多人把所有“UPC 一样”都当成同一种问题，这是误区。我在实际审计中把重复分成三种形态，它们的判定逻辑和处置动作差异很大。
| 重复形态 | 典型特征 | 判定难度 | 处置动作 |
|---|---|---|---|
| 完全重复 | 同一码被两条以上 SKU 使用，字段字符完全一致 | 低，纯字符比对即可 | 保留最早创建的一条，其余换码或归并 |
| 跨店铺复用 | 同一码在不同店铺的不同 ASIN 上使用 | 中，需要跨店铺合并数据 | 按站点区分：同站点必须拆码，跨站点可保留 |
| 跨变体复用 | 父子变体中，多个子体共用一码 | 高，需理解变体结构 | 每个子体必须独立码，否则平台会合并或拒绝 |
| 格式变形重复 | 前导零丢失、空格、全角字符导致的“伪唯一” | 高，肉眼几乎看不出来 | 统一清洗后再比对，否则会漏掉大量重复 |
特别注意第四种。UPC 是 12 位数字，但在导出 Excel 时，前导零经常被吃掉，变成 11 位；或者从不同系统导出时混入了空格和不可见字符。这种情况下，你的“去重”实际上是失败的，表面上没有重复，实际上重复得很严重。
我在帮卖家做码库审计时，几乎每次都会遇到同样四个误区。它们看似常识，但每一个都会让排查方向跑偏。
重复不一定违规，违规也不一定重复。同一个 UPC 在同一个平台的不同站点上使用，通常是允许的；同一个 UPC 在同一站点的不同 ASIN 上使用，几乎必然出问题。如果你不分站点一刀切，会把大量本来合规的码误判为问题码。
反过来，有些码在格式上完全唯一，但因为被第三方注册过商品信息，上架时会直接映射到别人的 ASIN。这种“外部占用型”问题，靠内部去重永远查不出来。内部去重解决的是“自撞”，外部核验解决的是“他撞”，两者不能互相替代。
Excel 的“删除重复项”只做精确匹配，不做归一化。如果你的数据里存在前导零丢失、全角数字、尾部空格，它会把本质上相同的码判定为不同。我做过一次对比测试，同一份 12000 行的数据，直接删除重复项识别出 173 组重复；先做清洗再比对，识别出 291 组。漏检率接近 40%。
清洗的规则至少要包含四条：去空格、去不可见字符、统一半角、补齐前导零到 12 位。其中补齐前导零这一步，必须在文本格式下操作，否则 Excel 会继续吃掉零。
这是最伤元气的做法。listing 一旦删除，评论、排名、历史销量全部归零，而重复的根因还在码库里，新建的 listing 只要还用那个码，问题会再出现一次。正确顺序永远是从数据层查源头，再决定这条 listing 是换码、合并还是放弃。
UPC-A 是 12 位，最后一位是校验位。校验位不匹配的码，从源头就是无效码，不可能在任何平台上成功注册。有些卖家买到的批量码里混着校验位错误的码，上架报错后去查重复，方向完全错了。
校验位计算规则很简单：前 11 位中，奇数位乘 3，偶数位乘 1，求和后取模 10，再用 10 减去余数，结果对 10 取模即为校验位。用 Excel 公式可以直接批量校验：
=MOD(10-MOD(SUMPRODUCT(–MID(A2,{1,3,5,7,9,11},1))*3
+SUMPRODUCT(–MID(A2,{2,4,6,8,10},1)),10),10)
把结果和目标码的第 12 位做比对，不一致的就是无效码。这一步应该放在所有排查的最前面，因为它能把“无效码问题”和“重复码问题”彻底分开，避免把时间浪费在错误的方向上。
我把排查逻辑固化成四层漏斗。每一层解决一类问题，上一层不通过就不进入下一层。这样做的好处是永远不会在错误的方向上浪费算力，也不会因为上游数据脏而误判下游结论。
这一层只做三件事：长度校验、字符校验、校验位校验。长度必须是 12 位（若是 EAN-13 则 13 位，若是 GTIN-14 则 14 位），字符必须全部是半角数字，校验位必须匹配。三项中任何一项不通过，直接归入“无效码”池，不参与后续重复比对。
这一层的价值在于把问题的性质区分开。无效码是采购和质量问题，重复码是管理问题，两者的处理路径完全不同。混在一起排查，效率会掉一大截。
清洗之后，按 UPC 分组统计该码关联的 SKU 数量、店铺数量、站点数量。判定规则我建议这样设定：同一 UPC 在同一站点关联超过 1 个 ASIN，即为冲突；同一 UPC 在同一店铺关联超过 1 个 MSKU，即为内部重复；同一 UPC 跨站点复用，标记为观察项，不直接判定冲突。
这一层用一条 SQL 就能跑出来，而且可以做成每日定时任务。下面是我常用的查询结构：
SELECT upc, COUNT(DISTINCT asin) AS asin_cnt, COUNT(DISTINCT store_id) AS store_cnt, COUNT(DISTINCT site) AS site_cnt, MIN(created_at) AS first_used, MAX(created_at) AS last_used FROM listing_sku WHERE upc IS NOT NULL AND upc <> '' GROUP BY upc HAVING COUNT(DISTINCT asin) > 1 AND COUNT(DISTINCT site) > 1 ORDER BY asin_cnt DESC;
把结果按 asin_cnt 降序排列，最上面几条就是要优先处理的。我通常建议先处理影响 ASIN 数最多的前 20 组，因为它们的波及面最大。
店群卖家往往同时做多个平台。同一个 UPC 在不同平台上注册到不同商品，虽然平台之间不一定互通，但会造成库存、订单、广告数据的错乱，也会在某个平台做品牌备案时暴露出来。
这一层需要一张跨平台的映射表，字段至少包含：UPC、平台、店铺、站点、商品 ID、商品名称。检查逻辑是看同一个 UPC 在不同平台上是否指向了差异过大的商品。如果同一个码在 A 平台是“陶瓷马克杯”，在 B 平台是“不锈钢水壶”，这就不是简单的重复，而是码库污染，必须立即拆码。
前三层解决的是内部问题。第四层才是真正去平台上核验这个码有没有被别人占用。核验方式是抽样：从码库里抽一定比例（我一般取 5% 到 10%），在目标站点前台搜索，看是否已有商品详情页，以及该详情页的品牌归属。
抽样比例可以按来源调整。第三方批量采购的码段，抽样比例要拉到 20% 以上；GS1 官方申请的码段，2% 到 3% 就够。这样可以在成本可控的前提下，把外部占用风险摸清楚。
讲完了逻辑，得讲工具落地。上面这套四层漏斗，如果全靠人工在 Excel 里跑，一旦店铺数量上到十个以上，每周更新一次就会变成灾难。我现在的做法是把多店铺数据接到数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys），在它的多店铺数据接入基础上建一张 UPC 主键台账。
核心原因是它解决的是“多店铺数据合并”这个前置问题。店群卖家最痛的不是分析，而是把七到二十个店铺、好几个站点的 listing 明细凑到一张表里。它支持多平台多店铺数据接入，能把不同店铺的 SKU 明细汇总到同一套字段体系下，这一点比在 Excel 里手工拼表省事太多。
第二个原因是字段可控。UPC 台账需要固定的七列结构：UPC、店铺、站点、ASIN、MSKU、创建时间、码来源。用自定义报表把这七列固定下来，每次刷新就是一次全量基线核对，不需要重新搭表。
第三个原因是异常可追踪。重复码不是一次性问题，它会随着新店铺、新 SKU 持续产生。把 UPC 重复组数做成一个持续观察指标，比每隔三个月做一次大扫除要靠谱得多。
第三步里最关键的是排序。很多人做出来一张重复清单就不管了，结果处理的都是影响面小的，真正影响十几个 ASIN 的码排在后面。按影响面排序，等于用最小的动作解决最大的风险。
我用同一套方法跟了一个 14 个店铺的卖家六个月。下面这组数据是我从他的记录里整理出来的，为了脱敏做了区间化处理，属于样本推演性质，但趋势可以说明问题。
| 观察指标 | 建立基线前（月均） | 建立基线后（月均） | 变化 |
|---|---|---|---|
| 新增重复码组数 | 47 组 | 6 组 | -87% |
| 重复码平均发现时长 | 19 天 | 1.5 天 | -92% |
| 因 UPC 导致的 listing 返工数 | 11 条 | 2 条 | -82% |
| 人工核对耗时 | 26 小时/月 | 4 小时/月 | -85% |
| 新 SKU 上架一次成功率 | 84% | 97% | +13 个百分点 |
这里我要特别说明一点：新增重复码组数并没有降到零。六个月里每个月仍然稳定产生 4 到 8 组新重复，主要来源是新店铺开张和新运营入职时的模板搬运。这说明重复码不是可以被“彻底消灭”的问题，它是一个需要持续监控的运行指标。
把目标从“清零”改成“控制在个位数”，是我在实操中最重要的认知转变。追求清零会导致过度管控，拖慢上架速度；完全不管会导致批量事故。控制在个位数、发现时长压缩到两天以内，才是性价比最高的状态。
我在整理这六个月数据时发现一个有趣现象：重复组数最高的第一个月，实际损失反而最小；而第四个月只有 11 组重复，却出了一次比较严重的事故，因为其中一组重复的码关联了主推款，被合并的详情页已经积累了 2000 多条评论。
结论很清楚：重复码的风险不等于重复码的数量，而等于重复码所关联 ASIN 的权重。一个关联 50 条评论的码，和一个关联 2000 条评论的码，风险量级差十几倍。
所以排序规则要升级。不能只按“关联 ASIN 数”排序，还要叠加“关联 ASIN 的评论总数”和“近 30 天销量”两个权重。我现在用的优先级公式大致是：影响 ASIN 数 × 0.4 + 评论总量归一化值 × 0.4 + 近 30 天销量归一化值 × 0.2。这个公式不精确，但足以把真正要命的码排到最前面。
排查逻辑是通用的，但落地动作必须按规模和阶段区分。我用店铺数量做主线，配合码库成熟度，给出四套可执行的方案。
这个阶段不需要工具，一张 Excel 就够了，但必须做成“活表”。具体做法是：建立 UPC 台账，固定七列结构，UPC 列设为文本格式，每周更新一次，用条件格式标出重复项。
关键是格式设置。导入前先把 UPC 列设成文本，再粘贴数值，否则前导零会丢。这一步如果做错，后面所有排查都是白费。同时加一列校验位公式，把无效码先剔除。
这个阶段的重点是建立习惯，而不是追求自动化。每周一次，每次半小时，成本可以接受。等到店铺数超过五个，再考虑工具化。
这个规模下，手工拼表已经不可行。核心动作是三件：多店铺数据自动接入、UPC 主键台账自动生成、重复组数做成日级指标。数跨境在这个阶段比较合适，因为它解决的正是多店铺合并的问题，而不只是单店分析。
我建议这个阶段把重点放在“增量监控”上。不要只看当前的重复总量，要看每天新增几组、每天修复几组。如果新增持续大于修复，说明源头还在漏，需要回到采购和上架流程去找原因。
另外建议固定一个责任人。我见过太多卖家把这件事交给运营兼着做，结果一忙就停。UPC 台账应该像库存盘点一样，有明确的周期和责任人。
这个规模下，事后排查已经不够，必须把校验前置到上架流程里。具体做法是把 UPC 唯一性校验做成上架前的强制卡点：任何新 SKU 在提交上架前，必须通过码库比对，未通过的不允许进入下一步。
这一步通常需要和内部系统配合。如果用的是 SaaS 化的项目管理工具或 ERP，可以做成一个校验节点；如果系统不支持，就退而求其次，用共享表 + 审批流程实现。核心是让“重复码”在产生的那一刻就被拦住，而不是等它产生损失之后。
这个阶段还应该建立码段台账，把不同来源的码段分池管理。GS1 官方码段、供应商码段、第三方采购码段分别编号，不同池子的抽样核验比例和审批权限不同。这样即使出现问题，也能快速定位到是哪一批码、哪一个渠道。
排查方案没有绝对最优，只有适合当下的取舍。我把几个关键取舍点摊开讲，每个都说清楚什么情况下选哪边。
自建表格的优势是完全可控、成本低、随时改规则；劣势是无法自动刷新、多店铺合并靠人工、容易因为人员变动而断档。采购工具的优势是数据接入稳定、可日级刷新、多人协作；劣势是需要适应期、字段结构相对固定、有固定成本。
判断标准很简单：如果你每周花在拼表上的时间超过 3 小时，就值得上工具；如果不足 1 小时，就别折腾。用时间成本而不是店铺数量做判断，更贴近实际。
存量清洗是一次性大工程，能在短时间内把重复组数打下来，但如果不控制增量，三个月后又会回到原点。控制增量见效慢，但可持续。
我的建议是先花两周做一次存量清洗，把最危险的那批码处理掉，然后立刻转成增量监控模式。不要试图一次性把所有重复都清干净，那个过程会拖很久，而且期间新问题还在产生。
发现重复之后，有两条路：换码重建，或者合并 listing。换码的代价是权重清零，但彻底干净；合并的代价是保留部分权重，但需要处理详情页冲突，而且可能留下后患。
判断依据是这条 listing 的权重。评论数低于 50、上架时间不足三个月，直接换码重建更省事。评论数超过 500、有稳定销量，就值得花时间去处理合并，尽量保住权重。中间地带的，看广告投入，如果已经投了不少且转化稳定，倾向于保留。
外部占用核验如果要全量做，成本极高，因为需要逐个在平台上搜索。抽样核验可以在可控成本下把风险摸清，但一定会有漏网。取舍点在于码的来源：GS1 官方码段可以低比例抽样，第三方采购码段必须高比例，甚至考虑全量核验一次。
| 码来源 | 建议抽样比例 | 适用理由 |
|---|---|---|
| GS1 官方申请 | 2% – 3% | 码段归属明确，外部占用概率极低 |
| 供应商或工厂提供 | 8% – 10% | 需防范供货方多头供货导致的撞码 |
| 品牌豁免后自编码 | 10% – 15% | 缺乏外部注册约束，需按期核验 |
| 第三方批量采购 | 20% – 30%，新批次建议全量 | 回收码、二手码比例高，是外部冲突的主要来源 |
工具能解决数据汇总和自动比对，但解决不了“运营随手复制模板”这个行为。我见过不少卖家买了工具，重复码依然不断，因为工具只在事后报警，行为没有改变。
所以最好的组合是：工具负责发现，流程负责阻断。工具把重复组数标出来，流程规定新 SKU 上架前必须通过校验。两者缺一，效果都会打折。如果只能选一个，我会先做流程，因为很多重复根本不需要工具就能避免，只需要改掉复制整列的习惯。
回到最开始那个问题：重复码排查从哪里开始？我的答案是，从你自己的一张表开始，而不是从平台的任何通知开始。这张表要能回答四个问题：这个码是什么来源、在哪些店铺和站点用过、关联了哪些 ASIN、关联的 ASIN 权重有多高。
整篇文章里，我认为最值得记住的三个判断是：第一，内部复制粘贴造成的重复远多于外部占用，把矛头对准采购往往找错了方向；第二，重复码的风险由关联 ASIN 的权重决定，而不是由数量决定；第三，重复码不可能清零，把它当成一个需要持续监控的运行指标，比追求一次性根治更现实。
下一步我会建议你按这个顺序做三件事。先花半天，把全部店铺的 SKU 明细导出来，UPC 列设成文本格式，做一次透视，看看重复组数和最高影响面的那几组在哪里。这一步不需要任何工具，今天就能做。
然后用两周时间做一次存量清洗，优先处理关联评论数最多的前 20 组，其余按批次推进。清洗期间不要停上架，但要临时加一道人工校验，避免边清边生。
最后把校验动作固化下来：小规模用一张固定结构的台账每周更新，规模上来之后接入数跨境这类多店铺数据工具，把 UPC 主键台账和日级重复监控固定成常规报表，并在上架流程里加一道准入卡点。工具负责发现，流程负责阻断，这两件事做齐了，重复码才会从“随时爆发的意外”变成“可控的日常指标”。
手上十几家店，UPC是从不同批次东拼西凑来的，后台也没有统一台账。真要一条条对着比，几千个SKU根本对不完，所以我想知道有没有一个当天就能动手、当天就能出结果的入口。
先别碰listing，先把UPC池拉出来。从三个来源导数据：各店后台的商品导出表（含UPC、SKU、ASIN、上架时间、状态）、UPC采购记录（批次、供应商、数量、前缀）、GS1或供应商给的授权归属文件。合并成一张主表，UPC统一成12位、去空格去横线、以文本格式存储。
第一刀用校验位过滤：UPC-A第12位是校验位，按mod 10算一遍，能一次性筛掉手输错位、位数不对、复制漏字符的脏码，实测通常能砍掉3%到8%。第二刀才做重复比对：先用COUNTIF对UPC列标出重复行，再按前缀前6到9位分组看，因为同一批买来的码前缀集中，撞码大概率发生在同批次内部。
当天要出的成果是一张高危清单：哪个批次、哪些UPC、被几家店在用。
我以前觉得UPC就是个条码，重复用顶多被平台警告一下。结果有一次一个店的listing被压了，后台提示目录冲突，我才开始怀疑是不是码出了问题。现在店多了，我拿不准这事到底多严重，也不知道该不该停下手上的活先查这个。
值得查，但优先级要分层，不要所有重复一视同仁。
第一类最危险：同一个UPC出现在两家以上店铺的在售listing上，平台侧看到的是同一商品主体被多个账号同时操盘，容易触发账号关联审查和目录冲突压制，必须当天处理，做法是保留一个主店铺的使用权，其他店立即下架换码，换码后不要原样重上，主图和文案也要有差异。
第二类是同一个UPC出现在同一家店的两个不同SKU上，属于变体或目录滥用，一般是警告和拆分风险，排在7天内修完即可。第三类是重复只发生在已下架、无效的历史记录里，基本无风险，但要在台账上标记，防止以后被复用。判断严重程度看两个维度：是否同时在售、是否跨店铺。
同时在售的口径建议按listing状态加近30天是否有出单来算，别只看后台显示的在售标记。
我导完表发现有六十多个UPC重复，但不敢直接改，怕改错反而把本来正常的listing搞坏。有些可能只是运营复制粘贴时填错了一位，有些是真的两个店撞上了。我需要一个能快速分流、不用凭感觉猜的判断办法。
用来源、用途、状态三列交叉验证，别只看有没有重复。第一步查来源：如果重复的两个SKU属于同一采购批次、同一前缀，多半是分配失误，把码从其中一个SKU上摘掉就行；如果前缀完全不同，比如一个来自自注册码、一个来自第三方转售码，那基本是两批码本身就撞了，属于真重复。
第二步查用途：同一个UPC对应的两个SKU是不是同一款产品？是同一款，就是跨店重复；不是同一款，就是错配或变体滥用。这里有个省时间的做法，拿主图做感知哈希或直接看图比对，比对着标题猜快得多，几千条也就几分钟。第三步查状态：在售还是下架、近30天有没有销量。
三步走完，把结果打上真跨店、错配、变体滥用、历史残留四个标签，只有前两个需要动listing，后两个改台账即可。另外提醒一句，第三方转售码即使不重复也有隐患，如果查不到明确的归属主体，建议优先替换成自注册码。
这次查完改完，我担心过两个月又乱了。运营换人、新店开张、采购又进一批码，靠人记肯定记不住。我想知道那些店群做得比较稳的团队，是怎么把这个流程固定下来的。
核心是把UPC从后台的一个填写字段变成有台账的资产，落地就三件事。第一，一码一档：建一张UPC主表，一行一个码，字段至少包括码、前缀、来源、采购批次、采购日期、分配店铺、绑定SKU、分配时间、状态、备注，任何新码入库前先在这张表里跑一次重复检查，重复的直接拦下不分配。
第二，入库即校验：把UPC校验位公式做成表格模板，粘贴新码时自动标红错误码，同时用条件格式对整表做重复高亮，避免事后再查。
第三，分配留痕加定期对账：每次把码分配给某个店某个SKU都要记录操作人和时间，每月拿后台商品导出表和主表对一次，重点查三类差异，后台有码但台账没记、台账记了但长时间没上架、同一个码出现在两行记录里。
如果有预算，用带UPC池管理和占用锁定能力的工具会比Excel省事，挑选的硬标准就两条：能不能做到一个码只能分配给一个店铺一个SKU，以及能不能按店铺维度反查历史占用记录。
读者评论
前导零这个坑太真实了。我们从平台后台导出的UPC列，Excel一打开就变成科学计数法，补零后还有全角空格，第一次去重报出来重复很少，后来用Python统一转文本再比对，重复组直接翻倍。建议别只靠Excel，至少用数据库或脚本做归一化，不然基线建了也是假的。
建码库基线方向对，但小团队执行难。我们试过维护主键表，结果运营上新时嫌麻烦，直接复制模板，表很快过期。后来改成上架前强制校验：UPC必须通过校验位、必须和店铺站点做唯一约束，不通过就不给提交。这比事后审计有效，但需要工具支持，不是靠自觉。
文章说外部占用靠内部去重查不出来，这点认同，但实际核验很难。第三方买的码，你没法提前知道有没有被注册过，只能上架测试或查GS1。我的疑问是，跨站点复用真的都合规吗？现在品牌备案和详情页合并规则变得快，同码跨站点也可能被拦。与其一刀切，不如按平台最新政策逐站点验证。