素材卡读完写不出文件，这种事在拍摄现场发生一次就够记一辈子。我经手过的损坏案例里，RAW 视频序列和 RSV 临时文件占了相当大的比例——前者多见于 CinemaDNG、BRAW 这类机身内录或外录格式，后者几乎全是设备在录制中途断电、拔卡、卡速跟不上时留下的半成品。这篇就把从拿到坏文件、到 Repairit 走完修复、再到 Premiere Pro 和 DaVinci Resolve 里做兼容性验证的整条链路摊开讲，包括这套流程在 RAW 和 RSV 上分别能做到哪一步、哪些情况它同样无能为力。凡是碰到素材读不出来、又不甘心直接判死刑的朋友，下面这套处理顺序基本都能照着走一遍。
1. 动手之前先分层：你的素材到底坏在哪一层
1.1 RAW 视频与 RSV 在文件结构上根本不是一类东西
很多人把 RAW 当成"一种格式"，这其实是个误解。RAW 是一类工作流的统称，落到文件上至少有三种完全不同的结构。CinemaDNG 是一个文件夹，里面是逐帧的 DNG 序列、一个独立的音频 WAV，外加一份记录帧率与时码的清单；BRAW 是单文件封装，内部有帧索引表和元数据块；某些机型的 RAW 则是分块目录加散列文件的组合。它们的共同特征是：元数据、索引与帧数据三者分离存放，每一帧相对独立。
RSV 完全是另一码事。它不是标准容器，本质是设备在录制过程中边写边占位的临时文件。文件头里通常只有一段厂商自定义的标识，后面的内容是裸码流或者非标准封装的传输流片段，没有正规的索引表，也没有完整的时长字段。换句话说，RAW 坏掉更像是"目录被撕了几页"，RSV 坏掉则是"整本书根本没装订"。
这个差别直接决定了后续的修复思路。RAW 的索引没了，码流大概率还在，重建索引就能救回来；RSV 连"这段字节对应第几帧"都得靠逐个特征码去猜，成功率天然低一个档次。所以拿到文件的第一件事不是打开软件，而是先判断它属于哪一类，再决定值不值得投入时间。
1.2 三类典型症状与它们背后的真实原因
我在排查时习惯先建一张"症状—原因—方向"的对照表，比盲目试软件高效得多：
| 症状表现 | 典型提示 | 底层原因 | 优先修复方向 |
|---|---|---|---|
| 能识别，但时长显示 0 秒或几秒 | 播放器秒退，属性里无时长 | 容器索引（moov 类结构）缺失或尾部被截断 | 索引重建，码流几乎完整 |
| 能播放，但中段花屏、马赛克、卡顿 | 播放器报解码错误后跳帧 | 某个 GOP 内的参考帧丢失，后续帧失去参考 | 重排码流，牺牲受损片段 |
| 完全无法识别，拖进软件直接报错 | 系统提示"不支持的文件格式" | 文件头全毁或前若干 KB 被覆盖 | 头部修补，或逐段扫描提取 |
| 序列中个别帧丢失 | 剪辑软件提示媒体离线 | RAW 序列中某些 DNG 帧被截断为 0 字节 | 单帧级替换或补帧 |
| 时间码跳变、音画不同步 | 播放正常但时码乱跳 | 清单文件与帧序列不匹配 | 重建清单，重算时基 |
RAW 特有的症状往往不在"能不能播"上，而在"帧序列完整性"上。CinemaDNG 少一帧，剪辑软件不一定报错，但会导致后面所有帧的时间码整体偏移，剪完导出才发现口型对不上。所以我检查 RAW 时，第一步永远是核对帧数与拍摄记录是否一致，而不是先看画面。
RSV 的症状则集中在"无结构"上。它可能被识别成某种传输流，也可能被识别成未知二进制。有些设备写出的 RSV 前半段是有效码流、后半段是无效占位，这类文件修起来最省事；有些则是头尾交替损坏，中间夹着零散的完整 GOP，这类只能做分段抢救。
1.3 为什么第一件事不是打开修复软件
我见过太多人拿到坏文件，第一反应是连着原卡反复打开各种软件试。这个动作本身就是二次损伤的主要来源。存储卡在主控异常或者闪存颗粒临界失效的状态下，每一次读取都会触发重试和擦写均衡，运气不好就把本来还能救的块彻底写坏。
正确顺序只有三步：断电、写保护、做镜像。卡从设备上拔下来之后不要再插回原设备，用读卡器接上后立刻打开写保护开关（没有开关的就用只读转接），然后用块级镜像工具把整张卡按扇区抠成一个镜像文件，后面所有操作都在镜像的副本上做。
# 逐扇区镜像，坏块跳过并记录，支持断点续传 sudo ddrescue -d -r3 /dev/sdX /data/card.img /data/card.map # 镜像完成后校验 md5sum /data/card.img-d是直接访问设备，绕过系统缓存；-r3表示对坏区重试 3 轮；最后的 map 文件是断点记录，中途断了重新执行同一条命令就能接着跑。这一步耗时取决于卡容量和坏块数量，1TB 的卡健康状态下大约两三个小时，有坏块时会明显变慢。
镜像拿到之后，用只读方式挂载，或者干脆用文件恢复工具在镜像上扫。这一层做完，后面不管用 Repairit 还是别的工具，失败了都能重来，成本只是再复制一份镜像。
2. Repairit 的修复链路：它究竟动了哪些地方
2.1 样本文件不是随便找一个就行
Repairit 修视频有一个绕不开的环节：添加样本文件。很多人卡在这一步，随便找个同格式的视频就丢进去，结果修复出来画面错乱或者干脆失败，然后判定"这软件不行"。问题多半出在样本上。
样本文件的作用，是给修复引擎提供一份"正常状态下这个文件的容器长什么样"的参照。具体包括：文件类型标识的字节布局、索引表的位置与大小、轨道数量、编码参数（profile、level、色彩空间、位深）、时间基与帧率字段、以及厂商私有元数据块的位置。修 RAW 时，这些元数据尤其关键，色彩矩阵、白平衡、LUT 标识全在里面。
所以样本的挑选标准很硬：
- 同机型、同固件版本——不同固件的私有元数据块布局可能不一样，跨版本参照会导致元数据错位；
- 同录制设置——分辨率、帧率、编码档次、色彩采样必须一致，位深不一致会让重建出来的帧头解析失败；
- 同格式同封装——CinemaDNG 找 CinemaDNG，BRAW 找 BRAW，不能拿一个转码过的 ProRes 去当样本；
- 时长足够——样本本身至少要包含若干个完整 GOP，太短的样本索引信息不全，重建出来的时长字段容易出错；
- 本身完好——拿一个"能播但花屏"的当样本，等于把坏结构复制过去。
我一般的做法是：拍摄现场每换一次设置，就让机器录一段十秒左右的"参数留档"素材，单独存一个小目录。平时觉得多余，出事的时候这十秒钟能省掉一整天的折腾。
2.2 扫描阶段到底在做什么
理解了扫描逻辑，你就能预判耗时和成功率。修复引擎处理坏文件时，大致分三段：
第一段是特征码遍历。它放弃依赖文件头，从偏移 0 开始逐字节寻找帧起始标记。H.264/H.265 的起始码是00 00 00 01，ProRes 的帧头有固定 magic，CinemaDNG 的每一帧本质上是一个 TIFF 结构，有可识别的标签序列。找到标记就记下位置，找不到就继续往后挪。
第二段是帧边界重组。把识别出来的帧起点按顺序串起来，用帧头里的长度字段或者下一个起始码的位置推算这一帧的结束点。这一步最容易出错的地方是"伪起始码"——码流内部的数据刚好凑成00 00 00 01，会被误判成新帧。引擎一般会用后续几个字节做二次校验，但不可能百分百准确，所以修复出来的文件偶尔会多出几帧乱码。
第三段是容器重建。用样本文件的结构模板，把重组好的帧按时间顺序写进新的容器里，同时补齐索引、时长、轨道描述、色彩元数据。
这解释了为什么扫描耗时是"暴力遍历"级别的。修一个 500GB 的 CinemaDNG 序列，光遍历就得按小时算，跟按索引跳转完全不是一个量级。也解释了为什么文件头全毁的情况下成功率会显著下降——头部丢失往往意味着开头的若干帧也一起没了，而很多容器的时间基定义恰恰写在开头。
2.3 快速修复与深度修复的取舍逻辑
Repairit 在视频修复上提供两个层级，界面上的叫法可能随版本变化，但逻辑一致：一层只重建容器和索引，另一层会逐帧校验、丢弃无法解码的帧、重新排列 GOP。
这里有个反直觉的结论：深度修复不是越深越好。如果损坏原因是索引丢失、码流完整，深度修复反而会把一些"看着有问题但实际能用"的帧丢掉，修完的文件时长变短，剪辑时对不上板。反过来，如果损坏原因是码流本身有大量坏帧，只做容器重建等于把坏帧原样搬进新文件，导入剪辑软件照样报错。
我的判断方法是先跑一次快速修复，导入播放器看结果：
- 时长正确、全程无花屏 → 到此为止，不用再深修；
- 时长正确、局部花屏 → 记下花屏位置，跑深度修复，对比两次结果哪段更完整；
- 时长明显偏短 → 说明帧边界识别就出了问题，深度修复值得一试；
- 完全打不开 → 大概率是结构性问题，先做头部修补再回来。
深度修复的耗时随文件大小线性增长，1TB 级别的 RAW 序列跑几个小时很正常。所以实际操作中我会先拿"受损段前后各 5 分钟"的片段做小样本试验，确认参数和样本对路，再全量跑。全量跑之前把电源、散热、磁盘空间都检查一遍，中途断电重来的代价太大。
3. 一次完整的 RAW 修复实操：从坏卡到可播放
3.1 修复前的环境准备清单
环境准备这一步经常被跳过，但它直接决定后面能不能复现问题。我固定会做这几件事：
- 镜像文件放独立磁盘，不要和系统盘、缓存盘同盘，修复过程会产生大量临时写入；
- 提前留出至少 3 倍于源文件大小的空闲空间，修复输出、转码中间文件、备份副本都要占地方；
- 关掉系统的自动索引和杀毒实时扫描，这两者会让逐字节遍历的速度掉一半以上；
- 记录源文件的完整路径、大小、修改时间、MD5 前若干位，修复前后做对比，避免张冠李戴；
- 把样本文件单独复制一份到工作目录，避免原样本在修复过程中被读取锁占用。
还有一点容易被忽略：修复输出的目录名不要带中文和空格。部分修复引擎在拼接输出路径时对非 ASCII 字符处理不稳，会出现"提示成功但找不到文件"的情况。这个坑我踩过一次，找了半小时才发现在一个乱码目录里。
3.2 参数设置的几个关键点
不同版本界面差异较大，但需要决策的项就那几个：
| 设置项 | 建议值 | 理由 |
|---|---|---|
| 输入类型 | 手动指定为对应 RAW 序列或单文件 | 自动识别在头部损坏时经常判错 |
| 样本文件 | 同机型同设置的健康素材 | 决定容器结构与元数据能否正确重建 |
| 修复层级 | 先快速，后按需深度 | 避免无谓丢帧，节省时间 |
| 输出位置 | 独立磁盘、纯英文路径 | 规避写入失败与路径解析问题 |
| 音频轨道 | 有独立音频文件时单独挂载 | RAW 的音频常常独立存放，漏挂会得到无声文件 |
| 帧率与时间基 | 与样本保持一致，不手动覆盖 | 手动改会让时间码整体偏移 |
CinemaDNG 这类序列式 RAW 有个特殊点：它本质上是"一堆图片帧 + 一份清单"。修复引擎处理时，如果只挂载了序列而漏了清单，修出来的文件可能帧率默认成 25 或者 30，跟原始拍摄的 24 对不上。这种情况不用重跑修复，直接在剪辑软件里手动指定帧率和起始时间码就能纠正，但前提是你知道原始参数——所以拍摄日志这件事，平时嫌烦，出事的时候是救命稻草。
3.3 修复结果的验收：能播放只是最低标准
修复完直接拖进播放器看一眼"能播"，是我最不建议的验收方式。RAW 素材的价值在于后期可调，一个"能播但色彩元数据全丢"的文件，在调色台上等于废片。我固定的验收清单是这样的：
- 时长核对：与拍摄记录、场记单上的时长逐条比对，误差超过一帧就要查原因；
- 帧数核对：CinemaDNG 直接数目录下的 DNG 文件个数，跟预期帧数对照；
- 逐段拖动：从头到尾快速拖一遍，重点看镜头运动快的地方和场景切换点，这两处最容易暴露丢帧；
- 音频波形：把音频单独导入看波形，有没有中断、有没有整体偏移；
- 时间码连续性：在剪辑软件里看时码显示，跳变说明清单重建有问题；
- 色彩对照：同一场景找一段未损坏的素材并排比，看白平衡、色彩矩阵有没有整体偏移；
- 首尾帧检查：开头和结尾的若干帧最容易在修复中被丢弃，要单独确认。
第 6 条最容易被跳过，但对 RAW 工作流来说恰恰最关键。我遇到过一次，修复出来的 BRAW 文件能播、时长也对，但整段素材偏绿，原因是修复时元数据块里的白平衡参数被重置成了默认值。这种问题在播放器里不明显，一进调色软件就暴露了，那时候再回头重修，前面的剪辑全白做。
4. RSV 临时文件的抢救路径：没有结构怎么重建
4.1 RSV 为什么天生难修
RSV 的难点在于它压根不是给人用的格式。设备在录制时创建这个文件，本意是"先占位、录完再转正"，中途断电或者异常退出，文件就停在了半成品状态。它可能缺尾部、可能缺头部、可能中间还有一段全零的预分配空间。
这就带来三个具体问题。第一，没有可靠的时长字段，播放器无法计算总长，很多软件直接拒绝加载。第二，没有索引表，随机跳转无从谈起，只能顺序解码。第三，码流可能不是从帧边界开始的，断电瞬间正在写入的那一帧是残缺的，从它开始的解码全是乱码。
所以修 RSV 的目标要现实一点：不是"完美还原"，而是"尽可能多地抢救出可用的连续片段"。指望修出一个时长完整、时码准确的文件，基本不现实。
4.2 先判断它是不是伪装的传输流
动手之前先做个十六进制勘察，这一步能省掉大量无用功：
# 看前 512 字节的文件头特征 xxd -l 512 damaged.rsv # 全文件搜索常见的传输流同步字节 grep -abo $'\x47' damaged.rsv | head -20 # 统计零字节占比，判断预分配空间大小 python3 -c " data = open('damaged.rsv','rb').read() print('总大小:', len(data)) print('零字节占比: %.1f%%' % (data.count(0)/len(data)*100)) "判断依据很直接：如果文件里大量出现间隔 188 字节的0x47，那它大概率是非标准封装的传输流，可以用重封装工具直接处理；如果零字节占比超过三成，说明后半段全是预分配的空洞，实际有效数据只有前面一截，修复目标就锁定在那一截；如果通篇找不到任何周期性同步字节，那基本是厂商私有封装，只能走特征码扫描这条路。
我处理过的 RSV 里，传输流变体占了一多半。这类文件的修复思路和 RAW 完全不同——不需要逐帧重组，只需要把有效的传输包按顺序提取出来、重新封装成标准容器。用 ffmpeg 就能做，而且可以反复试不同参数：
# 强制按传输流解析，忽略头部错误，尽量多读 ffmpeg -err_detect ignore_err -fflags +genpts \ -i damaged.rsv -c copy -bsf:a aac_adtstoasc \ salvaged.mp4 2> salvage.log # 只看能解出多少有效帧，不实际输出 ffprobe -v error -count_frames -select_streams v:0 \ -show_entries stream=nb_read_frames -of csv damaged.rsv-err_detect ignore_err是让它遇到坏包继续往下走而不是直接退出，+genpts是强制重新生成时间戳——原始时间戳在断电文件里基本是乱的，不重建的话输出文件会时长为零。跑完之后看日志里的frame=计数，就知道抢救回来多少。
4.3 头部修补与分段截断的组合拳
对于头部被截断的 RSV，我的常规做法是"嫁接"：找一个同设备录制的健康文件，把它前面若干字节的文件头复制过来，覆盖到损坏文件的开头，然后再尝试解析。
# 用健康文件的前 4KB 头部覆盖损坏文件的开头 dd if=healthy.rsv of=damaged_patched.rsv bs=4096 count=1 conv=notrunc dd if=damaged.rsv of=damaged_patched.rsv bs=4096 skip=1 seek=1 conv=notrunc这段操作的本质是"借壳"——容器结构用健康文件的，码流用损坏文件的。成功率取决于两个文件的封装版本是否一致。同机型同固件基本能成，跨固件就会解析出错误的轨道信息。
嫁接失败的话就上分段截断。思路是把大文件切成若干段，每段单独尝试修复，把能救回来的段落拼起来。切分点不能随便定，要落在同步字节上：
# 先定位所有同步字节位置，取间隔较大的位置作为切分点 python3 -c " data = open('damaged.rsv','rb').read() pos = [i for i in range(len(data)) if data[i] == 0x47 and (i % 188) < 2] cuts = [pos[i] for i in range(0, len(pos), 5000)] print('\n'.join(map(str, cuts[:50]))) "切出来的每段单独跑一遍重封装，能出画面的就保留，出不了的丢弃。最后用剪辑软件按原顺序拼回去。这个过程很土，但确实是 RSV 抢救里成功率最高的路子——它把"整体修复"变成了"局部抢救"，把一次失败变成多次独立尝试。
5. Premiere Pro 与 DaVinci Resolve 的兼容性实测
5.1 为什么同一份文件 PR 能认、达芬奇不认
修复完成的文件能不能进剪辑软件，取决于三件事：容器结构合规度、编码参数的合法性、以及软件自身对该编码的解码支持范围。前两条是文件本身的问题，第三条是软件能力边界，很多人把三者混为一谈，导致方向判断错误。
我在实测中总结出的规律是：Premiere Pro 对容器的宽容度更高，DaVinci Resolve 对参数的一致性要求更严。一个索引略有瑕疵的文件，PR 往往能强行读进来，最多在时间线上显示媒体离线后自动重连；同样的文件拖进达芬奇，很可能直接弹"媒体离线"或者干脆不出现在媒体池里。
RAW 格式的差异更明显。BRAW 在达芬奇里是原生支持，装上对应组件后可以直接调 ISO 和白平衡；在 PR 里则需要额外安装官方解码插件，没装的话文件能识别但显示为纯色块。某些机型的 RAW 在 PR 里需要相应的厂商插件，达芬奇则内置支持但依赖 GPU 解码能力，显卡不支持的话会退化成 CPU 解码，拖时间线卡到怀疑人生。
还有一条容易被忽略：达芬奇的免费版本对部分高位深编码有解码限制。修复出来的文件如果恰好是 10bit 4:2:2 的 H.265，免费版可能直接提示无法解码。这不是文件坏了，是版本能力边界。碰到这种情况别急着重修，先换一个编码参数相同的短片段测试一下，确认是软件限制而不是文件问题，再去考虑转码方案。
| 格式类型 | Premiere Pro 表现 | DaVinci Resolve 表现 | 建议 |
|---|---|---|---|
| CinemaDNG 序列 | 直接导入，需按帧率设置解释 | 直接导入，自动识别序列 | 两边都能用，注意帧率解释 |
| BRAW 单文件 | 需装厂商解码插件 | 原生支持，可调元数据 | 优先在达芬奇里做一级调色 |
| 某类厂商 RAW | 需对应插件，缺失时显示色块 | 内置支持，依赖 GPU | 先在达芬奇转码再进 PR |
| 修复后的 H.264/265 | 容错高，能强行读 | 参数不合法直接拒绝 | 用 PR 先过一遍再导出 |
| 重封装后的 MP4 | 正常 | 正常 | 注意时间戳连续性 |
5.2 时间码、帧率与音频同步的逐项校验
文件能导入只是第一步，真正的坑在时间线上。我固定的校验流程是三层：
第一层看时长与帧率。在媒体池里看软件报告的时长，跟修复工具报告的时长比对，再跟拍摄记录比对。三者不一致时，以拍摄记录为准，去查是修复环节丢了帧，还是软件解释参数时读错了。帧率读错是最常见的——24 帧的素材被读成 23.976，短时间内看不出来，剪到后面会发现音画慢慢错开。
第二层看时间码。把素材拖到时间线上，看起始时间码是不是拍摄时的原始值。修复过程重建容器时，起始时间码经常被重置成 00:00:00:00。单机位无所谓，多机位合板的时候就是灾难——所有机位的时码全从零开始，同步全靠手动对板。
第三层看音频。把音频单独导出成 WAV，在音频软件里看波形起点和终点，跟视频的对应关系比对。断电损坏的文件里，音频轨道往往比视频轨道短——因为音频包更小，写入更频繁，断电时丢失的尾部更多。这时候要么接受尾部静音，要么用同场景的其他音频补上。
提示：修复完成的第一时间就把时间码和帧率写进文件名或者元数据里。我习惯用
项目名_机位_日期_起始时码_帧率的命名规则，后期合板的时候能省掉大量翻场记的时间。
5.3 转码中转：什么时候该放弃直连
不是所有修复结果都值得直接用于剪辑。我的判断标准是：只要出现下面任意一条，就走转码中转，不在原始文件上硬扛。
- 剪辑软件能导入但拖动时间线明显卡顿，CPU 占用长期打满；
- 音频轨道与视频轨道长度不一致，且差值超过半秒；
- 时间码无法恢复，且项目是多机位合板；
- 原始编码在目标软件里属于受限解码范围；
- 素材需要给多个人协作，各人机器配置不一。
转码的原则是只转一次，且用高质量中间编码。我一般选 ProRes 422 HQ 或者同档次的帧内编码，位深和色彩空间跟源文件对齐。用帧间编码做中间格式是自找麻烦——每一代转码都在丢信息，而且解码开销大，剪辑体验差。
# 转成帧内中间编码，保留原始分辨率与帧率，音频统一为 48kHz ffmpeg -i salvaged.mov \ -c:v prores_ks -profile:v 3 -pix_fmt yuv422p10le \ -c:a pcm_s24le -ar 48000 \ -timecode 01:00:00:00 \ intermediate.mov-timecode这个参数值得单独说一句。修复出来的文件如果丢了原始时码，可以在转码时手动写回去，前提是你从场记或者文件名里找得到原始起始时码。写回去之后，转码产物就能直接参与多机位合板，不用再手动对。
6. 几个反复踩到的坑，以及我的应对习惯
6.1 修复工具报告"成功"不等于文件可用
这是所有坑里最坑的一个。工具弹出"修复完成"，进度条走满，输出目录里也确实躺着一个文件，大小还挺像回事。拖进播放器——黑的。拖进剪辑软件——离线的。
原因通常是修复引擎只完成了"结构重建"这一步，输出的是一个结构合法但内容为空的壳。它把索引、时长、轨道描述都写对了，但码流部分因为识别失败而全部丢弃。这种情况在文件头严重损坏时特别常见。
我的应对是不看提示看数据。修复完成后立刻跑三个命令：
# 1. 看容器结构和流信息 ffprobe -v error -show_format -show_streams output.mov # 2. 实际解码一遍，统计有效帧数 ffprobe -v error -count_frames -select_streams v:0 \ -show_entries stream=nb_read_frames -of csv output.mov # 3. 抽取若干帧存成图片，肉眼确认画面正常 ffmpeg -v error -i output.mov -vf "select='not(mod(n,300))'" \ -vsync 0 -q:v 2 check_%03d.jpg第一条看duration和bit_rate是否合理，第二条看实际解出的帧数跟预期差多少，第三条最直观——抽出来的图片里只要有一张是纯色或者雪花，就说明那一段没救回来。三个都过了，才算真的修好。
6.2 修复过程中最常见的三个误操作
第一个是在原卡上直接跑修复。前面提过，但还是要再强调一遍。修复工具会反复读取文件、尝试定位、写入临时数据，这些动作对一张已经处于临界状态的卡来说是致命的。我见过最惨的情况是本来只坏了尾部，修完变成整个目录都读不出来。
第二个是用错误的样本文件反复试。样本不对，修出来的结果就是错的，而且错得有迷惑性——文件能打开、有画面、有时长，只是色彩不对或者时间码不对。有人会以为是"修得不够深"，于是换深度修复再跑一遍，越跑越偏。正确的做法是样本不对就换样本，别在参数上折腾。
第三个是只留一份修复结果。修复过程本身就带有随机性，同样的输入跑两次，输出可能略有不同。我习惯把每次修复的输出单独存一个目录，用参数组合命名，全部保留到项目结束。曾经有一次，第一次修复的结果音频有问题，第二次的视频反而少了几帧，最后是从两次结果里各取一部分拼出来的。
6.3 从源头降低损坏概率的几个习惯
这些习惯平时看不出价值，出事的时候能救命。
录制前留参数档。每换一次录制设置，让设备录十秒左右的"参数样本"，单独存一个小目录，跟项目素材分开。这个动作花不了两分钟，但修复时能省掉找样本的大麻烦。
关键场次双卡备份。支持双卡的设备就打开同步录制，单卡设备就在换场间隙把已拍内容复制到移动固态上。复制完不要立刻格式化卡，等当天收工确认素材能正常打开再格。
不要边拍边删。在卡上删除文件、尤其是删除后再录制，会让文件在物理上碎片化，一旦损坏，连续可恢复的片段会大幅减少。我的习惯是卡只写不删，回工作室统一拷贝、统一清理。
备一块够快、够稳的卡。卡速跟不上录制码率是最常见的 RSV 来源之一。设备写不过来的时候不会报错，它会先建一个临时文件慢慢写，写不完就留在那儿。一块标称速度达标但持续写入掉速的卡，是这类事故的高发源头。买卡的时候看持续写入曲线，不要只看峰值。
定期做"可读性巡检"。长期存放素材的硬盘和固态，每隔几个月抽查几个文件能不能完整解码。存储介质的老化是渐进式的，等到整块盘读不出来的时候，损失就不是一两个文件了。
这套流程走下来，RAW 和 RSV 这两种看起来最没救的损坏类型，实际抢救成功率比想象中高不少。核心不在于用了哪个工具，而在于把"分层判断、先做镜像、选对样本、逐项验收"这几步老老实实走完。工具只是执行者，判断才是决定结果的那一环。
