迁移这事儿，本质上是把旧规则翻出来重新数一遍
不少人一听要换跳转方案，第一反应就是：新方案功能更全，把旧配置导过去跑通不就完了嘛。上个月有个做家居流量站的客户就是这么操作的，他们从一套自建的跳转插件换到另一套规则引擎，工程师花了两天把旧规则重新录进去，测试环境跑了一遍主流程，没毛病，直接切生产。结果第三天出事了——一批来自特定渠道的访问全被送进了兜底页面，转化数据掉了将近两成。
后来查出来问题在哪？旧方案里有一条专门针对那个渠道的单独分支，但配置项名称在新方案里叫法不一样，录入的时候被归到了默认组里。这种"看着导完了、实际上没接住"的情况，在跳转迁移里太常见了。说白了，迁移不是把配置从A搬到B就完事，得先把旧规则的全部行为清点一遍，再逐条确认新方案里有没有对应的承接位置。旧规则映射和新规则空白识别，就是这件事的两个面——一个管"搬过去的对不对"，一个管"有没有漏掉的"。
第一步：旧规则全量盘点，别只盯着主流程
旧规则盘点不能只看主分流逻辑。实际系统里通常有三类规则同时在跑，迁移时最容易漏的是后两类：
- 显式分流规则：按来源、设备、地区、参数这些条件做的分支判断，这类一般有配置文件或者管理后台，比较好找。
- 隐式兜底规则： 代码里写死的默认行为，比如"条件都不满足就跳首页"或者"参数缺失补个默认值"，这种往往不在配置面板里，藏在代码逻辑或者中间件里。
- 历史补丁规则： 为了修某个线上问题临时加的判断，比方说某次活动后加的一条参数清洗、某次故障后加的一个超时重试分支。这类规则没有文档，只能翻提交记录。
操作方法与限制
盘点怎么操作？我们是建议按这个顺序来——先从管理后台把全部显式规则导出，形成初始清单；然后拉取跳转相关代码的提交记录，重点看近半年内跟"fix""hotfix""临时"有关的改动，把隐式规则和补丁规则补进清单；最后找当时负责线上运维的人过一遍，口头确认有没有清单之外的行为。
这一步的限制在哪呢？补丁规则往往没有明确的触发条件记录，只能从代码倒推。如果旧系统压根没有版本管理，那盘点就只能靠日志反推——把过去一段时间的跳转日志按结果分组，看哪些结果没法被已知规则解释，那些就是隐藏规则。验证方法也简单：盘点完了之后，拿一批历史请求在旧环境回放，确认清单能解释全部跳转结果，解释不了的就是漏项。
第二步：建映射对照表，把语义差异摊开看
映射表要记四个字段
旧规则和新规则的对应关系不能靠脑子记，得落成一张表。表里至少要有四个字段：旧规则标识、旧规则语义描述、新规则承接位置、映射状态。映射状态分三种：直接对应、需要改写、暂无对应。 "需要改写"是最容易出错的类型。两套方案的规则表达方式不同，举个例，旧方案按"来源渠道编号"分流，新方案按"来源域名后缀"分流，条件语义变了，不能简单复制。改写的时候要写清楚转换逻辑，还得标注这个转换在什么条件下成立、什么条件下会失真。
映射验证方法
映射表建好之后，别急着进新环境配置。先用一批标注过的历史请求做纸上推演：拿每条请求的实际跳转结果，对照映射表逐条走一遍新规则逻辑，看推演结果和旧结果是不是一致。不一致的地方就是映射缺陷。这一步纯人工，慢是慢了点，但能在上线前拦住大部分语义错位问题。
限制条件也得说清楚：推演只能覆盖清单内的请求特征，覆盖不到长尾组合。所以推演之后还要做小流量试运行，用真实流量验证，这个见第四步。
第三步：新规则空白识别，主动去找漏
新规则空白指的是旧系统有行为、新系统没有对应承接的情况。空白通常来自三个地方：
- 旧系统的隐式默认行为在新系统里没有等价物。比如旧系统默认按访问时间做一次会话分组，新系统没有这个维度。
- 旧规则依赖的数据在新系统里拿不到。比如旧规则读了一个内部接口返回的用户等级，新系统没有接入这个数据源。
- 旧规则处理的是异常路径。比如超时、参数缺失、目标不可达时的降级行为，新方案如果只配了正常路径，这些异常路径就是空白。
空白扫描的操作方式
扫描方法用反向比对：以旧规则清单为基准，逐条问"这条规则在新系统里的触发条件、执行动作、异常处理分别对应哪里"。三个都找到对应才算接住，缺一个就是空白。异常处理这块要特别检查——很多迁移只对照了正常路径，异常路径的空白要等线上出问题才暴露出来。
识别出空白之后怎么处理？分两种：能补的就在新系统里补配置或者补逻辑；补不了的（比如数据源缺失）要记录为已知限制，并设定降级方案，比方说用兜底页面承接，同时监控这部分流量的占比。验证方法是：把空白项对应的历史请求单独挑出来，在新环境试运行，确认降级行为符合预期，而且不影响其他规则的正常分流。
第四步：试运行比对与回滚检查
试运行要并行跑
迁移验证不建议直接切换，而是让新旧两套方案并行跑一段时间，同一批流量同时经过旧逻辑和新逻辑，比对两条链路的跳转结果。比对维度至少包括：跳转目标是否一致、跳转耗时是否在可接受范围、异常路径的降级行为是否对齐。
并行跑的限制是成本——两套逻辑同时执行会占用额外资源。如果流量大，可以按比例抽样并行，比如抽百分之几的请求做双跑，其余只走旧逻辑。抽样要覆盖不同来源、不同设备、不同时段，避免样本偏斜。验证指标是：双跑样本中结果不一致的比例，以及不一致请求的特征分布。不一致比例高的特征段，就是需要重点复查的映射或空白项。
回滚检查清单
切换前要确认回滚路径可用。回滚检查至少包含：旧配置是否保留且处于可快速恢复状态、切换开关是否支持快速切回、切换后旧环境的数据写入是否还能对齐。很多团队切换后就把旧配置清理了，一旦新方案出问题，回滚没有依据。建议旧配置保留到新方案稳定运行至少一个完整业务周期，再决定清理。
一个迁移复盘的匿名案例
某做工具类流量的团队，日均跳转请求量在几十万量级，旧方案是一套自研的规则匹配服务，部署在两台中等规格的云服务器上。他们要迁到一套支持可视化配置的规则引擎，目标是降低后续维护成本。
迁移时他们犯了两个错。一是只盘点了配置面板里的显式规则，漏掉了代码里一条"参数归一化"的隐式逻辑——旧系统会把来源参数里的某些分隔符统一替换后再匹配，新引擎不做这个处理，导致一部分带特殊分隔符的请求匹配失败，被送进兜底页。二是没有识别出异常路径空白：旧系统在目标页面返回超时时会重试一次再降级，新引擎默认不重试直接降级，切换后这批请求的落地页质量下降。
调整过程是这样的：他们先用历史日志回放，把兜底页流量的原始请求捞出来，比对旧系统的处理结果，定位到分隔符问题；然后在接入层加了一层参数预处理，对齐旧行为。超时重试的问题则是在并行比对阶段发现的——双跑样本里有一批请求新旧结果不同，追查后确认是重试逻辑差异，在新引擎里补了重试配置。整个过程从发现问题到调整完成用了大约一周，期间旧方案保持在线，没有影响主流量。
最终状态是：新方案承接了旧方案的全部显式规则和补丁规则，隐式逻辑通过接入层补齐，异常路径的重试行为对齐。迁移后运行一段时间，跳转结果与旧方案在抽样比对中基本一致，维护成本按他们的说法降了一半左右。这个案例里最值得借鉴的不是技术方案，而是他们坚持了"旧配置保留到稳定后再清理"这条纪律，给了自己足够的调整空间。
迁移决策边界与检查项
跳转方案迁移要不要做这么细，取决于几个条件。如果旧系统规则数量少、没有隐式逻辑、异常路径简单，可以简化流程，重点做映射对照和小流量试运行。如果旧系统跑了两三年、经历过多次临时修改、有多个数据源接入，那全量盘点和空白识别就不能省。 迁移上线前的检查项可以按这个顺序过一遍：
- 旧规则清单是否覆盖显式规则、隐式规则、补丁规则三类，且能用历史请求回放验证完整性。
- 映射对照表是否标注了每条规则的映射状态，需要改写的规则是否写明了转换逻辑和失真条件。
- 新规则空白是否逐条识别，能补的是否已补，不能补的是否有降级方案和监控。
- 并行比对是否覆盖了不同来源、设备、时段的样本，不一致比例是否在可接受范围。
- 回滚路径是否可用，旧配置是否保留到新方案稳定运行一个完整周期之后。
迁移这件事，快的做法是导配置、跑主流程、切换；稳的做法是把旧规则的行为完整接住再切。两者的差距平时看不出来，等某批流量被错误分流、转化数据掉了才发现，那时候排查成本比迁移前多花的时间高得多。把旧规则映射和新规则空白识别当成迁移的必做环节，而不是可选项，是让切换过程可控的前提。
