研发数据迁移后要保留链接，选择取决于链接规模、目标地址是否稳定，以及旧链接需要被访问多久。批量重写映射把旧地址直接替换成新地址，适合链接可枚举、对应关系稳定的情况；跳转服务在访问层维护旧地址到新地址的规则，适合链接量大、来源分散或目标仍会调整的情况。原系统短期只读保留能撑过迁移窗口，但长期链接策略仍需在两者之间作出安排。
要点总览（TL;DR）
- 判断依据集中在三点：链接总量能否枚举、新旧地址对应关系是否稳定、迁移后目标地址是否还会变动。
- 链接规模可控、目标一次确定、旧系统可下线时，批量重写映射的长期负担最轻，成本集中在迁移期的梳理、改写与核验。
- 链接量大、来源分散、外部引用多或目标仍会调整时，跳转服务更合适，代价是长期维护规则表并保障跳转层可用。
- 原系统只读保留适合迁移窗口期兜底，链接可用性绑在旧系统运行状态上，不宜作为长期方案。
- 常见做法是组合：重写映射收敛主体链接，跳转服务承接无法改写或来源不可控的入口，再配合抽样核验与死链监控。
三种链接保留方式的同口径差异对照
讨论链接保留，先要分清三种方式各自作用在哪一层。批量重写映射改的是数据内容本身：迁移前或迁移中把文档正文、工作项描述、配置项里的旧链接替换为目标系统的新地址，访问者拿到的是已经指向新位置的链接。跳转服务作用在访问层：旧地址仍然存在，请求到达后被重定向到新地址，数据内容可以不改。原系统只读保留则把旧系统继续运行，让旧链接在原处可访问，属于过渡手段。
三者可以在同一组维度下比较，但要注意它们的成本发生时间和长期依赖完全不同。下表按链接规模、目标确定性、维护成本、长期可用性依赖、回退难度和对旧系统的依赖逐项对照，资料未覆盖的具体产品能力标注为待确认。
| 对照维度 | 批量重写映射 | 跳转服务 | 原系统只读保留 |
|---|---|---|---|
| 作用位置 | 改写目标数据中的链接地址 | 在访问层做重定向 | 保留旧系统可访问 |
| 适用链接规模 | 总量可控、可枚举 | 数量大、来源分散 | 不限，但受旧系统运行成本约束 |
| 目标地址确定性 | 要求新旧地址有稳定对应关系 | 目标可后续调整，改规则即可 | 不涉及目标地址 |
| 维护成本发生时间 | 集中在迁移期的一次性梳理、改写与核验 | 转为长期运行的规则维护与可用性保障 | 迁移窗口期内持续承担旧系统运维 |
| 长期可用性依赖 | 改写完成后不依赖额外服务 | 依赖跳转服务持续可用 | 依赖旧系统持续运行 |
| 回退难度 | 较高，改写后需再次批量处理才能回退 | 较低，调整或撤销规则即可 | 低，旧系统仍在原处 |
| 对旧系统的依赖 | 迁移完成后可下线旧系统 | 可下线旧系统，但需保留跳转层 | 强依赖，旧系统不能停 |
初步分流可以按两个问题判断：链接总量是否可枚举、目标地址在迁移后是否还会变。规模可控且目标一次确定，重写映射的长期负担最轻；规模大、来源不可控或目标仍会调整，跳转服务的调整成本更低。原系统只读保留适合放在迁移窗口期兜底，不宜作为长期方案，因为它把链接可用性绑在旧系统的运行状态上。
批量重写映射的适用条件与维护成本
批量重写映射更适合链接总量能够列清、新旧地址存在稳定对应关系、并且迁移完成后旧系统可以下线的场景。典型情况是内部文档库、项目空间或知识库整体搬迁，页面地址按固定规则生成，旧地址与新地址可以按路径或标识逐条对应。此时一次性改写能让数据内容自洽，访问者打开文档时直接落到新位置，不再经过额外一层。
适用条件可以整理成一份可核对的清单：
- 链接清单能够完整导出，包括正文链接、附件引用、导航配置等位置；
- 新旧地址之间存在可解释的对应规则，而不是逐条人工判断；
- 迁移后旧系统计划下线，不需要长期维持双系统运行；
- 有明确的抽样核验与遗漏排查安排，能覆盖非标准写法的链接。
成本主要集中在迁移期。前期要梳理映射规则，把旧地址与新地址的对应关系整理成可执行的清单；中期执行批量改写，按数据类型分批处理；后期做抽样访问核验和遗漏排查，确认没有留下指向旧地址的死链。这部分工作量与链接数量和写法规范程度直接相关，链接写法越不统一，排查成本越高。
风险主要有三类。映射规则写错会产生死链，而且批量执行会放大错误范围，所以改写前需要小范围试跑。非标准链接容易被遗漏，例如手工拼接的短链、嵌在附件或图片说明里的地址，导出清单时未必能覆盖。目标地址后续若再次变更，已经改写的链接需要重新批量处理，这也是重写映射更适合目标稳定场景的原因。具体迁移工具是否提供链接批量改写能力，需要按实际工具确认，本文不对未验证的产品能力作断言。
跳转服务的适用条件与长期维护要求
跳转服务更适合旧链接数量大、来源分散、外部书签与文档引用多，或者目标地址在迁移后仍可能调整的场景。它的优势在于数据内容不必逐条改写，旧地址继续对外可用，访问请求在访问层被引导到新位置。对于已经发出去的邮件、外部合作方收藏的页面、印刷材料上的短链，跳转服务是少数能够在不追回原始内容的前提下继续承接访问的方式。
选择跳转服务意味着接受一份长期维护责任，需要持续投入的动作包括：
- 规则表持续维护：新增旧地址、调整目标地址、清理失效规则都要有记录；
- 保障跳转服务自身的可用性与性能，访问高峰和批量请求下不能成为新的瓶颈；
- 定期排查规则冲突与循环跳转，避免一条旧地址被多条规则命中或跳转成环；
- 建立死链监控，目标地址失效时能及时发现并修正规则。
长期风险在于跳转层会变成一项持续依赖。规则表缺少治理会逐渐腐化，出现指向已下线页面、重复定义或无人认领的条目；跳转服务一旦中断，影响面覆盖所有仍在使用旧地址的访问者，比单条链接失效更集中。因此跳转服务需要明确的责任人和变更评审，不能只在迁移上线时配置一次。
原系统只读保留与跳转服务的关系需要说清：只读保留可以在迁移窗口期让尚未处理的入口继续可访问，为规则梳理争取时间，但它依赖旧系统持续运行，运维成本和系统生命周期都受限制。窗口期结束后，仍需要把访问承接转到跳转服务或完成重写，长期策略不能停留在只读保留上。
按场景给出选择建议与组合路径
把前面的条件落到具体场景，选择会清晰很多。下面三种场景覆盖了多数迁移决策，第四种是常见的组合做法。
场景一：链接规模小、目标确定、旧系统可下线。优先批量重写映射。链接清单可以一次列全，新旧地址对应关系稳定，改写并核验后即可关闭旧系统，长期不再需要维护额外的访问层。适合内部知识库、项目文档整体搬迁这类边界清楚的任务。
场景二：链接规模大、外部引用多、目标可能变动。优先跳转服务。旧地址继续对外可用，目标地址调整时改规则即可，不必回头修改已经发布的内容。需要同步落实规则责任人、变更评审和死链监控，把长期维护成本纳入迁移后的日常运维。
场景三：迁移窗口期需要过渡。原系统只读保留加逐步收敛。迁移期间让旧系统保持只读访问，给链接梳理和核验留出时间，同时按批次把入口迁移到重写映射或跳转服务，窗口期结束前完成收敛，避免旧系统长期运行。
组合路径：重写映射处理主体，跳转服务承接入口。迁移期先用批量重写映射收敛主体链接，让大部分文档和工作项内容直接指向新地址；对无法改写或来源不可控的入口，例如外部书签、已发布的短链、第三方系统里配置的回调地址，用跳转服务承接。这样既减少长期规则表的规模，又保留对不可控入口的兜底能力。
无论采用哪种路径，验证方向一致：按比例抽样访问新旧地址，确认跳转或改写后的落点正确；上线后持续做死链监控，把异常链接回流到清单；对规则变更做评审和留痕，避免跳转规则在无人复核的情况下累积。验证结果应当可以回溯到具体的链接条目和责任人，而不是只留一份上线报告。
迁移中的链接清单与规则如何被持续管理
链接保留的技术方案确定后，落地效果取决于清单、规则和核验记录是否被当作可追踪的对象管理。链接数量一多，靠表格和聊天记录传递状态很容易出现遗漏：某条链接改写到哪一步、由谁核验、异常是否处理完，都需要有统一的状态和责任人。
可以把链接清单、映射规则和核验结果作为工作项与文档来承载。每条待处理链接或每批规则对应一个工作项，记录旧地址、目标地址、所属数据类型和处理状态；映射规则与核验标准沉淀为文档，供迁移负责人、规则维护人和验收人共同查阅。角色分工上，迁移负责人统筹范围与批次，链接规则维护人负责对应关系和规则变更，验收人按抽样结果确认是否通过。
状态流转建议覆盖四个阶段：待映射、已改写、已核验、异常待处理。链接进入待映射后由规则维护人补齐目标地址；执行改写或配置跳转后转为已改写；验收人抽样确认落点正确后转为已核验；发现死链或跳转异常则进入异常待处理，修正后重新走核验。规则变更保留修改记录，验收结果与具体链接条目关联，后续出现问题时可以回溯到当时的判断依据。
ONES 在迁移场景中提供项目、工作项、文档与知识库的承载方式，迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，Confluence 空间、页面、附件和权限结构可迁移到 ONES Wiki，并支持批量迁移与数据包导入。链接清单与核验记录可以借助工作项状态和 Wiki 文档形成可追踪的交接链路，让规则变更和验收结果有据可查。迁移工具是否直接提供旧链接的批量重写或跳转承接，需要按实际环境确认；在工具能力之外，把清单和规则纳入统一的工作项与文档管理，是让链接保留结果可维护、可交接的基础动作。
常见问题
链接数量不多，但部分旧地址找不到稳定的对应规则，还能只靠批量重写映射吗？
可以先把能建立稳定对应关系的链接纳入批量重写，这部分通常占多数。找不到稳定规则的链接单独列出，逐条确认目标地址；确认不了的，用跳转服务承接，避免为了凑齐映射规则而人工猜测地址。判断标准是这条链接能否解释清楚旧地址与新地址的对应关系，能解释的走重写，解释不了的走跳转。
跳转服务上线后，规则表应该由谁维护、多久检查一次？
规则表需要明确一名维护人，负责新增旧地址、调整目标地址和清理失效条目；变更建议经过评审再生效，避免多人同时改动产生冲突。检查频率按访问量和变动情况定：目标地址经常调整的阶段可以每周核对一次死链与循环跳转，稳定后可放宽到每月。关键是检查结果要回流到清单，而不是只看跳转服务是否在线。
原系统只读保留能撑多久，什么时候必须切换到重写或跳转？
只读保留的期限取决于旧系统的运维成本和合同安排，没有统一时限。可操作的判断是：当链接清单已完成梳理、主体链接已改写或配置跳转、抽样核验通过后，就应安排旧系统下线，把剩余入口收敛到长期方案。窗口期内每延长一段，旧系统运维和双系统并行成本都会继续发生。
重写映射和跳转服务同时使用，核验时怎么避免两边都漏掉？
把链接清单作为唯一台账，每条链接标注处理方式（重写或跳转）和当前状态，核验按台账逐条抽样，不按方案分头检查。发现死链时先回到台账确认这条链接归哪一边处理，再修正对应规则或改写结果。规则变更和核验记录都关联到同一条链接条目，交接时按台账核对，可以减少两边都以为对方处理了的情况。
迁移工具本身是否支持旧链接批量改写或跳转承接？
这需要按实际使用的迁移工具确认，不同工具对链接地址的处理范围不同。ONES 的迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，Confluence 侧支持空间、页面、附件和权限结构迁移到 ONES Wiki，并支持批量迁移与数据包导入；资料未说明迁移工具是否直接提供旧链接的批量重写或跳转承接，选型时应向工具方核实这一项。
