Jira 迁移后发现附件丢失，先别急着重导整个项目。多数情况出在三个环节：导出包没有带上附件文件、源端附件存储方式导致文件未随数据搬走、导入时路径或权限不匹配使文件被跳过。本文按“界定范围—验证原因—定向补齐—核验防复发”的顺序给出排查与处置路径，帮助你在不覆盖已迁移数据的前提下把附件补回来。
要点总览（TL;DR）
- 先界定丢失范围：区分附件列表为空、条目在但文件打不开、仅部分问题类型缺失三种现象，按项目、问题类型、时间范围圈定受影响集合。
- 原因排查按假设逐条验证：源端附件是否真实存在、导出包是否含附件文件、存储方式是否被迁移方案覆盖、导入日志有无跳过记录、迁移工具是否只同步了字段。
- 处置以定向补齐为主，整体重导会覆盖迁移后新产生的数据；操作前备份目标端并设定回滚点与停止条件。
- 恢复后按项目与问题类型分层抽样，核对附件数量、文件名与可下载性，并把附件核验写成迁移验收的阻断项。
先界定丢失范围：哪些附件、丢在哪一步
“附件丢失”是一个笼统描述，不同现象指向的断点并不相同。排查第一步是把现象拆开，用可观察的事实替代“附件没了”的判断。
区分三种现象
- 附件列表为空：问题详情页看不到任何附件条目。通常指向附件记录未导入，或导入时附件字段被跳过。
- 附件条目在但文件打不开：能看到文件名，点击下载报错或得到空文件。通常指向文件本体未落到目标端存储，或路径映射错误。
- 仅部分问题类型缺附件：某些项目或问题类型正常，另一些缺失。通常指向导出范围、字段配置或权限差异。
圈定受影响集合
按项目、问题类型、时间范围三个维度圈定范围。例如“项目 A 的缺陷类型、2023 年之后创建的问题全部无附件”，这样的描述才能支撑后续比对。同时记录迁移方式：是 Jira 原生导出再导入、通过 API 同步，还是使用第三方迁移工具。迁移方式决定了链路上可能存在的断点位置——导出导入要看导出包，API 同步要看接口是否请求了附件字段，第三方工具要看其附件同步开关与日志。
建立数量对比口径
在源端按项目统计附件总数与总容量，在目标端用同样口径统计。两边口径要一致：是否包含已删除问题的附件、是否按最新版本附件计数、是否统计内嵌图片。口径不一致会让对比结果失真，把“统计差异”误判为“丢失”。完成这一步后，你应得到一份受影响附件清单和迁移链路断点的初步判断。
原因假设与排除证据：附件为什么没跟过来
原因排查的关键是把假设和证据分开。下面五条假设覆盖了常见断点，建议按表中顺序逐条验证，前一条排除后再进入下一条，避免同时改动多个变量。
| 假设 | 验证证据 | 排除结论的判定 |
|---|---|---|
| 源端附件本身缺失或被清理 | 回源端逐条打开抽样问题的附件，确认文件可下载 | 源端可正常下载，说明问题在迁移链路而非源数据 |
| 导出包未包含附件文件 | 解压导出包，检查附件目录是否存在、文件数量与源端统计是否接近 | 包内附件目录完整且文件数匹配，可排除导出环节 |
| 附件存储方式差异导致文件未随数据迁移 | 确认源端附件存放位置：本地文件系统、对象存储还是附件存储插件；核对迁移方案是否覆盖该存储方式 | 存储方式在迁移方案覆盖范围内，且文件已实际传输，可排除 |
| 导入时路径、大小限制或权限不匹配 | 查看导入日志中的跳过记录与报错；核对目标端附件目录权限、单文件大小上限 | 日志无跳过记录且抽样文件可访问，可排除 |
| 迁移工具或脚本只同步了问题字段 | 检查工具配置中附件同步选项是否启用；对比字段同步与附件同步的执行记录 | 附件同步选项已启用且有执行记录，可排除 |
验证时优先使用抽样法：从受影响集合中抽取 10 到 20 条问题，覆盖不同问题类型和附件大小区间。抽样全部指向同一断点时，再对该断点做全量核查。需要提醒的是，附件存储方式差异是最容易被忽略的一条：源端使用本地文件存储时，附件以文件形式散落在服务器目录中，若迁移只搬运了数据库记录，文件本体就留在了原服务器；使用对象存储或附件插件时，文件位置与访问方式又不同，迁移方案需要明确覆盖对应存储类型。具体到你所用的迁移工具是否支持某种存储方式，应以工具文档或厂商确认为准。
按范围处置：补齐附件而不是整体重导
处置的基本原则是定向补齐。整体重导会覆盖目标端已经正确迁移的数据，包括迁移后新产生的问题、评论和状态变更，风险远大于收益。下面按丢失范围给出处置路径。
全部附件丢失
这种情况通常指向导出包或存储配置的系统性问题。先修正导出配置或存储映射，再按项目分批重导。分批的意义在于控制影响面：第一批选一个附件量小的项目验证链路，确认附件能正常落地后，再推进其余项目。重导前必须备份目标端现有数据，并明确回滚点——即出现异常时恢复到哪个时间点的状态。
部分附件丢失
按受影响问题清单定向补传或补导。补传适合数量较少、可人工定位的场景；补导适合按项目或问题类型批量缺失的场景。操作时只针对清单内的问题执行，导入工具若支持按问题键过滤，应使用过滤条件限定范围，避免全量覆盖。补传完成后立即在目标端抽查，确认附件条目与文件均可访问。
附件条目在但文件不可访问
这类现象的重点在目标端存储配置。核查附件目录的读写权限、存储路径映射是否与实际存放位置一致、文件是否完整传输（对比文件大小）。若文件大小为零或明显小于源端，说明传输中断，需要重新传输该批文件。权限问题修复后，通常无需重新导入记录，文件即可恢复访问。
设置停止条件
处置过程中设定明确的停止条件：连续抽样 10 条以上仍出现附件不匹配，或补导后目标端出现数据覆盖迹象，应立即暂停操作，回到原因排查环节重新验证假设。带着未确认的原因继续批量操作，只会扩大需要回滚的范围。
验证恢复与防复发：用抽样和清单确认附件到位
附件补齐后，验证要回答两个问题：数量对不对、文件能不能用。两者缺一不可——数量一致但文件损坏，或文件可下载但大量缺失，都属于未恢复完成。
分层抽样核验
按项目与问题类型分层抽样，每个分层抽取若干问题，逐条比对附件数量、文件名、文件大小与可下载性。抽样应覆盖大文件、多附件问题、含内嵌图片的问题等边界情况。抽样通过后，再核对附件总容量与文件数是否与源端一致，作为整体完整性的佐证。
纳入迁移验收清单
把附件核验写成清单条目，作为切换前的阻断项：附件总数与源端差异在约定范围内、抽样问题附件全部可下载、附件目录权限配置正确、导入日志无未处理的跳过记录。任一条不满足，切换不通过。这样附件完整性就不再依赖个人记忆，而是验收流程中的固定检查点。
记录断点并更新操作手册
把本次断点的具体原因、验证证据和修复动作记录到迁移操作手册中，更新附件检查步骤。下一次迁移或增量同步时，按更新后的步骤执行，同类问题就能在导出前被拦截。
在工具承载层面，ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录的迁移，迁移问题数据时包含属性和属性值、附件、评论等信息，可作为附件核验与迁移验收的管理载体。ONES 也将数据完整、业务连续和系统稳定作为迁移目标，建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。附件核验清单可以直接落到迁移验收流程中，与分批切换的节奏配合使用。不同附件存储方式在具体迁移项目中的处理方式，建议在实施前与迁移服务方确认。
常见问题
源端和目标端的附件统计口径不一致，怎么判断是不是真的丢了？
先统一口径再对比。需要确认三件事：是否统计已删除问题的附件、是否按最新版本附件计数、是否包含内嵌图片。两边用同一口径重新统计后，如果数量与容量接近，说明差异来自统计方式而非丢失；如果目标端明显偏少，再按项目与问题类型缩小范围，进入逐条抽样核对。
附件条目能看到但下载报错，需要重新导入问题记录吗？
通常不需要。这类现象指向文件本体没有落到目标端存储，或存储路径映射与实际存放位置不一致。先核查目标端附件目录的读写权限、路径映射和文件大小：文件大小为零或明显小于源端，说明传输中断，重新传输该批文件即可；权限修复后，文件一般可直接恢复访问，问题记录无需重导。
只补一部分附件，会不会覆盖迁移后新产生的问题和评论？
取决于补导方式。使用导入工具时，若支持按问题键过滤，应限定在受影响清单范围内执行，避免全量覆盖。补传方式只新增附件文件，对已有问题字段影响较小。无论哪种方式，操作前都应备份目标端现有数据并明确回滚点，补导后立即抽查，确认没有出现数据被覆盖的迹象。
迁移工具声称支持附件迁移，为什么还是丢了？
“支持附件迁移”通常指功能存在，实际是否生效要看配置与执行记录。需要确认附件同步选项是否启用、执行日志中附件环节是否成功、源端附件存储方式是否在工具覆盖范围内。源端使用本地文件存储时，附件以文件形式散落在服务器目录，若迁移只搬运数据库记录，文件本体就留在原服务器。具体存储类型的处理方式，应以工具文档或厂商确认为准。
附件核验应该放在迁移流程的哪个节点？
放在切换前的验收环节，作为阻断项。核验内容包括：附件总数与源端差异在约定范围内、分层抽样的问题附件全部可下载、附件目录权限配置正确、导入日志无未处理的跳过记录。任一条不满足则切换不通过。把核验写进验收清单，附件完整性就不再依赖个人记忆，而是流程中的固定检查点。
