Confluence 页面迁移完成后，如果同时出现附件缺失、链接失效和权限错配，建议按“先定范围与批次，再查附件，再查链接，最后查权限”的顺序推进。附件是页面正文中图片和下载链接的实体来源，先确认附件落地情况，可以避免把附件缺失引起的链接打不开误判为独立故障；链接依赖页面标识、标题和附件地址，等对象状态稳定后再校验，结论才可靠；权限调整常涉及批量授权，放在对象关系确定后进行，能减少返工。每一类都先取证再动手，修复后用抽样页面验证并记录复发点。若迁移目标是 ONES Wiki，其迁移方案覆盖空间、页面、附件和权限结构，可作为对照基准。
要点总览（TL;DR）
- 三类异常并存时按“先定范围与批次，再查附件，再查链接，最后查权限”推进，附件是正文图片和下载链接的实体来源，先修附件能避免把连带失效误判为独立链接故障。
- 附件排查先建源端基准清单，再对迁移日志区分未传输、传输中断、传输成功但未挂载三种情况，最后查目标端大小限制与文件名编码等落地障碍，逐条勾销后再进入下一步。
- 链接排查按站内页面互链、锚点与标题层级、附件与图片链接、外部与跨空间链接分层校验，外部链接单独归类，避免混入迁移问题清单。
- 权限排查以源端授权清单为基准逐条比对，重点找继承关系被打破的位置，过度开放优先处理；批量调整前小范围试点并保留原授权记录。
- 修复后按页面类型、附件类型、权限层级抽样验证，把本次原因写入迁移检查清单作为下一批次预检项，并区分源端处理与目标端修复。
先分清症状：三类异常各自的表现与影响范围
“迁移出问题”是一个笼统说法，先把它拆成可分别取证的三类症状，才能确定从哪查起。三类异常的表现和第一手证据如下表。
| 异常类型 | 典型表现 | 先看哪些证据 |
|---|---|---|
| 附件缺失 | 页面在但附件列表为空；附件可下载但大小异常；部分页面附件齐全、部分缺失 | 源端页面附件列表、导出清单、迁移日志中的失败记录 |
| 链接失效 | 站内页面链接跳转 404；锚点定位错位；指向附件或图片的链接打不开 | 失效链接清单、目标页面是否存在、附件落地结果 |
| 权限错配 | 原可见页面迁移后无权访问；原受限页面迁移后过度开放；继承权限与单独授权混乱 | 源端空间与页面授权清单、目标端授权设置 |
圈定影响范围时，用三个维度交叉判断：迁移批次（同一批次集中出问题，多为传输或工具环节；零散出现，多为个别页面对象问题）、页面空间（单空间异常还是多空间异常）、页面层级（顶层页面正常而子页面异常，往往指向继承关系或批量处理）。三个维度组合后，通常能判断是全局性失败还是局部遗漏，这决定了后续是整批重迁还是逐页修补。
排查顺序的依据：为什么先附件、再链接、后权限
这个顺序来自三类对象之间的依赖关系，而非习惯排序。附件是页面内容的实体对象，正文中的图片和下载入口都指向它；附件没有落地，相关链接自然打不开。先修附件，可以避免把这类连带失效当成独立的链接故障去查，省掉一轮无效定位。
链接依赖页面标识、标题、锚点和附件地址。页面是否迁移完整、标题是否被改写、附件是否到位，都会改变链接校验的结果。在页面与附件状态稳定之前校验链接，修完附件后往往要重新校验一遍，前面的结论作废。
权限调整通常涉及重新授权或批量同步，动作影响面大、回退成本高。等页面和附件的关系确定后再调权限，可以避免“刚授完权、对象又被重建”造成的返工。批量改权限前保留原授权记录，是这一顺序能安全落地的前提。
每一类问题都按“先假设、再取证”的方式推进：列出可能原因（未传输、传输中断、传输成功但未挂载、页面标识变化、继承关系被打破等），再用迁移日志、导出清单和抽样页面逐项验证，确认一条排除一条，不把猜测直接写成结论。
第一步查附件：从导出清单到目标端落地逐项比对
附件排查的目标是回答两个问题：缺了哪些，缺在哪一环。做法是先建基准，再对日志，最后查落地障碍。
- 建立基准清单。从源端导出页面附件列表，逐条记录文件名、大小、版本和所属页面。这份清单是后续所有比对的依据，缺失判断以它为准，不以记忆或印象为准。
- 核对迁移日志与失败记录。把缺失项与日志对照，区分三种情况：未传输（日志中无记录）、传输中断（有开始无完成）、传输成功但未挂载到页面（日志显示完成、页面附件列表为空）。三种情况的处理方式不同，混在一起会导致盲目重传。
- 检查目标端落地障碍。确认目标端是否存在附件大小限制、文件名编码或特殊字符处理问题。这类障碍常表现为“传输成功但页面看不到”或“能下载但大小异常”，需要结合目标平台的实际限制确认。
- 按批次补迁。对确认缺失的附件按批次重传或补迁。重传前保留源端原件，避免覆盖目标端已有的正确版本；补迁完成后回到基准清单逐条勾销，形成闭环。
停止点是：基准清单中每一项都有明确结论（已到位、已补迁、确认源端即缺失），再进入链接排查。若迁移目标是 ONES Wiki，其迁移范围包含页面正文、附件、图片、常用宏及批注，可用迁移结果与源端清单做同样的逐项比对；具体失败日志字段和附件大小限制以实际迁移工具输出和平台说明为准。
第二步查链接：按页面链接、锚点、附件链接分层校验
附件状态确定后，链接排查按依赖层次从粗到细推进，每一层单独归类，避免把不同原因的失效混成一个清单。
| 链接类型 | 校验要点 | 常见原因与修复动作 |
|---|---|---|
| 站内页面互链 | 目标页面是否已迁移、页面标识是否变化、标题是否被改写 | 目标页缺失则补迁；标识或标题变化则按映射关系批量替换链接 |
| 锚点与标题层级链接 | 迁移后标题结构是否保留、锚点是否仍指向原位置 | 标题层级被调整则重建锚点或修正链接指向 |
| 附件与图片链接 | 与第一步附件落地结果逐条对照 | 附件未到位则回到补迁；附件到位但链接失效则修正链接地址 |
| 外部链接与跨空间链接 | 单独归类，确认是否属于迁移导致 | 外部站点自身失效与迁移无关，不混入迁移问题清单 |
分层校验的顺序有实际意义：页面互链的结论会影响锚点校验的范围，附件链接的结论直接引用第一步的结果。把外部链接和跨空间链接单独归类，是为了防止把与迁移无关的失效算进修复工作量，干扰对迁移质量的判断。每层校验完成后记录失效数量和修复方式，作为后续验证抽样的依据。
第三步查权限：对照源端授权结构重建访问关系
权限错配的定位方法是对照，而不是凭感觉逐个页面试。以源端空间或页面的授权清单为基准，逐条记录用户、用户组和权限级别，再与目标端实际授权比对，差异项就是需要处理的对象。
比对时重点看继承关系：目标端页面是继承父级权限还是单独授权，继承关系在哪个层级被打破。常见情况是迁移后子页面被设为单独授权，切断了与父级的继承，导致原可见用户无权访问，或原受限内容对外可见。找到继承被打破的位置，往往能一次修正一批页面。
两类风险的处理优先级不同。“过度开放”意味着原受限内容被更多人看到，属于需要优先处理的风险；“无权访问”影响使用但不扩大暴露面，可在过度开放处理完后跟进。批量调整前先做两件事：小范围试点，确认调整后的授权效果符合预期；保留原授权记录，明确回退方式。停止点是试点页面的授权与源端清单一致，再推广到整批。
若迁移目标是 ONES Wiki，其 Confluence 数据迁移范围包括用户、用户组、空间权限与页面权限，可作为重建授权关系的对照基础；继承关系的具体重建方式以实际迁移结果和平台授权设置为准。
修复后的验证与复发预防
修复完成不等于问题关闭，验证要覆盖三类对象并形成抽样方案。按页面类型（顶层页、子页、含大量附件的页）、附件类型（图片、文档、大文件）、权限层级（空间级、页面级、单独授权页）分别抽样，确认附件可正常下载且大小正确、各类链接可跳转且锚点定位准确、权限与源端清单一致。抽样中发现的新问题回到对应步骤处理，不跳步修补。
把本次问题的原因写入迁移检查清单，作为下一批次的预检项，是防止复发的直接手段。清单至少包含：附件基准清单是否建立并逐条勾销、链接分层校验是否完成、权限对照是否覆盖继承关系、批量操作是否留有备份和回退方式。同时明确迁移日志的保留周期和责任人，复发时能快速调取记录定位。
最后区分问题的处理位置：源端本身缺失的附件、源端即已失效的外部链接，回到源端确认或记录豁免；页面标识变化、锚点错位、继承关系被打破，在目标端修复。把这两类分开记录，下一批迁移的范围评估和验收标准才有可靠依据。对于采用 ONES 迁移方案的项目，官方建议把迁移工具、原厂服务和分阶段切换结合起来，并在正式迁移前确认数据范围与功能匹配，这些做法同样适用于把本次排查结论固化为下一批次的预检规则。
常见问题
迁移批次里只有个别页面附件缺失，还需要整批重迁吗？
通常不需要。个别页面缺失、同批次其他页面附件齐全，更可能是个别页面对象在传输或挂载环节出了问题，而不是整批传输失败。做法是先用源端基准清单确认缺了哪些，再对迁移日志看这些附件是未传输、传输中断还是传输成功但未挂载，按批次补迁缺失项即可。整批重迁适用于同一批次集中出现大量缺失、且日志显示传输环节整体异常的情况；重迁前保留源端原件，避免覆盖目标端已有的正确版本。
附件补迁完成后，之前判定失效的链接会自动恢复吗？
指向附件和图片的链接在附件重新落地后通常可以恢复，但需要重新校验确认，不能默认恢复。站内页面互链和锚点链接与附件无关，附件补迁不会改变它们的失效状态。建议在附件逐条勾销后，按链接分层表重新跑一遍校验：先看附件与图片链接是否已可打开，再核对页面互链与锚点。若附件已到位但链接仍打不开，说明问题在链接地址本身，需要按映射关系修正链接，而不是继续补迁附件。
权限错配里“无权访问”和“过度开放”应该先处理哪个？
优先处理过度开放。原受限页面迁移后对更多人可见，属于暴露面扩大，拖延处理的风险高于暂时无法访问。无权访问影响使用但不扩大暴露范围，可以在过度开放处理完后跟进。两类问题都建议先对照源端授权清单定位差异，找到继承关系被打破的层级，往往能一次修正一批页面；批量调整前先小范围试点，确认授权效果符合预期，并保留原授权记录和回退方式。
源端本身就缺失的附件或已失效的外部链接，要不要算进迁移问题？
建议单独记录，不计入迁移质量判断。源端即缺失的附件、源端就已失效的外部链接，与迁移过程无关，回到源端确认或记录豁免即可；页面标识变化、锚点错位、继承关系被打破这类问题，在目标端修复。两类分开记录后，下一批迁移的范围评估和验收标准才有可靠依据，也避免把与迁移无关的失效算进修复工作量。
迁移到 ONES Wiki 时，这套排查顺序需要调整吗？
顺序可以沿用。ONES 的 Confluence 数据迁移范围包括页面正文、附件、图片、常用宏及批注，也覆盖用户、用户组、空间权限与页面权限，因此附件、链接、权限三类对象同样存在，按附件→链接→权限推进依然成立。差异在于具体取证方式：附件失败日志字段、目标端附件大小与文件名限制、页面标识与锚点的映射规则、权限继承关系的重建方式，需以实际迁移工具输出和平台说明为准。存在定制场景或插件依赖时，迁移前应逐项评估，避免假设所有插件都能一一对应。
