网站历史记录查询：工具支持的对象格式变化时怎样改输入规范
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /040ea9b3d4f9.html
📄
网站历史记录查询：工具支持的对象格式变化时怎样改输入规范
先给结论：格式变化时不要整批改规范，而要先判断变化属于“可兼容扩展”还是“语义替换”。前者只需追加映射并保留旧字段，后者必须冻结旧规范、建立版本号，再逐类迁移。判断依据不是工具提示，而是你手上对象的实际类型与下游用途。
先分清两种格式变化，再决定动不动规范
工具支持的对象格式变化，通常来自两类原因。一类是字段扩展，比如原来只接受域名，现在也能接受带路径的完整链接；旧输入仍能被解析，只是新增字段可选。另一类是语义替换，比如原来用“站点标识”指代一个域，现在同一个字段名被用来指代某个具体页面或子目录。前者可兼容，后者不可兼容。
可兼容扩展的处理代价低：在输入规范里追加一条映射规则，说明新字段从哪来、缺省时怎么回退，旧记录不动。语义替换的代价高：同一个字段名在不同批次里含义不同，后续核对、去重和比对都会出错，必须引入版本区分。
判断方法很直接：拿三条旧输入，按新格式重新解析一次。如果解析结果与旧结果指向同一对象，属于可兼容扩展；如果指向的对象层级变了，属于语义替换。这一步不需要工具配合，用现有数据就能做完。
条件一：对象仍是同一层级时，追加映射而不是重写规范
当新旧格式指向的对象层级一致，只是表示方式不同，例如从裸域变成带协议的完整地址、从纯文本变成结构化字段，建议保留旧规范并追加映射层。实施动作是：在输入环节增加一个规范化步骤，把各种写法统一转换成内部标准形式，再交给查询工具。
这个动作的结果会直接影响下一步。转换层一旦建立，后续新增格式只需在转换层加规则，查询逻辑不用改；如果跳过这一步直接改查询逻辑，每次格式变化都会牵动下游，迁移成本随批次累积。
需要设例外：如果新格式允许一个输入对应多个对象，比如一个标识同时展开为多个子域，追加映射就不够了。此时必须先在转换层做拆分，明确是一条记录还是多条记录，否则去重和比对会得到看似合理但实际错误的结果。
条件二：对象层级或语义变了时，冻结旧规范并加版本号
当新格式指向的对象与旧格式不在同一层级，或者同一字段名承载了新含义，继续在旧规范上打补丁会制造歧义。此时应冻结旧规范，给输入规范加版本号，新旧批次分开存放，并记录每批使用的版本。
实施动作分三步：先给现有规范标注版本并停止修改；再为新格式单独建一份规范，写明适用对象和字段含义；最后做一次抽样比对，确认同一对象在两种规范下能被正确区分，而不是被误判为两条不同记录。
这一步的结果决定迁移节奏。如果抽样比对显示新旧规范对同一对象的判定一致，可以按批次逐步迁移；如果出现大量误判，说明差异不只是格式，而是对象定义本身变了，需要先统一对象定义，再谈迁移。这里要提醒：查询结果条数突然变化，不能单独证明规范改对了，它也可能来自数据源覆盖范围变化或抓取周期不同，需要结合对象定义一起看。
一个注明假设的短例子
假设某批历史记录查询的输入对象原本是“域”，规范要求只填裸域；工具更新后开始接受“域加路径”的写法。若你的查询目标是看整个域的历史变化，路径属于噪声，应在转换层截断路径，保留旧规范；若你的查询目标是区分同一域下不同目录的历史，路径就是必要信息，应新建带版本号的规范，把对象定义为“域加路径”，并重新核对旧批次的记录能否对应到目录层级。
两种做法都成立，区别在于查询目标。选错方向的代价是：该截断时保留路径，会把一个域拆成多条记录，造成重复；该保留路径时截断，会把不同目录的变化混在一起，掩盖真实差异。
改完输入规范后，先验证三件事再全量切换
- 旧输入在新规范下是否仍指向同一对象，抽三条以上逐一核对。
- 新格式是否引入一对多关系，若有，先确定拆分规则再入库。
- 版本标记是否随记录一起保存，否则后续无法解释同一字段的两种含义。
三项都通过，再按批次切换；任何一项不通过，先修规范而不是修数据。规范改动的正确性，最终要看它能否让不同批次的对象保持可比，而不是看单次查询是否跑通。
