一堆 FCP 模板点不开,我以为是缺素材,结果坏得更离谱

前天晚上我在远程 Mac 租机上打开 FCP，效果浏览器里一整排模板齐刷刷挂着黄叹号——点了没反应，预览图全是灰的。数了一下，30 个模板，19 个这样。

刚发现的时候，和大多数人一样，我以为是素材丢了。这包是早些年攒的，媒体引用一大堆，只要缺一个引用整个就废。我挨个核对了引用关系，结果 Media 引用零缺失，包体本身是完整的。那就怪了，东西都在，为什么打不开？

我后来干了一件挺笨的事：把那 19 个模板文件拉出来，一层层扒它的底层结构。它们本质上是一种二进制化之后的 XML 文件。用解析工具去读的时候直接报错，XML 根本立不起来。再往下比对字节，发现这 19 个文件的头尾都不对——首字节没了，尾部还多出一段垃圾字节。诡异的是，文件总大小一点没变。

这就像一本书，总页数没少，但第一页开头被撕掉一行、最后一页后面又糊了几行乱码，你还是按原来的页数去翻，自然翻不动。FCP 解析不了，就给你挂个叹号。

定位清楚就好办了。我没碰那 11 个完好的，只针对 19 个损坏文件做了两件事：补回首字节，删掉尾部垃圾。然后做了三重校验：头尾字节 30/30 全部能对上；XML 解析 30/30 全过；修复后的包结构和成员命名跟原包一模一样，只有内容字节有改动。三关全过，我才敢说"修好了"这三个字。

修完才发现，真正的坑在打包这一步。因为要在不同系统之间倒腾，9 个序号目录和文件名末尾带着尾随空格——这玩意在不同系统下行为完全不一样：GNU tar 会把它剥掉，Python 原生 open 直接报错，bsd tar 还给你整出重复结构。最后我是用 tar-in-tar 内存直写才保住那些空格。还有两个小坑：安装脚本 v1 因为路径没加引号被词拆分搞挂了，v2 改成数组加全引号才正常；macOS 自带的 unzip 不认 UTF-8 标志位，中文文件名直接报 Illegal byte sequence，换成 Python 的 zipfile 才解开。

修模板修出了兴致，我干脆用官方 FxPlug SDK 从零做了个自己的插件。不是 Xcode 工程，就是一个 Makefile 加 clang。编译链路是：先检测 SDK，再编译 XPC 服务、Wrapper App 和 metallib，然后 ad-hoc 签名，最后 pkgbuild 出 pkg。产物里 Wrapper App 内嵌了 XPC 服务和 FxPlug.framework。

真机验证我走的是闭环：代码和素材同步到 Mac，跑 build-pkg.sh 真编译，6 项冒烟测试全 PASS，安装落盘，进 FCP 实测——效果浏览器里能看到、有预览图、能拖出来用、拖到时间线能渲染出画面。这一步我特意留了日志和 git 记录，因为我吃过一次亏：悬停没叹号，不等于渲染输出就正常。验证得看实际跑出来的东西，别凭印象下结论。

最后说句实在话。现在这个 pkg 是 ad-hoc 签名、没有公证，只能装在我自己这台机器上用。真要放到网上给别人装，还得走 Developer ID 签名加公证。所以它目前就是个本机可用的个人项目，我还在折腾，离能拿出手还早。

从翻车到修好再到自己做插件，踩的坑比写的代码多。这次的完整踩坑清单，我整理在了「小风瞎折腾」，省得你们再掉一遍同样的坑。