从 Confluence 迁出后出现知识查找变慢、权限边界混乱或协作断点，通常源于迁移过程中的字段映射、权限结构和协作痕迹没有完整重建，新平台本身的能力往往不是主因。定位时先固定一批可复现的症状样本，再分别核对数据、索引、权限继承和协作记录，用证据把“迁移遗漏”“规则未重建”“使用习惯未切换”三类原因分开，最后决定补数据、补权限模型还是补协作流程。
要点总览（TL;DR）
- 迁出后查找慢、权限乱、协作断点，通常来自迁移时字段映射、权限继承和协作痕迹未完整重建，先固定症状样本再排查。
- 查找类问题先核对迁移日志与字段映射，区分数据缺失与索引覆盖不足；权限类用测试账号验证空间与页面继承；协作类抽查评论、提及、通知与负责人。
- 排查顺序为样本复现、核对迁移记录、测试账号验证权限、抽查协作痕迹；重跑迁移、批量改权限、重建索引前必须备份并设停止点。
- 修复后用同一批样本复测，验收标准为查找异常清零、越权与缺权样本清零、协作断点有明确处理结果。
- 把根因结论回写到迁移验收清单、权限模型文档和页面负责人规则，防止后续迁移或日常使用中复发。
先分清三类症状：查找、权限、协作各自的表现与范围
迁出后的“不好用”往往是一句笼统感受，直接全量排查会耗费大量时间且难以收敛。更有效的做法是把症状拆成可观察、可统计的条目，用一份样本清单圈定排查范围。样本建议覆盖页面、空间、人员和时间四个维度，每类症状取 10 到 20 个具体案例即可，不必一开始就全量扫描。
知识查找效率下降的表现
- 搜不到：明明记得存在的页面，用标题关键词或正文关键词都检索不到。
- 搜到旧版：搜索结果指向迁移前的历史版本，或同一主题出现多个重复页面。
- 找不到附件：页面正文在，但附件、图片缺失或无法打开。
- 跨空间检索缺失：原来在 Confluence 中能一次搜到多个空间的内容，现在只能逐个空间翻找。
权限边界不清的表现
- 不该看的人能看到：原本限定在某个空间或页面的敏感内容，迁移后对更大范围可见。
- 该看的人看不到：原本有访问权限的成员，迁移后需要重新申请。
- 权限申请变多：服务台或管理员收到的访问申请数量明显上升，说明原有权限关系没有延续。
协作断点的表现
- 评论与 @提及丢失：页面正文迁移过来了，但围绕页面的讨论记录不见了。
- 页面无人认领：原来有明确负责人的页面，迁移后没有责任人，更新停滞。
- 评审与交接脱节：依赖页面评论或任务链接推进的评审流程，在新环境中找不到触发点。
把上述表现逐条填入样本清单，记录页面地址、所属空间、涉及人员、首次发现时间，就得到了一份可用于复现和对比的问题底稿。清单之外的现象暂不纳入本轮排查，避免范围失控。
三类症状的常见原因假设与排除证据
症状清单确定后，下一步是为每类症状列出候选原因，并为每个原因准备可验证的证据。这里的关键是把假设和结论分开：在证据出现之前，任何原因都只是待排除项。下表按症状类别整理常见假设、验证证据和建议的排除顺序。
| 症状类别 | 候选原因 | 验证证据 | 排除顺序 |
|---|---|---|---|
| 知识查找 | 迁移字段缺失（标题、正文、标签、别名未完整迁移） | 对照迁移日志与字段映射表，抽查样本页面的字段完整性 | 1 |
| 知识查找 | 搜索索引未重建或覆盖范围不足 | 用同一关键词在新旧环境分别检索，比较命中结果；确认索引覆盖的空间与内容类型 | 2 |
| 知识查找 | 标签与别名丢失导致检索词对不上 | 抽查原页面标签、别名是否在新页面中存在 | 3 |
| 知识查找 | 旧链接失效，用户仍按旧路径访问 | 收集用户反馈的失效链接，检查是否配置了跳转或重定向 | 4 |
| 权限边界 | 空间权限被压平为统一可见 | 用测试账号对比迁移前后同一空间的可见范围 | 1 |
| 权限边界 | 继承层级未重建，页面权限与空间权限脱节 | 抽查子页面的权限设置，验证是否按预期继承父级 | 2 |
| 权限边界 | 外部协作账号与内部账号混用 | 核对账号清单，确认外部账号的可见范围是否符合约定 | 3 |
| 协作断点 | 评论与提及未随页面迁移 | 抽查样本页面的评论记录与 @提及，与迁移前截图或导出对照 | 1 |
| 协作断点 | 通知规则未配置，讨论无法触达相关人 | 检查新环境的通知设置，验证评论或更新是否触发提醒 | 2 |
| 协作断点 | 页面负责人与评审流程未定义 | 抽查页面是否标注负责人，评审是否有明确的发起与确认环节 | 3 |
排除顺序遵循“先查数据完整性、再查规则配置、最后查使用习惯”的原则。数据缺失和索引问题属于迁移层面的客观事实，验证成本低、结论明确；权限继承和通知规则属于配置层面，需要测试账号配合；使用习惯问题则要在前两类排除之后才能确认，否则容易把迁移遗漏误判为用户不适应。
三类根因的区分标准可以这样把握：迁移遗漏表现为新旧环境数据本身不一致，同一份内容在两边对不上；规则未重建表现为数据在但关系断了，比如页面存在而权限继承失效、评论存在而通知不触发；使用习惯未切换表现为数据和规则都正常，只是用户仍按旧路径操作，比如继续使用旧链接或旧搜索方式。三者可能同时存在，排查时按样本逐条归类，不要用一个结论覆盖全部症状。
按症状走排查路径：从样本复现到根因确认
排查路径的设计原则是先做低风险核对，再动数据；每一步都有明确的输入、操作和判定标准，出现异常即停止并回退。以下四步按顺序执行，前一步结论不明确时不进入下一步。
第一步：在新旧环境用同一批样本复现
输入是 S1 形成的样本清单。操作是在旧环境（如仍可访问的 Confluence 只读实例或导出包）和新环境中，用相同的关键词、相同的账号、相同的访问路径逐一复现，记录检索结果、可见范围和协作记录的差异。判定标准是每个样本都能明确归入“一致”或“不一致”，不一致的样本标注差异类型。这一步只记录、不修改任何数据。
第二步：核对迁移日志与字段映射
输入是迁移日志、字段映射表和第一步标记为“查找类不一致”的样本。操作是逐项核对标题、正文、附件、标签、别名是否按映射规则写入新环境，区分“数据未写入”和“数据已写入但检索不到”。判定标准是能明确回答每个样本属于数据缺失还是索引问题。若确认是数据缺失，记录缺失字段和影响范围，作为补迁依据；若数据完整但检索不到，转入索引覆盖范围的核查。
第三步：用测试账号验证权限继承与可见范围
输入是权限类样本和一组测试账号，测试账号应覆盖空间管理员、普通成员、外部协作人员等典型角色。操作是用每个测试账号访问样本页面，记录实际可见范围，并与迁移前的权限记录对照；同时抽查子页面，验证是否按预期继承父级权限。判定标准是能区分“权限被压平”“继承未重建”“账号混用”三种情况。这一步只读验证，不批量调整权限。
第四步：抽查协作痕迹是否随页面迁移
输入是协作类样本。操作是逐页检查评论、@提及、页面关注、任务链接是否存在，通知规则是否对相关角色生效，页面是否有明确负责人。判定标准是每个协作断点都能对应到“痕迹未迁移”“通知未配置”“负责人未定义”中的一类。
破坏性操作的条件与停止点
排查过程中可能涉及重跑迁移、批量修改权限、重建索引三类操作，执行前需要满足共同条件：已完成样本复现并形成书面结论、已对当前数据和权限配置做完整备份、已约定回退方式和责任人。执行时设定停止点，例如批量改权限前先在小范围空间试运行并抽检结果，重建索引期间观察检索可用性，一旦出现超出预期的可见范围变化或数据异常，立即停止并回退到备份状态。没有备份和回退方案时，不执行这三类操作。
在采用 ONES 迁移方案的场景中，排查可以借助迁移侧已有的记录：ONES 的 Confluence 迁移支持将空间、页面、附件和权限结构迁入 ONES Wiki，迁移数据包括用户、用户组、空间权限与页面权限，页面正文、附件、图片、常用宏及批注也在迁移范围内。这些记录可以作为第二步和第三步的对照依据，帮助判断某个样本属于迁移遗漏还是规则未重建。对于存在插件或定制场景的页面，迁移前需逐项评估，排查时也应把这类页面单独列出，避免把定制功能的差异误判为数据丢失。
修复后的验证与复发预防
根因确认并完成补数据、补权限或补流程之后，验证要回到最初那批样本，用同一口径复测，确认症状确实消失，而不是被新的问题掩盖。
验证方式与验收标准
- 样本复测：用 S1 的样本清单在新环境重新执行检索、访问和协作检查，逐条标记“已恢复”或“仍异常”。
- 权限抽检：用测试账号重新验证空间与页面可见范围，确认越权样本和缺权样本均已清零；抽检范围应覆盖迁移时调整过权限的空间。
- 协作断点回访：向涉及交接和评审的成员确认评论、提及、通知和负责人机制是否恢复可用，交接链路能否追溯到具体页面和责任人。
- 查找命中验证：对查找类样本设定可核对的命中标准，例如样本页面能通过标题关键词和正文关键词检索到，附件可正常打开，跨空间检索能返回预期结果。
验收标准建议写成可勾选的条目：样本清单中查找类异常清零、权限类越权与缺权样本清零、协作类断点均有明确处理结果。未达到标准的条目回到 S3 对应步骤继续排查，不带着未闭环的问题进入日常使用。
复发预防机制
- 迁移验收清单：把本次排查中发现的字段映射、权限继承、协作痕迹检查项固化为验收条目，后续迁移或增量导入按清单逐项确认。
- 权限模型文档化：记录空间权限、页面权限与继承关系的设计规则，明确哪些内容对外部账号可见，避免下次迁移时再次被压平。
- 页面负责人与评审规则：为关键页面指定负责人，约定评审的发起、确认和归档方式，让协作有明确的触发点。
- 根因结论回写：把本次确认的根因、验证证据和处理方式回写到迁移规范中，作为下一次迁移前的检查依据。
如果组织使用 ONES 承接迁移后的知识管理，可以把上述验收条目和权限规则落到具体的工作项与文档状态中：迁移验收清单作为工作项逐条流转，权限模型文档在 Wiki 中维护并随空间权限调整同步更新，页面负责人和评审记录与页面本身关联，便于后续复查时直接追溯。这样，排查结论就不只停留在一次问题的处理上，而能成为下一次迁移和日常治理的参照。
常见问题
迁出后搜不到页面，怎么快速判断是数据没迁全还是索引没建好？
先拿一个具体页面做对照：在旧环境确认该页面存在，再在新环境用标题关键词和正文关键词分别检索。如果新环境后台能看到页面内容但检索不到，问题更可能在索引覆盖范围；如果后台也找不到页面或附件，则先核对迁移日志与字段映射，确认标题、正文、附件、标签是否按规则写入。两者都排除后，再检查用户是否仍按旧路径或旧搜索方式操作。
权限边界不清时，如何区分是迁移时权限被压平还是新平台权限模型没重建？
用一组覆盖空间管理员、普通成员和外部协作人员的测试账号，分别访问同一批样本页面，记录实际可见范围，并与迁移前的权限记录对照。如果原本限定在空间或页面的内容对更大范围可见，且子页面没有按预期继承父级权限，说明权限结构在迁移中被压平或继承关系未重建。如果可见范围与迁移前一致但用户仍申请权限，则更可能是使用习惯或账号映射问题。验证过程只读，不批量调整权限。
评论和@提及丢失导致的协作断点，排查时应该看哪些记录？
逐页抽查样本页面的评论、@提及、页面关注和任务链接是否存在，并与迁移前的截图或导出记录对照。同时检查新环境的通知规则是否对相关角色生效，页面是否标注了负责人。如果评论和提及本身缺失，属于协作痕迹未随页面迁移；如果痕迹存在但相关人收不到通知，属于通知规则未配置；如果两者都正常但交接仍脱节，则需要检查页面负责人和评审流程是否重新定义。
排查过程中哪些操作有破坏风险，执行前需要做哪些准备？
重跑迁移、批量修改权限、重建索引这三类操作会直接改变数据或可见范围，属于破坏性操作。执行前应满足三个条件：已完成样本复现并形成书面结论，已对当前数据和权限配置做完整备份，已约定回退方式和责任人。执行时设定停止点，例如批量改权限先在小范围空间试运行并抽检，重建索引期间观察检索可用性，一旦出现超出预期的可见范围变化或数据异常，立即停止并回退到备份状态。没有备份和回退方案时，不执行这三类操作。
修复后如何确认问题真正解决，而不是被新问题掩盖？
回到最初那批症状样本，用同一口径复测：查找类样本能通过标题关键词和正文关键词检索到，附件可正常打开，跨空间检索返回预期结果；权限类样本用测试账号复验，越权与缺权样本清零；协作类断点逐项回访，确认评论、提及、通知和负责人机制恢复可用。验收标准写成可勾选条目，未达到的条目回到排查步骤继续处理，不带着未闭环的问题进入日常使用。
