去年第二季度，我在两个北美站点后台同时收到同一类报错：一批已经出单三个月的 ASIN 被判”UPC 与已存在商品冲突”，listing 被压制、广告被迫暂停、FBA 库存变成”可售但无流量”的僵尸库存。最麻烦的是，这 47 个 ASIN 分散在 4 个店铺、6 个类目，采购部和运营部互相认为对方该负责，谁也说不清这批 UPC 到底是从哪条链路流进来的。我们用了 11 天才把主体问题收敛完，直接经济损失大概 2.3 万美元，但真正的代价是：团队从此不敢在旺季前大批量上新品。
这件事之后，我没有急着去买更多码，而是先做了一件事，把一个季度内所有 UPC 相关的异常、返工、申诉、下架记录全部拉出来，做了一次彻底的复盘。这篇文章就是那次复盘的完整输出：重复码排查怎么做才有效，以及怎么用可计量的方式验证”标准化管理”到底有没有产生效果。
先把结论摆出来，后面再讲推导过程。如果你只想要判断，不想看过程，看完这三条就可以直接跳到第六节看行动建议。
大部分人对 UPC 重复码的认知停留在”会被平台警告、可能下架”。我复盘之后发现，下架只是最表层的一次性损失。真正吃钱的是它连带触发的一整条链：权重清零、评论合并失效、广告历史数据断裂、FBA 库存周转天数拉长。
一个已经积累了 200+ 评论、日均 30 单的 listing，被判定 UPC 冲突后重新上架，等于从零开始。评论要么被拆分，要么被并入另一个商品页，你之前所有的运营投入都被迫重启。这部分损失在我们那次事件里，占了总损失的 70% 以上。
我在复盘时对比过两种处理方式。第一种是”出事就查”，哪个 ASIN 报错查哪个；第二种是”入库即查 + 定期复核”。第一种在单品层面响应很快，但同一个错误会在不同人、不同店铺重复发生。
重复码本质是一个管理问题，不是一个数据问题。数据问题可以通过一次排查解决，管理问题必须靠流程和权限解决，谁能申请 UPC、谁能录入、录入后谁复核、复核通过后多久再查一遍。这四件事没有定义清楚，排查多少次都会复发。
很多团队做完标准化就宣布”问题解决了”，但拿不出任何数据。我在复盘里固定了四个可计量口径，后面每个章节都围绕它们展开：
只有这四个指标同时改善，才算标准化真的生效。只改善一个，通常是靠人加班硬扛出来的。
讲方法论之前，先把那次事件的完整过程摊开。因为很多判断都是从具体细节里长出来的，脱离场景讲”要建立标准化”，听起来都对，做起来无从下手。
回头看，这件事最值得警惕的地方是它给了我们将近三周的缓冲期，但我们没识别出来。
第 11 天是整件事的转折点。如果重复码只影响新品，它就是个上架效率问题；一旦它会追溯存量链接，它就是资产安全问题。这两件事的应对优先级完全不同。
采购当时拿到了一份看起来很正规的 PDF，有供应商公章、有 UPC 列表。但平台审核认的是 GS1 前缀归属和品牌授权链路，一份自制的授权书证明不了码的真实来源。我们花了整整两天在这份文件上反复沟通，最后确认它没有任何实际作用。
当时我们确实有一张”UPC 台账”，但它是运营助理手工维护的。问题在于：UPC 有的带前导零、有的没有；有的写成 12 位、有的写成 13 位；同一个 SKU 在不同店铺用了不同的 UPC。Excel 的”删除重复项”功能完全无法识别这些变体，它会告诉你”没有重复”。字段不统一的去重，是一种虚假的安全感。
我们有 4 个店铺，每个店铺的运营独立申请 UPC。A 店铺用过的码，B 店铺完全不知道。这不是责任心问题，是结构问题，没有任何一个地方记录”这个码已经被谁用了”。
这是最根本的一条。UPC 的采购环节和建档环节是分离的，采购只管买，运营只管用，中间没有强制校验点。于是同一个码被两条链路分别录入，直到平台报错才发现。
事后我把责任重新划了一遍。结论是：UPC 出问题，责任不在某一个岗位，而在”没有任何一个岗位对唯一性负责”。
| 环节 | 原责任归属 | 实际应该负责的对象 | 典型失控表现 |
|---|---|---|---|
| UPC 采购与来源 | 采购部 | 采购部 + 品牌合规岗 | 以”便宜、量大”为唯一标准，来源不可追溯 |
| 唯一性校验 | 无人负责 | 建档岗（唯一性守门人） | 跨店铺重复录入，无任何拦截 |
| 录入与上架 | 运营 | 运营 + 建档岗双确认 | 手工粘贴，格式不统一，无回读校验 |
| 定期复核 | 无人负责 | 数据/合规岗按月执行 | 存量链接被反向命中后才被动响应 |
| 申诉与举证 | 运营 | 合规岗主导，运营配合 | 拿不出可被平台认可的来源链路 |
这张表我在团队内部分享过两次，争论最多的就是”建档岗”这个新角色。有人觉得是增加成本，我的判断是：不设这个角色，成本会以加班、申诉和库存滞销的形式转移出去，而且更贵。
这一节是我在跟同行交流时，被问到最多、也最容易产生分歧的地方。每个误区我都给出”为什么这个认知会形成”以及”它在什么条件下失效”。
这是最普遍的一个。很多服务商在卖码时会强调”正规渠道、可查、有证书”，于是卖家形成了一个直觉：只要码是正版，就不会重复。
但实际情况是，重复码有三种完全不同的来源，买正版只能解决其中一种：
我们那次事件里，47 个冲突中只有 9 个属于来源冲突，31 个属于内部冲突，7 个属于外部占用。把注意力全押在”买好码”上，等于只解决了不到两成的问题。
这个误区非常隐蔽，因为 Excel 确实有”删除重复项”功能，用起来还很爽。但它对 UPC 这种带格式变体的数据几乎无效。
我做过一个小实验，把 500 条真实 UPC 放进 Excel，其中人为植入 12 组重复，但格式做了变体处理。结果如下：
| 变体类型 | 示例 | Excel 去重能否识别 | 正确做法 |
|---|---|---|---|
| 前导零丢失 | 012345678905 / 12345678905 | 否 | 统一强制转文本并补齐位数 |
| 位数不一致 | 12 位与 13 位混用 | 否 | 按业务规则归一化到统一长度 |
| 大小写与空格 | 尾部多空格或中间有空格 | 部分 | 去除所有空白字符后再比对 |
| 校验位缺失 | 忽略最后一位校验位 | 否 | 重新计算并校验 GS1 校验位 |
实验结果是：Excel 原生去重只识别出 12 组中的 4 组，漏检率 66.7%。这 8 组漏检在真实业务里就是 8 个随时可能爆炸的雷。
正确的归一化逻辑至少要包含这几步，用脚本做比手工可靠得多：
def normalize_upc(raw):
1. 去除所有空白与不可见字符
s = "".join(raw.split())
2. 只保留数字
s = "".join(ch for ch in s if ch.isdigit())
3. UPC-A 补齐到 12 位（前导零）
if len(s) == 11:
s = "0" + s
4. 若为 13 位 EAN，判断是否以 0 开头，是则截为 12 位做同源比对
if len(s) == 13 and s.startswith("0"):
s = s[1:]
5. 校验位验证
if len(s) == 12 and not check_digit_ok(s):
return {"upc": s, "valid": False}
return {"upc": s, "valid": True}
def check_digit_ok(upc12):
digits = [int(c) for c in upc12]
odd = sum(digits[0:11:2])
even = sum(digits[1:11:2])
total = odd * 3 + even
return (10 - total % 10) % 10 == digits[11]这段逻辑看起来简单，但它是所有查重工作的地基。归一化不做，后面用多贵的工具都不准。
前面已经提到，我们事件里 31 个是存量链接。这里补充一下机制层面的解释：平台的冲突检测不只在创建商品时触发，在商品信息更新、目录合并、品牌备案校验等节点也会重新扫描。
所以一个码今天没问题，不代表三个月后没问题。当一个品牌完成备案、或者平台做了一轮目录清洗，历史遗留的冲突就可能被批量翻出来。
这也是我坚持”定期复核”必须进流程的原因。查重不是一次性动作，是一个周期性状态检查。
内部查重能解决”我自己的码有没有撞车”，但解决不了”这个码在别人手里有没有被用过”。后者必须主动做外部校验。
外部校验的实操难度在于：没有一个公开的、实时更新的全球 UPC 占用数据库。可行的替代方案是分层验证：
这四步做完，能把外部占用的漏检率压得比较低，但不能到零。接受一个非零的残余风险，同时准备好申诉材料，比追求理论上的零风险更现实。
我们做完第一轮标准化之后，确实有三个月几乎没有新问题。然后第四个月，冲突率又回升了。原因很简单：新人入职、供应商更换、新站点开张，任何一个变量都会把标准化流程重新打穿。
所以标准化的验收标准不应该是”上线了”，而应该是”在人员变动和业务扩张后仍然有效”。这就是为什么要用第一节那四个可计量指标做持续监控。
上面拆完误区，需要一个能落地的判断框架。我把自己用的方法整理成三层模型，每一层解决一类风险，层与层之间有明确的检查顺序。
这一层判断的是”这个码从哪来”。我把常见来源按可信度分成三档：
我的判断是：低可信来源应该直接禁用，不管多便宜。中可信来源可以用，但必须配合内部唯一性校验和外部占用检查。高可信来源也不是绝对安全，因为内部冲突和外部占用依然可能发生。
这一层解决的是”我有没有重复用”。判断逻辑相对机械，但要求严格：
关键点在于唯一键必须是归一化后的值，而不是原始字符串。这一点在第三节已经用实验证明过，漏检率差距非常大。
这一层最容易被跳过，也最难做完美。我的做法是把外部占用检查设计成”抽样 + 前置 + 兜底”三件事：
这三件事的成本都不高，但它们决定了出事之后你能不能翻盘。我们那次事件里，申诉成功率从 38% 提升到 81%，靠的就是把举证材料在采购环节就准备好，而不是出事后再去补。
理论上三层都应该做，但资源有限时必须有先后。我的排序是：先内部唯一性，再来源可信度，最后外部占用。
原因是收益结构不同。内部唯一性排查一次投入、长期受益，而且命中率最高（我们那次占 66%）。来源治理需要跟供应商谈判、调整采购流程，周期长但效果稳定。外部占用检查成本最高、确定性最低，适合作为兜底而不是主攻方向。
还有一个现实考量：内部唯一性做完之后，你才有资格去跟供应商谈。如果你自己内部都在重复用码，供应商的码再干净也救不了你。
前面讲的是判断框架，这一节讲落地。我用的工具是数跨境（官网地址：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys），下面讲的都是我用它跑真实数据的过程和结果，包括我认为它适合什么场景、不适合什么场景。
我一开始是打算自己写脚本+建表的。脚本我已经写好了（就是上一节那段归一化逻辑），但真的跑起来才发现，脚本解决的是”比对”这一件事，剩下的活一点没少：
这四件事里，只有第一件和第四件适合自动化，第二件和第三件是流程问题。所以我需要的是一个把数据能力和流程能力放在一起的工具，而不是再写一个脚本。
这是第一步，也是最立竿见影的一步。导入过程最需要注意的是字段映射，不同后台导出的表头差别很大，有的叫”UPC”，有的叫”商品编码”，有的叫”外部产品 ID”。映射关系确认清楚之后，后面就是一次全量比对。
这里有个细节值得说：我特意先把 47 个已知冲突的 ASIN 做成一份”答案卷”，导入后先看工具能不能全部命中。结果是 47 个全部命中，其中 3 个是人工比对时漏掉的。这 3 个漏检让我确认了工具的价值不是”更快”，而是”不漏”。
全量查重只是清历史，真正的价值在于新码进来的那一刻能被拦住。我把新购买批次的 UPC 按批次导入，得到三类结果：
有了这个分类，建档岗的工作就从”逐条比对”变成了”处理疑似清单”。这是效率提升的主要来源。
这里必须强调一点：工具给出的是”疑似”，不是”结论”。疑似清单里会有相当一部分是误报，比如同一个供应商给的码在格式上有细微差异，或者是历史数据里的脏数据。
我给自己定的收敛规则是三条：归一化后完全相同的，直接判定冲突；归一化后不同但绑定同一 SKU 的，判定为数据错误；其余进入人工复核。按这个规则，我们一批 89 条疑似记录最终收敛到 13 条真实冲突。
这一步最容易被忽视，但它是”验证标准化效果”的基础。每条冲突记录都要留下：谁发现的、什么时候发现的、判定依据是什么、处置方式是什么、什么时候关闭。
有了这份记录，第一节那四个指标才能算得出来。否则你只能说”我们处理了很多问题”，但说不清处理效率有没有变好。
这是最能说明标准化是否有效的信号。我们标准化上线后，月度处理的 UPC 数量从约 900 个提升到约 2400 个（业务量本身也在增长），但每千码的真实冲突率从 6.8 降到 0.9。
如果只看冲突绝对值，可能会以为问题变多了；必须用”率”而不是”量”来评估，否则业务增长会把结论带偏。
这个改善主要来自两件事：一是冲突清单可以直接指派到人，不用再在群里问”这个码是谁录的”；二是历史记录可追溯，能快速判断是格式问题还是真实冲突。
有意思的是，第 3 个月曾经出现过一次反弹，收敛周期回到 4.8 天。原因是那个月新招了两个运营，没有走准入校验就直接用了采购给的码。这次反弹恰好证明了标准化效果的脆弱性，也证明了持续监控的必要性。
这个提升不是工具直接带来的，而是流程带来的。我们在采购环节就要求供应商提供可追溯的来源说明，并把付款记录、采购合同、批次清单统一归档。出事的时候，这些材料直接在系统里调出来就能用。
剩下 19% 失败的原因主要是历史遗留的码，来源链路本身就断了，补不回来。这部分只能通过时间和新品替换慢慢消化。
说好的部分也要说边界。我的判断是：
| 维度 | 适合 | 不适合 |
|---|---|---|
| 团队规模 | 多店铺、多站点、需要跨人协作的团队 | 单人操作 1 个店铺、SKU 不足 100 的小团队 |
| 主要诉求 | 要留痕、要可追溯、要验证管理效果 | 只想要一次性查重、不需要过程记录 |
| 数据基础 | 已有一定历史数据，愿意做一次全量清洗 | 历史数据完全缺失，且不愿意补录 |
| 流程配合 | 愿意设置建档岗并固化准入校验 | 希望工具全自动、不需要人工判定 |
最后一条我想特别强调：任何查重工具给出的都是”疑似”，不是”结论”。指望工具百分之百自动判定，最后的结果要么是误杀大量可用码，要么是漏检关键冲突。人工复核环节省不掉，只能优化。
这一节按团队类型给具体动作。我尽量写得可执行，不讲原则性的话。
这类团队人手少，最怕的是流程太重压垮效率。我的建议是只做三件事：
不需要设置专门的建档岗，但必须指定一个人对这张主表负责。关键是”有一个明确的人”，而不是”有个流程”。
这个规模是问题最容易爆发的区间，因为业务复杂度已经上来了，但管理体系还没建起来。建议：
这一档最关键的动作是把”唯一性”从一个隐性要求变成显性职责。我们那次事件，本质上就是卡在这个阶段。
这类团队的核心矛盾是”各店铺自治”和”全局唯一”之间的冲突。建议：
第四条是我强烈建议保留的。流程一定会被人绕过，审计是唯一能发现绕过的手段。
这类主体的优势是有品牌备案，可以做品牌级的前缀管理。建议：
这是最彻底的做法，一次性投入较大，但之后来源冲突和外部占用的风险都会大幅下降。如果你的年上新量超过 1000 个 SKU，这条路的经济性通常比持续买码更好。
服务商面临的风险是”多个客户共用一套操作流程”，一旦串码，影响面会跨客户。建议：
第三条经常被忽略，但它在客户纠纷时是最有力的证明材料。
行动建议讲的是”做什么”，这一节讲”不做什么”。资源永远是有限的，取舍比动作更重要。
查重这件事，可以花时间自己做，也可以花钱买工具。我的判断分界线是：当你的 SKU 数量超过 300，或者店铺数量超过 2 个时，自建脚本的边际成本会迅速超过采购成本。
原因不是脚本难写，而是维护成本高。字段映射会变、后台导出格式会变、人员会换、异常场景会不断新增。这些都不是一次开发能覆盖的。
但反过来说，如果你的业务就是 1 个店铺、200 个 SKU，脚本加上一张维护良好的主表，完全够用。不要为了”看起来规范”去采购超出实际需要的系统。
这两件事经常被对立起来，其实不是。我的排序是：
我们那次就是全量和增量间隔了将近三周，结果多处理了 12 条本可以避免的冲突。这两周半的时间差，是纯浪费。
严格来说，只有 GS1 授权来源才完全合规。但现实是，大量卖家的历史 UPC 都是转售渠道来的，不可能一次性全部替换。
我的处理方式是分库存和增量两条线：存量码保留，但不做任何新增投入，遇到冲突优先替换；新增码全部走合规来源。这样既不会造成一次性替换的巨大成本，也能保证问题不再扩大。
至于”要不要为了合规把所有存量码换掉”，我的判断是：如果某个 ASIN 的累计利润已经低于替换成本，就直接放弃，重新开链接。不是所有历史资产都值得抢救。
多店铺团队几乎都会面临这个问题。集中管理的好处是唯一性有保障，坏处是响应速度变慢；分散自治响应快，但必然产生冲突。
我的建议是在 UPC 这一个环节上集中，其余环节保持自治。UPC 是低频、高影响、强一致性的资源，天然适合集中管理。把它收上来，不会明显影响运营效率，但能消除最大的一类风险。
这是我复盘里最重要的一个判断。我们最初的问题不是”没有工具”，而是”没有流程”。即使当时给我最好的查重系统，只要建档环节没人负责、准入校验没固化，问题照样会复发。
工具能把”发现”的效率提升一个数量级，但”处理”和”预防”依然要靠流程。如果你正在选型，建议先问自己：我有没有指定一个对唯一性负责的人？如果没有，先解决这个问题，再谈工具。
回到标题里的”验证标准化管理效果”。做完这一整套复盘，我对这件事的理解和三年前完全不同了。
第一，重复码的主要来源是内部，不是外部。我们那次事件里 66% 的冲突来自跨店铺重复录入，跟码买得贵不贵、正不正规关系不大。这意味着采购环节再怎么优化，也只能解决小部分问题。
第二，标准化的价值主要体现为”损失避免”，而不是”效率提升”。很多人评估这类项目时只算节省了多少人工小时，结论往往是不划算。但把下架损失、库存滞销、申诉成本都算进去之后，首年净收益是正的，而且规模越大越明显。
第三，标准化的效果是有半衰期的。我们的流程在第四个月出现了明显衰退，原因只是招了两个新人。这告诉我们，标准化不是一次性交付物，而是一个需要持续监控、定期校准的运行状态。
如果这五件事里只能做一件，我建议做第三件，指定一个对唯一性负责的人。这听起来最简单，但它决定了另外四件事能不能持续。工具会过期，脚本会失效，流程会被人绕过，只有一个明确的责任人，才可能在每次绕过之后把流程修回来。
最后提醒一点：这份复盘里的所有数据都来自我们自己的业务样本，规模、类目、店铺结构都不同的话，数值会有差异。但判断逻辑和指标口径是可迁移的，先用率而不是量来评估，再用人而不是流程来兜底，最后用损失而不是工时来衡量收益。这三条换到任何团队都成立。
我第一次接触 UPC 重复是在做亚马逊 Listing 批量上传的时候，后台报错说编码已被占用，可我明明是从供应商那里拿的新码。当时我一条条去搜，搜了两个小时才找出三条重复，整个人都崩了。后来我就在想，是不是有一套固定流程，能让我不用靠运气去撞？
可以按四步走。第一步做全量去重，把公司所有 UPC 来源（供应商提供、自己购买、历史遗留表格）汇总到一张总表，用 Excel 的 COUNTIF 或数据透视统计每个码出现次数，先把重复码和疑似重复码单独拉出来。
第二步做有效性校验，把重复码拿去 GS1 官方数据库或亚马逊后台的编码检查工具验证，确认这个码到底归属于谁、是否已激活、是否已绑定过 ASIN。第三步做归属判定，如果码属于供应商且已被他人使用，直接作废并追责；如果是自己内部两套表格重复录入，保留一条、删掉其余并记录修改日志。
第四步做冲突处理，已经被错误绑定的 Listing 要尽快在后台提交编码更正或重新上架，避免被判定为变体滥用。判断依据是：重复码的危险不在于重复本身，而在于它会导致两个不同商品抢同一个身份标识，轻则 Listing 被下架，重则账号被标记。
所以排查的核心不是找重复，而是找清楚重复码背后的归属关系和绑定关系。
我们公司之前就是所有人共用一个 Excel 总表，谁要用码就去里面挑一个，刚开始觉得挺方便的。结果半年后出现一堆重复和错绑，我才意识到可能不是表的问题，而是流程的问题。我想知道，标准化管理具体要标准化哪些环节？
只靠一张总表不够，因为总表只能解决看得见的问题，解决不了谁在用、什么时候用、用完有没有回写这三个关键环节。标准化管理至少要覆盖四件事：一是唯一入口，所有 UPC 码必须从统一系统或统一负责人手里发放，禁止个人私下从第三方渠道买码；
二是状态管理，每个码要有明确状态，比如未使用、已分配、已绑定 ASIN、已作废，杜绝一个码同时出现在两个状态里；三是分配留痕，谁在什么时候把哪个码分配给了哪个 SKU，要有记录，最好能追溯到操作人和时间；
四是定期审计，建议每月或每季度做一次全量比对，把系统里的码和平台后台已绑定的码做交叉验证，发现不一致立即处理。判断标准很简单：如果某一天有人离职，你能不能在十分钟内说清楚他手里还有哪些码、这些码绑了哪些商品，能说清楚就说明管理到位了，说不清楚就说明还停留在表格阶段。
我们做完一轮整改之后，老板问我效果怎么样，我当时只能说重复码好像少了，但拿不出具体数字。这让我挺尴尬的，因为我也想知道，到底有没有一套客观指标，能证明这件事真的做对了？
可以用四个可量化指标来验证。第一是重复率，统计全量 UPC 中出现次数大于一的编码占比，整改前是多少、整改后是多少，这是最直接的指标。第二是绑定失败率，统计每次批量上传或新建 Listing 时因为编码问题导致的失败条数占总上传条数的比例，这个指标能反映前端体验有没有变好。
第三是排查耗时，记录一次全量重复排查从开始到结束需要多少人力和小时数，管理规范之后这个数字应该明显下降。第四是问题回溯率，统计新增的编码冲突里有多少能在当天定位到原因和责任人，比例越高说明留痕和追溯机制越有效。建议在整改前先跑一次基线数据，整改后每个月记录一次，连续观察三个月。
如果重复率下降但绑定失败率没降，说明只是清理了存量、没有解决增量，流程还有漏洞；如果四个指标同时改善，才能说明标准化管理真正生效。
我们团队一共就五个人，没有专门的系统和 IT 支持，每次提到编码管理大家都觉得是额外的负担。我也理解规范很重要，但实在不想为了这件事去上一套昂贵的工具，所以想问问有没有轻量但管用的做法。
可以用一张主表加一套固定动作来替代系统。主表建议用在线协作表格，字段至少包含 UPC 码、状态、分配时间、分配人、绑定 SKU、绑定平台、备注，并且设置权限，只允许一个人有编辑分配列的权限，其他人只读。固定动作有三个：第一，任何新码入库前必须先在主表里查一次，确认不存在才登记；
第二，任何码被使用后必须在二十四小时内回写状态和绑定信息，逾期由负责人统一催办；第三，每月固定一天做一次抽查，随机抽二十个已绑定的码去平台后台核对，发现不一致就追查。工具层面还可以用表格的条件格式做重复高亮，用数据验证做状态下拉选项，这些都不需要额外花钱。
判断标准是：这套办法能不能让一个新人十分钟内学会、能不能在没有你本人在场时照常运转，如果能，就已经比大多数小团队的现状好很多了。关键不是工具多高级，而是动作有没有被固定下来。
读者评论
我们三个店铺也遇到过类似问题，但主要不是来源冲突，是同一批人换店铺时复制了旧UPC。后来自己写了个校验表，但字段规范一直没定死，前导零和12/13位还是偶尔漏。文章把建档岗当唯一性守门人我认同，但小团队很难单独设人，可能得让采购在系统提交时就卡住。
四个指标里我比较关心异常收敛周期和申诉成功率。发生率下降有可能是新码录入少了之后自然下降，不一定全是标准化效果；最好再看同期新建SKU数量，否则容易把季节性波动算成管理收益。
供应商授权证明那段很有共鸣。我们之前拿到的PDF也有公章和UPC列表，平台只认GS1或品牌授权链。后来改成先查GS1前缀和注册主体，再决定是否采购，但外部占用还是防不住，只能上架前批量扫一次。