Confluence 迁移完成后发现链接打不开，通常集中在三类原因：页面或附件没有迁入导致目标对象缺失，空间键、标题或层级调整让旧路径无法解析，以及迁移工具只搬运正文、没有重写页面互链和附件地址。排查时先按失效范围缩小问题层级，再逐类验证原因，分别用补迁、重定向或批量替换处置，最后通过巡检和抽样点击确认恢复，并把链接检查写入迁移验收。
要点总览（TL;DR）
- 迁移后链接失效先按范围定位：个别页面内链、某个空间整体、跨空间或全站，三种范围对应不同的成因方向。
- 原因验证要逐类进行：对象缺失看新端能否搜到目标，路径变化比对空间键与层级，引用未重写检查正文中的旧域名和旧路径。
- 处置按原因分开：漏迁的补迁并记录映射，路径变化的配置重定向或别名，引用未重写的导出清单分批替换，批量操作前先备份。
- 验证以失效清单清零或剩余项有处置记录为标准，并把链接巡检写入迁移验收，迁移前导出链接清单、迁移中保留对象 ID 或建立映射表可减少复发。
- 采用 ONES 迁移方案替换 Confluence 时，官方资料说明可迁移空间、页面、附件、权限结构及正文、图片、常用宏与批注；链接重写与巡检的具体支持程度需在迁移前与服务方确认。
先判断失效范围：单页、单空间还是全站
链接失效的数量和分布，决定了应该先查哪一层。范围判断的目标是用最小成本找到问题所在的层级，避免一上来就全量重写。可以先把失效链接按出现位置归类，再对照迁移范围判断成因方向。
| 失效范围 | 典型表现 | 优先排查的成因方向 |
|---|---|---|
| 个别页面内链 | 只有某几篇页面中的互链或附件链接打不开，其他页面正常 | 引用未重写，或该页面引用的对象漏迁 |
| 某个空间整体 | 同一空间内大量链接失效，跨空间链接正常 | 空间键或空间路径变化，空间内页面层级调整 |
| 跨空间或全站 | 多个空间、多个入口同时失效，包括导航和收藏 | 域名或基础路径变化，批量迁移时引用整体未重写 |
收集证据时，先导出一份失效链接清单，记录每条链接的原始地址、所在页面、点击后的表现（404、跳转到错误页面、空白）。再抽取若干代表性页面，对照迁移前后的页面标题、所在空间和父子层级。抽样要覆盖不同空间和不同页面类型，避免只看到某一类问题。
还需要区分迁移引入的失效与迁移前已存在的死链。做法是回看源端 Confluence 中同一批链接的状态：源端就已失效的链接，迁移后自然仍然失效，这类问题应单独记录，不计入迁移缺陷。只有源端可正常访问、迁移后无法访问的链接，才属于本次迁移需要处置的范围。
逐类验证原因：对象缺失、路径变化还是引用未重写
范围确定后，下一步是把原因假设与验证证据对应起来。三类原因的表现有重叠，不能凭第一印象直接下结论，需要逐类验证。
| 原因假设 | 验证动作 | 判定证据 |
|---|---|---|
| 对象缺失 | 打开失效链接，按标题或附件名在新端搜索目标对象；同时回源端确认该对象是否存在 | 新端搜不到目标页面或附件；源端仍存在，说明是漏迁而非删除 |
| 路径变化 | 比对迁移前后的空间键、页面标题和父子层级，检查旧 URL 的路径段能否解析到对应对象 | 目标对象在新端存在，但旧地址的路径段与新路径不一致 |
| 引用未重写 | 查看页面正文源码，检查互链、附件链接和图片地址指向的域名与路径 | 正文中仍保留旧域名或旧路径，链接文本正常但地址未更新 |
| 外部书签与硬编码链接 | 确认失效链接来自浏览器书签、邮件或第三方系统配置，而非页面正文 | 链接不在迁移数据范围内，迁移工具无法控制其指向 |
对象缺失的验证要点是区分漏迁与主动删除。如果源端仍有该页面，说明迁移范围没有覆盖到，属于漏迁；如果源端已删除，则链接失效是预期结果，处置方式应是清理链接而非补迁。附件缺失同理，需要确认附件是否在迁移数据范围内。
路径变化的验证要落到具体路径段。空间键调整、页面改名、父子层级重排都会改变 URL，但目标对象本身仍然存在。这类失效的共同特征是：在新端能搜到内容，只是旧地址无法定位。验证时可以手动把旧路径中的空间键或标题替换为新值，看是否能打开，以此确认路径变化是唯一原因。
引用未重写的验证集中在正文内容。批量迁移后，页面正文中的互链、附件下载地址和图片地址可能仍指向旧域名。检查时抽取若干页面查看源码中的链接地址，如果大量页面同时出现旧地址，基本可以判定为引用未重写。这类问题与对象缺失的区别在于：目标对象可能已经迁入，只是链接地址没有跟着更新。
外部书签和第三方系统硬编码链接不受迁移工具控制。用户浏览器收藏、邮件中的历史链接、其他系统配置的回调地址，都需要单独通知持有方处理。排查时应把这类链接从迁移缺陷清单中分离出来，避免与可修复项混在一起统计。
按原因处置：补迁、重定向与批量重写
原因确认后，处置方式按类型分开执行。涉及批量修改的操作，先备份、再分批、保留回滚点，是贯穿始终的操作边界。
对象缺失：补迁或重建并记录映射
先回源端确认页面或附件是否仍然存在。存在则安排补迁，补迁时记录源对象与新对象的对应关系，便于后续修正引用。源端已删除的对象，不必补迁，直接清理指向它的链接，并在清单中注明原因。补迁完成后，检查是否有其他页面引用该对象，一并更新。
路径变化：配置重定向或保留旧路径别名
对确认属于路径变化的链接，可以在新端配置重定向规则，把旧地址指向新地址；如果平台支持保留旧路径别名，也可以为高频访问的页面设置别名。重定向适用于路径规则相对稳定的场景，规则数量多、路径变化频繁时，维护成本会上升，需要评估规则的可管理性。配置完成后逐条测试，确认跳转目标正确。
引用未重写：导出清单、按映射批量替换
先导出失效链接清单和新旧对象映射表，核对每条旧地址对应的新地址。批量替换前备份受影响的页面内容，替换范围限定在链接地址，避免误改正文中的普通文本。建议分批执行，每批完成后抽样点击验证，确认无误再推进下一批。发现替换错误时，用备份回滚该批次，修正映射表后重新执行。
外部链接：通知持有方或提供跳转说明
浏览器书签、邮件历史链接和第三方系统配置的地址，迁移工具无法自动更新。可以整理一份新旧地址对照说明，通知相关持有方更新；对访问量大的入口，提供跳转说明页，减少访问中断。这类处置不追求一次性清零，重点是让持有方知道新地址在哪里。
所有批量操作前都应确认备份可用、回滚步骤清晰。替换脚本或规则先在少量页面上试运行，确认匹配逻辑不会误伤正常内容，再扩大范围。
验证恢复与防止复发
处置完成后，验证的目标是确认失效清单清零，或剩余项都有明确的处置记录。验证方式可以组合使用：用链接巡检工具扫描全站，检查是否还有指向旧地址或不存在对象的链接；对关键入口页面（首页导航、空间首页、常用文档目录）逐个人工点击核对；从失效清单中抽样回访，确认原链接已能打开或正确跳转。
通过标准建议写成可核验的条目：巡检扫描无新增失效链接；抽样点击全部通过；剩余未修复项在清单中注明原因（如源端已删除、外部持有方待更新）和责任人。这样验收时不必依赖主观判断。
防止复发的重点在迁移流程本身。迁移前导出源端链接清单，作为后续比对的基线；迁移中尽量保留对象 ID，或建立完整的新旧映射表，让引用重写有据可依；迁移后把链接巡检纳入验收清单，与数据完整性检查一起执行。对于采用 ONES 迁移方案替换 Confluence 的团队，官方资料说明可将空间、页面、附件和权限结构迁移到 ONES Wiki，迁移数据包括页面正文、附件、图片、常用宏及批注，并支持批量迁移与数据包导入。链接重写、重定向和巡检的具体支持程度，建议在迁移前与服务方逐项确认，并把确认结果写入迁移方案。
迁移后的链接维护也可以纳入日常协作。把链接巡检结果作为工作项记录，明确负责人和处理状态；把新旧地址映射表作为文档留存，供后续引用和排查使用。这样链接问题从一次性修复转为可跟踪的日常事项，下次迁移时也有可复用的基线资料。
常见问题
迁移前源端就存在的死链，迁移后需要一并修复吗？
建议分开处理。回看源端 Confluence 中同一批链接的状态，源端已失效的链接迁移后自然仍然失效，属于历史遗留问题，不计入本次迁移缺陷。处置时可以清理这些链接或在清单中注明原因，避免与迁移引入的失效混在一起统计，影响对迁移质量的判断。
重定向规则配置多少条比较合适，规则太多怎么办？
重定向适合路径规则相对稳定的场景。规则数量多、路径变化频繁时，逐条维护的成本会明显上升。可以按访问频率分层：高频入口页面优先配置重定向或旧路径别名，低频页面改为在页面内说明新地址，或通过映射表供检索。配置完成后逐条测试跳转目标，确认没有指向错误页面。
批量替换链接时如何避免误改正文中的普通文本？
替换范围限定在链接地址，匹配规则要包含域名或路径特征，避免用短字符串做全局替换。操作前备份受影响页面，先在小批量页面上试运行，抽样点击确认无误后再扩大范围。每批完成后保留回滚点，发现误改时用备份恢复该批次，修正映射表后重新执行。
外部系统里硬编码的旧链接，迁移团队能做什么？
迁移工具无法控制浏览器书签、邮件历史链接和第三方系统配置中的地址。可以整理新旧地址对照说明，通知相关持有方更新；对访问量大的入口提供跳转说明页，减少访问中断。这类事项不追求一次性清零，重点是让持有方知道新地址，并在清单中记录待更新状态和责任人。
用 ONES 迁移方案替换 Confluence 时，链接相关事项需要提前确认什么？
官方资料说明可将 Confluence 空间、页面、附件和权限结构迁移到 ONES Wiki，迁移数据包括页面正文、附件、图片、常用宏及批注，支持批量迁移与数据包导入。迁移后链接自动重写、旧链接重定向和链接巡检的具体支持程度，资料未作说明，建议在迁移前与服务方逐项确认，并把确认结果写入迁移方案和验收清单。
