百度分享插件，工具支持的对象格式变化时怎样改输入规范
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /547f421d7b9a.html
📄
百度分享插件，工具支持的对象格式变化时怎样改输入规范
先给结论：不要直接把新格式塞进旧输入规范，而要先判断变化属于“同一对象的字段增减”还是“对象类型本身换了”。前者只需改字段映射和校验规则，后者必须新增一层对象识别，否则历史数据和新数据会混在同一列里，后续核对时谁也说不清哪条属于哪种格式。下面按这两种条件分别说明改法、动作和例外。
先分清两种变化：字段变了，还是对象变了
判断依据不看文件后缀，而看“一条记录代表什么”。如果一条记录仍然代表同一个分享入口或同一段页面配置，只是多了或少了几个属性，这是字段变化。如果一条记录从“一个分享按钮”变成“一组分享渠道配置”，或者从“页面级配置”变成“站点级配置”，这是对象变化。
可核对的证据有三类：一是旧数据里每条记录能否一对一映射到新数据；二是新数据里是否出现了旧规范无法表达的必填属性；三是把新旧数据放在同一张表里时，主键是否还唯一。如果主键不再唯一，基本可以判定为对象变化，而不是字段增减。
条件一：只是字段增减时，改映射不改结构
这种情况下，输入规范应保持原有对象层级，只做三件事：新增字段设为可空或给默认值、旧字段标记弃用但不立即删除、在规范里写明每个字段的取值来源。
实际动作是先在导入环节加一道字段白名单校验，遇到规范外的字段先拦截并记录，而不是静默丢弃。这样做的结果是：你能看到新格式里到底多了什么，再决定是补进规范还是忽略。下一步才更新映射表，并把历史数据按旧字段回填，保证新旧记录用同一套字段名读取。
例外是：如果新增字段会影响筛选或统计口径，就不能只做可空处理，必须同步修改下游的聚合逻辑，否则同一指标会因数据来源不同而出现两个版本。
条件二：对象类型变了时，先加一层对象标识
对象变化时，最忌讳的是把新格式硬套进旧列。可行做法是在输入规范最前面加一个对象类型字段，取值由人工或规则判定，而不是靠格式猜测。之后每个对象类型各自维护一套字段规范，共用同一张表时用类型字段区分。
实施顺序建议如下：
- 列出旧规范能表达的对象类型，以及新格式实际出现的对象类型。
- 为每种类型定义最小必填字段，缺一即判为不合格输入。
- 在导入时先判类型，再按对应规范校验，类型无法判定就退回人工确认。
- 把历史数据按旧类型补上类型标识，完成后再开放新格式写入。
这样做的直接结果是：同一批数据里不同对象不会互相污染，核对时能按类型分别抽样。下一步可以针对数量最多的类型优先细化规范，而不是一次性重写全部规则。
把分歧转成可核对项：一份最小的判定清单
当多个角色对“格式到底变没变”有不同理解时，不要争论定义，直接跑一份对照清单。假设有一批旧记录和一批新记录，可以这样核对：
- 取新旧各若干条，尝试一对一映射，能全部映射则偏向字段变化。
- 检查主键是否唯一，出现重复则偏向对象变化。
- 检查新记录里是否存在旧规范无法表达的必填项，存在则偏向对象变化。
- 把两类记录混在一起做一次筛选，若结果无法区分来源，则说明规范缺少类型标识。
这份清单的作用不是给出绝对答案，而是把“我觉得变了”变成“哪一条映射不上、哪个主键重复了”。有了具体条目，修改输入规范才有依据，否则容易在字段名上反复调整却解决不了根本问题。
改完后必须验证的三件事
规范改完不等于生效。第一，用旧数据回放一遍导入流程，确认历史记录仍能通过校验；第二，用新格式样本跑一遍，确认不合格输入会被明确拦截并给出原因；第三，抽查下游读取逻辑，确认类型字段被正确使用，而不是被当作普通属性忽略。
如果这三步里有任何一步失败，先不要扩大新格式的写入范围，而应回到对象类型判定环节重新核对。只有当新旧数据能在同一套规则下分别通过、且混在一起时仍可区分，输入规范的修改才算完成。
