科技 · 实用指南
Immich 下载 Live Photo 后只剩静态图：改标识前先检查什么
远端能播放、文件标识一致、保存出一张照片，分别证明不同的事。先检查两份原始资源和“照片”里的恢复结果，再判断备份是否真的还原。
如果 Live Photo（实况照片）在 Immich 中能播放动态，但新存入 Apple“照片”的项目只是静态图，就还不能确认实况照片已恢复。保留原文件，先确认静态照片和配套视频都在，检查真实文件类型及相关标识，再到“照片”中验证恢复出的项目。修改 UUID 不应是第一步。
这些检查必须分开，有明确的代码依据：我们查看的 Immich v3.2.1 和 v3.3.5 移动端保存服务中，某个 Photos 错误分支会尝试只保存静态图，并以返回的静态资源是否非空判断成功。这证明源码存在降级保存路径，并不证明你的问题由此引起，也不表示每一种完成提示都来自该返回值。
服务器关联、两份文件和恢复出的实况照片，是三种证据
Immich 可以把照片与视频关联，并在自己的查看器中播放动态。这回答的是服务器上的关联问题；下载后有两份文件，回答的是资源是否保留下来；新项目能否在 Apple“照片”中作为实况照片播放，才回答你关心的恢复问题。不能把前一项观察结果直接当作后一项的证明。
Apple 文档说明，视频的内容标识会与对应静态照片 Exif MakerNote 中的元数据关联。Immich 自己的链接则是数据库关系。因此，在 Immich 中重新关联两项资源，本身不能证明文件内嵌的 Apple 元数据已经改变，更不能证明“照片”会接受这对文件。
保留原始资源，并记录出现问题的下载方式
从自己的存档或原文件下载中取得静态照片及其配套视频，只在副本上操作，并把两者放在独立文件夹中。如果导出只得到静态图，应先找回对应的原始视频；截图、预览图或把文件改名为 .MOV，都不能补回缺失的动态内容。不要直接修改 Immich 管理的存储目录来试验修复。
记录 Immich 服务器版本、移动应用版本、iOS 版本，以及结果来自移动端“保存”、网页下载还是其他导出方式。还要注明来源是 Apple 实况照片还是 Android 动态照片。本指南检查的是 Apple 实况照片的恢复问题，不保证跨平台动态照片转换成功。
只读取文件类型和标识分组，不写入元数据
安装 ExifTool 后，先运行 `exiftool -ver`，再运行 `exiftool -a -G1 -s -FileType -ContentIdentifier "photo.JPG" "photo.MOV"`，把引号中的两个路径替换为副本路径。这些选项只读取元数据。保留输出中的文件边界和分组名称；文件名以 .MOV 结尾，不能代替实际文件类型检查。
在我们检查的 iPhone 样本中，静态照片显示 [Apple] ContentIdentifier，视频显示 [Keys] ContentIdentifier。比较这两个值，不要因为外观相似，就拿 ImageUniqueID、文件名里的 UUID 或无关的 XMP 值代替。如果某个分组缺失、多项数值冲突，或工具无法读取文件，应如实记录不确定性，不要判定配对有效。
两组真实故障样本说明，单一元数据配方并不够
我们使用 ExifTool 13.59，只读检查了 Immich 问题 14066 和 15805 所附的公开 JPEG/MOV 压缩包。两组都含有一张 JPEG 和一个 MOV；第一组的 Apple/Keys 内容标识不同，第二组相同。读取前后的 SHA-256 检查确认，四个文件的内容都没有改变。
这些结果只说明所提供文件的元数据情况，不能诊断原先的故障。问题 14066 还包含缺少任务记录的错误；问题 15805 则被后续修正视频下载 URL 的补丁明确列为修复对象。我们没有执行 iOS 或 macOS 恢复测试，而且服务器导出的一对文件正确，也不能证明早期移动端实际下载了哪些字节。
根据已有证据决定下一步
如果视频缺失、无法读取，或者实际又是一张图片，应先取回正确的原始资源，再考虑配对。如果相关标识缺失或不同，应回到来源存档及导出历史，确认哪张照片与哪个视频原本属于同一组。相同主文件名或接近的拍摄时间只是线索，不能据此随意选取文件并覆盖标识。
如果相关标识已经相同，就不要继续把替换 UUID 当成通用修复。保留这对文件，转而检查资源交付和写入“照片”的路径。现有修复工具可以在文件间复制标识，但不能据此认证视频、其余元数据或 Apple 的接受结果。标识一致却恢复失败，意味着需要更好的诊断证据，而不是反复写入同一个值。
把历史客户端修复与静态图降级保存分开看
这里有两个已存在的客户端修复值得区分：PR22708 修正了视频请求误用静态照片 URL 的问题；PR29952 修正了已完成实况照片下载任务的分组及回调交互。这说明资源交付故障可以独立于原文件的标识问题存在。任何一个补丁都不能证明后来所有“只剩静态图”报告的原因。
所查 v3.2.1/v3.3.5 保存代码仍会捕获错误码以 PHPhotosErrorDomain 开头的异常，尝试调用 saveImageWithFile，并返回静态图保存是否得到资源。我们没有把这个布尔值追踪到每一种界面状态。可靠结论应限定为：传输进度和已保存的静态图，都不足以证明完整实况照片已恢复。先记录版本，再在受支持的更新后用保留好原件的单个样本复测，不要盲目套用旧补丁。
到 Apple“照片”中验证这次新恢复的项目
检查这次恢复创建的项目，不要误看图库里原本就正常的旧副本。Apple 当前的 iPhone 指引为“照片”→“精选集”→“媒体类型”→“实况照片”；打开项目后按住屏幕播放。如果“照片”仍提供实况控制项，应先确认实况效果是否被关闭，再判断动态内容是否缺失。
一个能单独播放的 MOV 是值得保留的资源，但不能证明“照片”已经把它还原成一项实况照片。目标设备及预期流程通过验证前，继续保存原文件。不要为了造出干净测试环境而删掉唯一正常的副本；可以使用原资源已另行保存的现有失败样本，或条件允许时使用独立测试目标。
记录恢复结果，避免夸大成功范围
对测试样本，保留版本、导出方式、两份文件的类型、相关标识是否一致，以及“照片”的实际播放结果。有效的支持报告可以明确区分“原始视频缺失”“两份资源都保留，但恢复尚未确认”和“已在这台设备上恢复并播放”。若出现错误，应附上准确错误内容；没有报错并不能自动证明保存成了实况照片。
这套流程帮助缩小下一步判断范围，不能找回已经不存在的视频帧，也不能认证所有标识一致的文件对。实际目标是得到诚实的恢复结论，并保住来源资源。仅凭服务器能播放动态，不应丢弃仍需恢复的实况照片剩余副本。
