去年 8 月的一个凌晨，我手里一个做家居收纳的店群项目出了事：三个店铺、同一个站点，同一批第三方 UPC 码被重复用在了 7 条 listing 上。亚马逊没有一次性全部报错，而是先抑制了其中 2 条，隔了两天又在另一个店铺触发了 GTIN 校验失败，最后一条是品牌方通过 GS1 数据库比对后提交了侵权投诉。整件事从爆发到收尾花了 19 天，直接损失 8.7 万元销售额，还不算申诉的人工和后续广告重投。
这次事故之后我复盘了很久，发现一个很反直觉的结论：UPC 重复码问题的根源，几乎从来不是”编码算错了”，而是”权属没理清、台账没建、店铺之间没有隔离”。很多人把 UPC 当成一次性耗材，用完就扔，却不知道它在平台风控体系里其实是一张”身份证”，一个 GTIN 对应一个商品实体、一个 ASIN、一个权属主体。
这篇文章我按三个层次来讲：先给结论，再拆我踩过的坑和常见误区，最后给出一套能落地的重复码排查 SOP 和店群管理方法，包含台账字段设计、验码流程、工具选型和不同规模下的取舍逻辑。如果你正在运营多店铺矩阵，或者打算把单店扩成店群，这篇内容能帮你少走至少一次下架弯路。
我把这几年的经验浓缩成一句话：重复 UPC 排查，查的是”这个码归谁、给谁用、用过没有”，而不是”这串数字对不对”。绝大多数人卡在第一步，因为他们默认码是”通用资源”，就像电话号码一样，谁都能拨。但 UPC 不是电话号码，它更像车牌，牌子挂在谁名下，是有登记记录的。
一个 UPC-A 码（12 位）在真实世界里同时具备三重身份，很多卖家只看到第一层。
第一层是格式身份：12 位数字、校验位合法，扫码枪能扫出来。这一层谁都能满足，用校验位计算器一算就出来了。很多人就停在这里，觉得”码能用”。
第二层是权属身份：码的前缀来自 GS1 分配给某个企业的公司前缀（GCP），这个前缀在 GS1 体系里是可以被查询到归属公司的。如果你从第三方码商手里买的码，前缀属于别人公司，这就是隐患的源头。
第三层是平台身份：在亚马逊的体系里，一个 GTIN 在同一个站点只能对应一个 ASIN。一旦这个 GTIN 已经被别人创建过 ASIN，你再拿它上架，要么被合并，要么被抑制，要么触发审核。
三层身份里，真正会出事的永远是第二层和第三层，而大多数卖家的排查动作只停留在第一层。
单店铺偶尔复用一次 UPC，最坏结果是一条 listing 被抑制。但在店群场景下，风险会被放大成三条独立的传导链。
我见过最典型的场景是：运营 A 为了赶进度，把一个店铺用过的 UPC 直接复制给了运营 B 的新店。当时”没报错”，因为新店的 listing 还没被系统完整收录。三周后两个店的库存和评论开始互相干扰，排查起来花了整整两天才定位到是码的问题。
我给所有做店群的朋友第一条建议都是：给每个店铺分配独立的 UPC 池，池与池之间不交叉，码一旦归属某店就不再流转。这条规矩听起来很笨，成本也更高，但它能规避掉 90% 以上的重复码事故。
原因是：一旦允许跨店流转，你就必须维护一张极度精确的状态表，记录每个码在哪个店、哪个站点、哪个 SKU、什么时候释放的。人的记忆撑不住这种复杂度，Excel 手动维护也撑不住。而如果池子隔离，即便某个店出现码冲突，影响范围也被限制在单店内部，不会引爆账号关联。
我把经手过的、印象最深的三次 UPC 重复事故拆开讲，因为它们分别对应三种不同的错误类型，也对应三种不同量级的代价。
2021 年，我做一个厨房小工具类目。当时同一个产品出了两个颜色，为了省事，我用同一个 UPC 建了两条独立 listing，只是标题和图片不一样。当时的想法很朴素：反正是同一个产品，用同一个码天经地义。
结果第二周，两条 listing 被系统判定为重复商品，其中一条被抑制，另一条虽然正常，但评论被拆分显示。找客服之后得到的答复是：同一 GTIN 在同一站点只能对应一个 ASIN，如果要做颜色区分，应该用变体（Variation）关系，而不是复制独立 listing。
这次事故教给我的是：UPC 的唯一性约束是”站点级别的商品实体唯一”，不是”卖家级别的 SKU 唯一”。颜色、尺寸、包装数量的差异，本质上都是同一个商品实体的变体，应该走变体结构，而不是靠共用 UPC 来偷懒。
2022 年，我手上 11 个店铺。为了控制成本，我从一个第三方码商那里一次性买了 5000 个 UPC，价格是 0.06 元一个。这批码被统一发放给所有店铺使用，运营那边只做了一件事：用 Excel 记了一下哪些码已经用了。
问题出在”回收”环节。有一个店铺的 listing 被删除后，运营把这个 SKU 占用的 UPC 标记为”可复用”，然后分配给了另一个店铺。但这个 UPC 对应的 ASIN 在亚马逊系统里还存在历史记录，新店的 listing 一上架就触发了 GTIN 校验，随后被抑制。
更麻烦的是，两个店铺使用的是同一个前缀段，平台在做风控扫描时把这两个店铺关联到了一起，其中一个店铺被要求提供额外的商品信息证明。整个处理过程 11 天，直接销售损失 3.2 万元。
这次事故的核心教训是：码的”回收”不等于”可复用”。只要这个 GTIN 在平台历史上出现过，它就一直带着”已使用”标记。释放的是你内部的占用状态，释放不了平台侧的记录。
2023 年，我尝试把美国站跑通的 listing 平移到欧洲站，为了省事，直接用了美国站的 UPC。当时测试阶段没报错，上架也成功了。但一个月后 FBA 入库出现了问题：两个站点的库存记录在内部系统里串了，补货计划完全乱掉。
后来我理解了这个机制：虽然亚马逊不同站点的 GTIN 唯一性约束是独立的，但很多店铺的 ERP、库存系统、广告系统是靠 SKU 和 UPC 做映射的。当同一个 UPC 在两个站点对应两条不同 SKU 时，你内部的数据链路会先乱掉，平台的混乱只是时间问题。
复盘下来，三次事故有三个高度一致的特征，这三点构成了我后面所有管理动作的出发点。
下面这六个误区，几乎每一个做店群的人都听人说过，甚至当成经验在传递。我逐个拆开讲，附上我的判断依据。
UPC-A 的校验位算法很简单：前 11 位数字中，奇数位乘 3、偶数位乘 1，求和后取模 10 的补数。任何人用 Excel 三行公式就能生成合法的校验位。
但校验位只解决”这串数字是不是格式合法的 UPC”，完全解决不了”这个码归谁、有没有被用过”。我见过有人用脚本批量生成校验位合法的码去上架，短期内看起来能用，但这些码在 GS1 数据库里根本不存在，一旦平台启动 GTIN 校验就会被判为无效，严重的会被认定为提供虚假商品信息。
所以判断一个码能不能用，校验位是必要不充分条件，最多算入场券。
这个说法在五六年前还算勉强成立，现在完全不成立。平台至少有三个渠道可以核实 GTIN 的真实性：一是与 GS1 数据库的直接比对；二是品牌方的投诉与举证；三是同一 GTIN 在系统内的历史创建记录。
我经手的一次问询里，平台直接要求提供 GS1 证书或者 GS1 官方数据库的截图，证明这个前缀归属于我的公司。这个要求本身，就已经说明平台在做权属核验。
这是最危险的一个误区。不同店铺用同一个 GTIN，恰恰是平台最容易发现账号关联的场景之一，因为 GTIN 是商品维度的强标识，比 IP、设备指纹更难伪装。
我理解很多人会想：我用了不同的收款账号、不同的网络环境，应该查不出来。但商品数据是公开可见的，同一个 GTIN 出现在两个店铺的 listing 上，任何人（包括平台、竞对、品牌方）都能看到。这类关联属于”公开信息层面的关联”，风控系统识别成本极低。
品牌备案确实能申请 GTIN 豁免，上架时不再强制要求填 UPC。但备案解决的是”上架门槛”问题，不解决”历史数据”问题。
如果你在备案前用第三方转售码建了大量 ASIN，这些 ASIN 的 GTIN 记录依然存在，品牌方依然有可能通过 GS1 数据库发现这些码归属异常。备案不是免死金牌，它只是让你未来的新品不再依赖 UPC。
平台的校验不是实时全量的。我观察到的时间差通常在 3 天到 4 周之间，具体取决于类目热度、商品信息的完整度、是否处于风控扫描周期。
所以”上架成功”和”安全”之间有一大段空白。真正安全的判断标准是：这个 GTIN 的权属清晰、状态明确、在你的台账里唯一指向一个店铺的一个 SKU。只要满足这三条，报不报错都不影响它安全。
这是最让人心疼的一个误区。删掉 listing 重建，意味着评论归零、排名归零、广告历史归零。一条积累了 300 条评论的 listing，重建成本远高于换一个码。
正确的做法是先判断问题类型：如果是 GTIN 权属问题，可以尝试通过变体关系或换码方式处理；如果是重复商品判定，需要先解决 ASIN 冲突；只有在 listing 本身已经被平台标记为不可恢复的时候，才考虑重建。
我现在的做法是：任何一批新码入库、任何一个码分发给店铺之前，必须走完四步验证。这四步不是为了走流程，而是每一步失败对应的处置方式完全不同。
操作方式很直接：把 UPC 前缀拿出来，去 GS1 的官方数据库做归属查询。如果查询结果显示归属公司是我自己或我授权的实体，这个码的权属是干净的。
如果查询不到，或者显示归属某家陌生的贸易公司，就要打上”高风险”标签。这里要注意一点：查不到归属不等于一定违规，但等于你在遇到投诉时无法自证，这在申诉环节是致命的。
我一般把权属分成三档：自有前缀（可自证）、可追溯上游（需保留采购凭证）、无法追溯（建议冻结不用）。
站内查重的核心动作是把候选码与历史 listing 全量数据做比对。亚马逊卖家后台可以导出全量商品报告，里面包含 product-id（GTIN）字段，这是最可靠的一手数据源。
比对的范围至少要覆盖：本店铺全部站点、同一运营主体下的其他店铺、以及历史已删除的 listing（如果 ERP 里有记录）。很多人只比对了当前在售的 listing，漏掉了归档数据，这是第二次事故的直接原因。
这一步是店群特有的。你需要一张”码，店，站，SKU”的四维映射表，任何一个码在同一时间只能出现在一行上。
我用的规则是：码一旦分发到某个店铺，终身归属该店铺，不做跨店回收。店铺关停时，该店的码全部转为”冻结”状态，不进入可复用池。这个规则会让码的消耗速度加快，但换来的是风险可控。
我给每个码定义了四个状态，简单但够用：
关键是“冻结”和”回收”必须严格区分。只要一个码在平台侧创建过 ASIN，无论 listing 是否还在，它都应该进冻结，而不是回收。这是第二次事故用 3.2 万元换来的教训。
把”权属是否清晰”和”是否已在平台出现过”两个维度交叉，会得到四种情况，处置方式完全不同。
| 情况 | 权属清晰 + 未使用 | 权属清晰 + 已使用 | 权属不清 + 未使用 | 权属不清 + 已使用 |
|---|---|---|---|---|
| 典型场景 | GS1 自有前缀的新码 | 自有码建过 ASIN 后释放 | 转售码未启用 | 转售码已建 listing |
| 风险等级 | 低 | 中 | 中高 | 高 |
| 处置方式 | 直接使用，一码一 SKU | 冻结，不跨店复用 | 退回或冻结，优先换自有码 | 制定换码计划，同步准备权属说明材料 |
| 优先动作 | 录入台账 | 标记原店铺归属 | 停止分发 | 先稳定账号，再逐步替换 |
我个人的优先级判断是：第四象限（权属不清 + 已使用）必须先处理，因为它随时可能引爆；第三象限其次，因为它是潜在的定时炸弹；第二象限最容易被忽视，但它是店群内部关联的主要来源。
前面讲的都是方法论，这一节讲我实际怎么落地的。纯靠 Excel 维护 UPC 台账，在 5 个店铺以内还能撑住，超过 10 个店铺之后一定崩。原因不是 Excel 不行，而是数据不流动，listing 数据在后台，销售数据在报表里，UPC 台账在另一个文件里，三者对不上。
我最终定下来的字段不多，一共 12 个，但每一个都有明确用途，缺一个就会在某个环节卡住。
| 字段 | 用途 | 是否必填 |
|---|---|---|
| UPC 码 | 主键，12 位数字，去重依据 | 必填 |
| 前缀 | 用于权属查询与店铺分组 | 必填 |
| 来源类型 | 自有 / 转售 / 豁免，决定风险等级 | 必填 |
| 所属店铺 | 一码一店的绑定依据 | 必填 |
| 站点 | 区分不同 marketplace | 必填 |
| SKU | 与内部 ERP 对齐 | 占用时必填 |
| ASIN | 反向关联平台数据 | 上架后必填 |
| 状态 | 可用 / 占用 / 冻结 / 回收 | 必填 |
| 首次启用日期 | 判断是否已进入平台历史 | 必填 |
| 当前 listing 状态 | 在售 / 已删 / 被抑制 | 建议填写 |
| 权属凭证链接 | GS1 查询截图或采购合同存档位置 | 高风险码必填 |
| 备注 | 记录异常、投诉、换码历史 | 选填 |
台账建好之后，真正难的是让它”活着”，每天自动更新，而不是靠人手工填。我后来的做法是把多店铺的商品数据和 UPC 台账放在同一个数据看板里做关联，这里我用的是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）。
选择它的原因很实际：店群运营的痛点是数据分散在十几个店铺后台，而 UPC 台账需要和商品数据、销售数据放在一起看才能判断风险。如果台账是独立文件，你永远看不到”某个码被哪个店在用、这条 listing 卖得怎么样、值不值得为它换码”。把这些数据打通之后，判断就变得非常简单。
我在看板上主要看三件事：
这套东西听起来像技术活，实际上搭起来大概花了我一天半，主要时间花在字段对齐上，因为不同店铺后台导出的商品报告字段名和格式不完全一致。
我用一个 12 店的项目做对比，时间窗口是上线台账看板的前后各三个月。数据来自项目内部的运营记录，属于单项目样本，不是行业统计，但变化趋势我认为有参考价值。
最让我意外的一个变化是：运营团队对 UPC 的态度变了。之前大家把它当耗材，用完随手记一下；现在看到看板上标红的码会主动来问怎么处理。工具带来的不只是效率，还有风险意识的可见化。
这一节给可直接照做的操作流程。我按五个步骤写，每一步都说明输入、动作和输出，方便你直接套用。
这是整条流程里最容易被做错的一步。很多人只导出当前在售的 listing，导致已删除但 GTIN 仍被平台记录的商品完全没被覆盖。
正确做法是同时导出三份数据：当前在售商品报告、已归档/已删除商品记录（如果系统里还有）、以及内部 ERP 的 SKU 主数据。三份数据在导出后统一成一张宽表，字段至少包含店铺、站点、SKU、ASIN、GTIN、listing 状态、创建时间。
把三份数据合并之后，形成一张以 UPC 为主键的映射表。这张表要能回答三个问题：这个码在哪些店铺出现过、对应哪些 ASIN、对应哪些内部 SKU。
实际操作中你会发现大量”一对多”的情况，比如一个 UPC 对应两个 ASIN、一个 SKU 对应三个 UPC。每一个”一对多”都是一个潜在问题点，需要单独标注出来。
如果数据量在几千行以内，Excel 足够。我常用的两个公式：
=COUNTIF($E$2:$E$100000,E2)
这个公式用来统计每个 UPC 在全表中的出现次数，结果大于 1 就是重复。
=IF(AND(COUNTIFS($E:$E,E2,$B:$B,"<>"&B2)>0,B2<>""),"跨店冲突","")
这个公式用来判断某个 UPC 是否出现在不同店铺（B 列为店铺字段）中，这是店群场景下最关键的一类冲突。
如果数据量超过五万行，Excel 会明显变慢，我改用 Python 处理：
import pandas as pd
df = pd.read_excel("upc_master.xlsx")
全表重复检测
dup_all = df[df.duplicated(subset=["upc"], keep=False)]
跨店铺冲突检测
grouped = df.groupby("upc")["shop"].nunique().reset_index()
cross_shop = grouped[grouped["shop"] > 1]
跨站点冲突检测
station = df.groupby(["upc", "shop"])["marketplace"].nunique().reset_index()
cross_station = station[station["marketplace"] > 1]
输出冲突清单
dup_all.to_excel("dup_all.xlsx", index=False)
cross_shop.to_excel("cross_shop.xlsx", index=False)
cross_station.to_excel("cross_station.xlsx", index=False)这段脚本我用了两年多，跑一次全量数据大概十几秒，输出三份冲突清单。比起人工比对，效率差距是量级的。
脚本跑出来的是”内部冲突”，还需要和外部数据交叉验证。这一步要做两件事：
第二步经常能发现意外情况：有些 GTIN 对应的 ASIN 已经属于别的卖家了，而且评论量很高。这种情况说明你的码可能已经被别人先用了，需要立即评估是否换码。
排查出问题之后，处置顺序非常重要，不能一刀切。我的分级标准是：
处置动作上，换码不是简单地在后台改一个数字，因为改 GTIN 往往意味着要新建 ASIN。所以我的一般策略是：高价值 listing 优先争取保留 ASIN（通过变体关系或客服申诉），低价值 listing 直接换码重建。这个取舍在后面第八节会详细讲。
UPC 管理没有万能方案，5 个店和 50 个店的做法完全不同。我按四种典型规模给出可直接执行的建议。
这个阶段不需要复杂系统。核心动作只有一个：把库存报告里的 product-id 字段导出来，做一次全量去重，之后每次上新前查一次。
建议用 Excel 维护一张最简单的表，字段只要有 UPC、SKU、ASIN、状态四列就够。采购上，建议直接用 GS1 自有前缀，中国区小微企业会员的年费摊到几百上千个码位上，单码成本可以接受，换来的是权属清晰。
这个规模是问题高发区，因为已经开始需要协调，但还没到必须系统化的程度。我建议做三件事：给每个店铺分配独立前缀段、建立一码一店的硬规则、每两周做一次跨店查重。
前缀段分配很实用：假设你有 10 个店，可用码位有 10000 个，那就按 1000 个一段分配给每个店，物理上保证不同店铺的码不会混。这个做法简单粗暴，但极其有效。
这个阶段我建议开始考虑用数据看板来管理，就是第五节讲的那种方式。8 个店左右是分水岭，超过之后人工维护的单位成本开始明显上升。
到这个规模，UPC 管理必须制度化，靠人或靠 Excel 都不行。我的建议是：把 UPC 台账纳入选品和上新流程的强制卡点，没有分配 UPC 的 SKU 不能进入上新流程。
具体做法是把 UPC 分配做成一个审批动作，由专人负责，运营提交上新申请时同时申请 UPC，系统自动从前缀池里分配一个可用码，分配即锁定。这样做的代价是上新速度会慢一点，但换来的是零重复。
另外建议采购足够量的 GS1 自有码位，按 25 个店、每店 200 个 SKU 的规模估算，大概需要 5000 个以上码位，这个量级直接注册 GS1 会员比自己编造成本更低也更安全。
备案之后你有两个选择：申请 GTIN 豁免，或者继续用 UPC。我的建议是新品类走豁免，老品类继续用 UPC 直到自然迭代。
原因是：豁免虽然免去了 UPC，但部分类目和部分站点对豁免的支持并不一致，而且变体结构在某些情况下仍然依赖 GTIN。更关键的是，历史 ASIN 已经带着 GTIN 记录，豁免解决不了历史问题。
所以备案后的第一件事应该是：先排查历史 UPC 的权属和重复情况，把高风险的替换掉，再考虑新品走豁免。
这种情况处置顺序很明确，不要乱。
方法讲完了，但实际执行中最难的不是”怎么做”，而是”什么时候不做”。我总结了四个必须提前想清楚的取舍点。
这个取舍表面是成本问题，实质是风险归属问题。
转售码适合的场景非常有限：短期测试、非核心类目、SKU 数量极少、随时可以下架的试水商品。
自有 GS1 前缀适合的场景：核心类目、需要长期经营的 listing、有品牌备案计划、店群规模超过 3 个店。
我的建议很直接：只要是打算长期做的品，一律用自有码。转售码省下的几千块钱，抵不上一次申诉的人力成本。但对于纯测款的一次性商品，用便宜的码快速试错也不是不能接受，前提是你清楚它随时可能被下架。
这是实际操作中问得最多的一个问题。我的判断标准主要看三个数：评论量、月销售额、广告依赖度。
| listing 情况 | 建议动作 | 理由 |
|---|---|---|
| 评论 < 50 条，月销售额 < 1 万元 | 直接换码重建 | 重建成本低于申诉时间成本，评论损失可承受 |
| 评论 50，200 条 | 先申诉，备好换码方案 | 申诉成功率不确定，需要同步准备退路 |
| 评论 > 200 条，或月销售额 > 5 万元 | 优先申诉，必要时通过变体关系承接 | 评论和排名资产价值高，重建损失远大于申诉投入 |
| 广告依赖度 > 40% | 倾向申诉 | 重建后重新起量的广告成本极高 |
这里有个容易被忽略的点：换码重建的隐性成本是关键词排名。一条跑到首页的 listing，重建后可能需要 4 到 8 周才能恢复自然排名。所以在判断时，要把这段时间的机会成本算进去。
GTIN 豁免的优势是省事、省钱、免去权属烦恼。劣势是它把商品识别权完全交给了平台，一旦出现商品合并、变体错乱，你少了一个可自证的锚点。
我的实践经验是：标品、同质化严重的类目，走豁免问题不大；非标品、需要精细化区分的类目，保留 UPC 反而更安全，因为 GTIN 是区分你和别人商品的一道边界。
这个取舍我在第五节已经用数据回答了一部分。补充一个判断维度：如果你的团队每个人都能熟练用 Excel 做数据透视表，5 个店以内自建完全够用；但如果团队里有新人、有人员流动，工具化的价值会立刻显现，因为工具不会因为交接而丢失规则。
我之所以后来选择用数据看板来做，很大程度上不是为了效率，而是为了”规则固化”。人走了，规则留在系统里，这才是最值钱的部分。
写到这里，我想把整篇文章的核心观点再收一次。
UPC 重复码问题的本质，是权属没理清、状态没管住、店铺没隔离。它不是技术问题，是管理问题。很多人愿意花几千块买一批便宜的码，却不愿意花一天时间建一张台账，这个决策本身就藏着最大的风险。
第二个观点是：UPC 管理的关键动作是”发现时机前移”。平台的校验是在事故发生之后才报错的，你唯一能争取的时间窗口，就是在内部把问题找出来。台账和看板的价值，就在于把发现时机从”平台通知”提前到”例行自查”。
第三个观点是：店群场景下，码的隔离比码的数量更重要。一店一码池、码不跨店这两条规则看起来很笨，但它把风险限制在了单店内部，避免了账号关联这个最致命的问题。
如果你现在就要动手，我建议按这个顺序来：
最后补一句我自己的体感：在跨境这门生意里，合规成本永远是前置付的。你早付一天，代价就小一天；晚付一天，它就会以事故的形式，连本带利地找上门。UPC 只是其中一个很小的切口，但它足够说明这个规律。
我手上管着七八个店铺，上架的时候是几个运营各自从表格里捞码用，结果最近被平台提示重复。我自己也慌，不知道到底是同一店铺内重复，还是跨店铺撞码了，更不知道从哪下手查。总不能一个个listing点开来核对吧。
先把所有店铺的商品明细导出成一张总表，字段至少留UPC、SKU、店铺、站点、ASIN、上架时间，然后在UPC列右边加一列公式＝COUNTIF(A:A,A2)，返回大于1的就是重复项，按这个结果分组着色。
第二步再做真假校验：用GTIN-12的校验位算法（前11位按3、1交替加权求和，取模10补足）算一遍第12位，很多所谓的重复其实是运营手抄时错了一位形成的假码，校验不过的直接归到录入错误，不要混进重复清单。第三步按范围分两轮查，先查同一站点内重复（这是平台判得最重的），再查跨店铺重复。
如果店铺数超过十个、SKU上千，不要用表格硬扛，直接在批量上传模板里跑一遍全量更新，平台回执里会明确写出UPC已被占用的错误行，这份回执本身就是最权威的重复清单。
我一直以为只要商品图片和文案不一样就没事，UPC反正是自己买的，哪家店用不是用。直到有人跟我说同一UPC出现在两个店铺可能触发关联审核，我才开始担心，毕竟店群最怕的就是这个。但具体到哪个平台严、严到什么程度，我确实说不清。
要分平台看，不能一概而论。亚马逊的机制是UPC与ASIN强绑定，同一个UPC在同一个站点只能对应一个ASIN，你在第二个店铺用同一个UPC上传，系统要么直接报错，要么把两个店铺的listing强行合并到同一个ASIN上，而两个店铺共用同一个ASIN是典型的关联信号，风险等级不低。
沃尔玛、eBay对GTIN的校验相对宽松，更多是查GTIN是否有效、是否与品牌备案一致，跨店铺撞码不一定马上触发处罚，但一旦被投诉假货或滥用变体，这条重复记录会成为佐证。
我的操作口径是：同一站点内绝对一码一店，跨站点（比如美国站和欧洲站）可以复用同一个UPC，但前提是品牌授权和GS1注册信息都覆盖该站点。判断依据很简单，去GS1后台看这个GTIN绑定的公司前缀属于谁，如果前缀不是你们公司，那这个码在任何店铺用都是隐患。
我们一开始就是买一批码丢在共享表格里，谁上架谁去拿，人少的时候没出过问题，店一多就开始撞。每次出事都是上架之后才发现，改起来要下架重建listing，损失很大。我想找一套能落地的分号规则，而不是每次都事后救火。
核心做法是按店铺切分号段，而不是按人分。GS1给的是公司级前缀，前缀部分是固定的，真正能自己编排的是后面几位，所以可以把可编排位切成区块，比如店铺A固定用0001到0500，店铺B用0501到1000，一个店铺一个区块，永不交叉。
配合一张UPC台账，字段至少包含UPC、SKU、店铺、站点、品名、领用日期、上架日期、ASIN、状态、领用人，规则是先在台账登记再上架，不允许从GS1后台批量导出码之后直接分发。
第三个动作是定期审计，每月跑一次全量比对，把已下架商品的UPC标为可回收状态，但不要立刻重新分配，至少冻结一个季度，避免平台侧历史记录还没清干净就撞车。这样做的判断依据是：重复码的根因从来不是码不够用，而是没有归属约束，只要每个码在台账里只能出现一次、且只能属于一个店铺，重复率可以压到接近零。
我们现在用在线表格加条件格式查重，人少的时候还挺好用，但最近经常出现两个人同时编辑、版本冲突、有人把历史行删了的情况。我在纠结是继续优化表格，还是干脆上一个管理工具，但又不确定这个量级值不值得折腾。
给一个可操作的分界线：店铺数在十个以内、年SKU增量在两千以内、只有一到两个人负责编码，用在线表格完全够，前提是必须做三件事，第一，UPC列设数据验证加唯一性提醒，第二，把表格拆成录入区和查询区，录入区只允许追加不允许修改历史行，第三，每周导出一次快照留档，防止误删。
超过这条线就该换，标准是当出现多人并行录入、需要审批流、需要按店铺和站点做权限隔离这三种需求中的任意两种时，表格的维护成本会超过工具成本。
换成系统时，不要直接买一个通用工具硬套，先把UPC领用做成一条任务流：申请、审批、分配、上架、回填ASIN，任务的状态就是台账的状态，某项目管理工具或某项目管理平台都能承载这个流程，关键是一定要有唯一性约束，数据库层面的唯一索引才是最终防线，靠人眼在表格里查重迟早会漏，这一点我踩过不止一次。
读者评论
第三方码那个 22% 撞码率虽然作者自己标注是经验推演，但我这边体感差不多。真正难的是买之前没法验：码商给的前缀在 GS1 库里查得到，可查到归属公司不等于你就有权用，卖家到手后基本没有提前筛查的手段。现在我只走自有前缀，贵就贵点，至少出事时能自己举证。
『回收不等于可复用』这点值得单独拎出来。补充一个我们遇到的：删掉 listing 后用同一个码重建，有时确实能上架，但评论和 BSR 会挂到历史 ASIN 上，等于白白给之前那条记录做嫁衣。所以后来我连自己店铺内部都不复用码，宁可多买。
一店一码池方向没错，但小团队的执行成本被低估了。难的从来不是分池，是分完之后谁登记、谁维护释放状态。我们用共享表格做过一轮，三个月就乱，最后还是靠工具把领用环节卡住才管住。想请教作者台账字段具体怎么落的，特别是释放状态那一栏怎么定义。