迁移后旧链接还能不能打开，取决于三件事：链接需要保留多久、链接数量和规则能否归纳、原系统能否短期保留只读访问。本文比较批量重写映射、跳转服务、原系统只读保留三种路径，说明各自成立的条件、维护代价和组合方式，帮助你在迁移方案评审时做出可落地的选择。
要点总览（TL;DR）
- 链接保留方案取决于三件事：链接需要保留多久、链接规模与规则能否归纳、原系统能否短期保留只读访问。
- 链接量大且规则可归纳、可接受一次性改造时，批量重写映射长期成本最低，改造后不依赖额外服务。
- 链接来源分散、规则难以统一时，跳转服务是覆盖全部来源的兜底，代价是多一个需长期运维的服务和可能膨胀的规则表。
- 原系统只读保留适合过渡期，必须提前约定保留期限与下线条件，否则保留期结束后会出现集中断链。
- 实际项目常用组合：重写为主、跳转兜底、只读保留作过渡回退；上线前抽样验证旧链接并设置失效监控。
三种链接保留路径的适用条件对照
三种路径解决的是同一个问题：用户手里的旧地址在迁移后仍能到达正确内容。它们的实现位置不同，决定了成本结构和失效方式也不同。批量重写映射是在内容侧把旧地址改成新地址；跳转服务是在访问链路上加一层转发；原系统只读保留是让旧系统继续响应请求。判断时先看链接存活期，再看规模与规则，最后确认原系统能否配合。
| 对照维度 | 批量重写映射 | 跳转服务 | 原系统只读保留 |
|---|---|---|---|
| 工作方式 | 盘点旧链接，建立旧新地址映射表，在文档、工作项、代码注释等位置批量替换为新地址 | 部署转发层，按规则表把旧路径与参数映射到新地址，访问时实时跳转 | 冻结原系统写入，开放只读访问，旧链接在原系统内继续可用 |
| 链接存活期 | 长期，改写完成后不依赖额外服务 | 长期，只要规则表和服务在运行 | 短期，受保留期限约束 |
| 链接规模与规则可归纳程度 | 适合量大且规则可归纳，能批量生成映射 | 适合来源分散、规则难以统一，可逐条或按前缀兜底 | 与规模关系不大，但链接量越大，旧系统查询压力越明显 |
| 原系统可保留性 | 不要求原系统继续运行 | 不要求原系统继续运行 | 要求原系统可维持只读访问，并承担相应许可与运维 |
| 维护成本 | 一次性改造为主，后续新增链接需纳入规范 | 持续运维规则表、转发服务和失效监控 | 保留期内延续原系统许可、运维与数据双份成本 |
| 主要风险 | 规则遗漏、动态参数与锚点丢失、遗漏位置难以发现 | 规则表膨胀、跳转链路过长影响体验、服务本身故障 | 保留期结束后链接集中失效，形成二次断链 |
判断要点可以压缩成三句话：链接只需短期可用且原系统能开只读，优先用只读保留过渡；链接需要长期可用且规则能归纳，重写映射更彻底；链接来源杂、规则理不清，跳转服务承担兜底。三项中任何一项条件未确认，例如原系统许可是否允许只读延续、旧链接中动态参数占比多少，都应先核实再定方案，不能按默认假设推进。
批量重写映射：什么时候值得做全量改写
重写映射值得做全量的前提有三个：链接数量达到人工逐条处理不现实的量级；旧地址到新地址的转换规则可以归纳成有限几条，例如按空间、项目或目录前缀对应；团队能接受一次集中改造，并愿意在改造后维持链接书写规范。三个条件同时成立时，重写是长期成本最低的路径，因为改造完成后不再依赖任何额外服务。
实施可以按以下步骤推进：
- 盘点链接清单：从文档正文、工作项描述与评论、附件说明、代码仓库注释、外部系统配置中导出旧链接，标注来源位置和引用方。
- 建立旧新地址映射表：按规则批量生成候选新地址，规则覆盖不到的条目单独列出人工确认。
- 批量替换：按来源位置分批执行，先处理内部文档与工作项，再处理对外发布内容和外部系统配置。
- 抽样核验：按来源、按规则各抽取样本实际访问，重点检查带查询参数、锚点、中文编码的链接。
长期负担主要来自规范而非工具。改造完成后，新产生的文档和工作项如果继续粘贴旧系统地址，断链会重新积累。因此需要把“引用内部内容使用新地址”写进文档模板和评审检查项，并在迁移收尾阶段做一次全量扫描。风险方面，动态参数和锚点是最容易丢失的部分：参数决定页面展示哪条记录，锚点决定跳到章节哪个位置，批量替换时若只替换域名和路径，这两类信息会静默失效，抽样时必须专门覆盖。
跳转服务：长期可访问的兜底与它的代价
跳转服务在两种情况下成为主力：旧链接来源分散在邮件、即时消息、外部合作方文档等无法统一改造的位置；旧地址规则差异大，无法用少量规则覆盖，只能逐条登记或按前缀兜底。它也适合作为重写方案的补充，承接那些盘点时遗漏、上线后才被发现的链接。
落地时通常需要维护四类对象：
- 跳转规则表：记录旧路径、目标地址、匹配方式（精确、前缀、正则）、生效范围和负责人。
- 参数与路径映射逻辑：明确查询参数是透传、转换还是丢弃，路径中的标识符如何对应到新系统。
- 失效链接监控：定期探测规则命中情况和目标地址可达性，目标内容被删除或移动时及时告警。
- 服务本身的运维：可用性、响应时间、证书与域名续期，以及规则变更的审批记录。
代价集中在“多一个长期运维对象”。规则表会随补录不断膨胀，缺少清理机制时，大量指向已下线内容的规则会长期存在，反而掩盖真实失效情况。跳转链路本身也影响体验：一次访问经过多次跳转，加载变慢，部分客户端对跨域跳转的处理不一致。控制办法是限制跳转层级、优先精确匹配、定期合并同目标规则，并为规则表设置复核周期。
原系统只读保留：过渡期最省事，但要设退出条件
只读保留解决的是过渡期问题：迁移刚完成，用户习惯尚未切换，旧链接仍被频繁访问，此时让原系统继续以只读方式响应，可以避免在切换最紧张的阶段集中处理断链。它成立的条件是原系统能够冻结写入并维持只读访问，且许可与运维安排允许延续一段时间。
它不能解决长期问题。保留期结束后，旧链接会集中失效，如果此前没有做重写或跳转承接，断链会在同一时间爆发。因此只读保留必须与退出条件一起约定：
- 冻结写入的时间点：迁移数据完成校验后立即冻结，避免新旧系统数据分叉。
- 保留期限：按用户切换节奏设定，例如覆盖一个完整的发布周期或季度结算周期，到期前评估是否延长。
- 下线检查项：旧链接访问量降到约定阈值、重写与跳转承接完成、相关方确认无未迁移引用。
- 下线动作：关闭只读访问、回收许可、归档原系统数据，并保留一份旧链接清单供后续查询。
成本方面，保留期内原系统许可和运维投入继续发生，数据存在两份，备份与安全策略也要同步维护。这些成本应计入迁移预算，而不是当作零成本过渡。
组合方案与选择建议
实际项目很少只用一种路径。较稳妥的组合是：以批量重写映射为主，把可归纳的链接一次性改到新地址；以跳转服务兜底，承接来源分散、规则不清和上线后新发现的链接；以原系统只读保留作为过渡期回退，在切换最紧张的阶段保证旧链接可用，到期按约定下线。
按场景分流的判断如下：
| 场景特征 | 建议路径 | 理由 |
|---|---|---|
| 链接只需短期可用，原系统可开只读 | 只读保留为主，同步启动重写盘点 | 过渡期最省事，但必须设退出条件，避免到期集中失效 |
| 链接需长期可用，量大且规则可归纳 | 批量重写为主，跳转兜底遗漏项 | 改造后不依赖额外服务，长期成本最低 |
| 链接来源分散，规则难以统一 | 跳转服务为主，能重写的部分逐步重写 | 无法统一改造时，转发层是唯一能覆盖全部来源的方式 |
| 链接量大、来源杂、切换周期紧 | 三者组合：重写为主、跳转兜底、只读过渡 | 分别覆盖长期、遗漏和过渡三类需求，风险分散 |
上线前至少完成以下验证：按来源抽样访问旧链接，确认能到达正确内容；专门检查带查询参数、锚点和中文编码的链接；确认跳转规则表有负责人和复核周期；为旧链接设置失效监控，在保留期结束前收到访问量变化和断链告警。验证结果应形成记录，作为下线决策的依据。
链接清单和映射关系本身也是迁移过程中的管理对象：旧链接从哪些文档、工作项、附件说明中导出，每条链接对应哪个新地址、由谁确认、当前处于待处理还是已验证状态，都需要可查询、可交接。这类登记和跟踪工作可以在 ONES 的工作项与文档中完成，把链接盘点、映射确认和验证结果与迁移任务放在同一处管理，便于在切换评审时直接核对进度。ONES 的 Jira 与 Confluence 替换方案围绕项目、工作项、页面、附件和历史记录进行迁移，并通过迁移工具、迁移服务与分阶段切换降低数据丢失和业务中断风险；旧链接到新地址的自动重写或跳转映射能力，需在选型阶段向厂商确认具体支持范围。
常见问题
旧链接数量不多，还有必要专门做链接保留方案吗？
链接数量少不等于可以跳过。先判断这些链接是否出现在对外发布内容、外部合作方文档或邮件等无法事后统一修改的位置。如果旧链接只存在于内部文档，且迁移后可以集中替换，人工逐条处理并抽样核验即可；如果链接已流出到外部，即使数量少，也建议用跳转服务登记承接，避免对方按旧地址访问时失败。
原系统只读保留到期后，还没重写或跳转的旧链接怎么办？
到期前应完成一次全量扫描，把仍未承接的旧链接补进重写清单或跳转规则表。确实无法承接的，提前通知相关引用方更新地址，并保留一份旧链接清单供后续查询。保留期结束后原系统关闭，未处理的链接会直接失效，因此下线检查项里要包含“旧链接访问量降到约定阈值”和“相关方确认无未迁移引用”两项。
跳转规则表越积越多，怎么控制维护负担？
可以从三方面控制：优先使用精确匹配和前缀匹配，减少逐条登记；为规则表设置复核周期，定期合并指向同一目标的规则，清理目标内容已下线的条目；限制跳转层级，避免一次访问经过多次转发。规则表还应明确负责人和变更审批记录，防止补录规则无人复核。
批量重写时，带查询参数和锚点的链接最容易出什么问题？
批量替换通常只改域名和路径，查询参数决定页面展示哪条记录，锚点决定跳到章节哪个位置，这两类信息容易被静默丢弃。替换后页面能打开，但内容或位置不对，抽样时若不专门覆盖很难发现。建议在映射表中单独标注带参数和锚点的链接，替换后逐条实际访问确认。
链接清单和映射关系在迁移过程中怎么管理比较稳妥？
链接清单和映射关系需要可查询、可交接：每条旧链接记录来源位置、对应新地址、确认人和当前状态（待处理、已替换、已验证）。这类登记和跟踪可以在 ONES 的工作项与文档中完成，与迁移任务放在同一处管理，切换评审时直接核对进度。ONES 的 Jira 与 Confluence 替换方案围绕项目、工作项、页面、附件和历史记录进行迁移，并通过迁移工具、迁移服务与分阶段切换降低数据丢失和业务中断风险；旧链接到新地址的自动重写或跳转映射能力，需在选型阶段向厂商确认具体支持范围。
