在云端 Mac 上验收 macOS 文件类型关联与双击打开

远程调试 macOS 文档应用时，开发者常遇到这样的情况：终端指定应用后，样本文件能打开；把同一文件放到桌面双击，却进入了别的应用，或者系统询问该用什么打开。前一次成功只说明应用有机会接收文件，并没有验证文件类型关联。要查清问题，需把类型声明、应用接收、默认打开拆成三个独立结果。

本文用自定义 .notejson 文件举例。它的内容是 JSON，但扩展名用于标识应用自己的文档。操作应在已构建、可运行的 macOS 应用上进行；测试文件只放虚构数据，不使用生产文档。

先定义文件类型，而不是只判断扩展名

自有格式应有稳定的类型标识。示例约定标识为 dev.sample.notejson，扩展名为 notejson，内容符合 JSON。应用的类型声明需同时覆盖两件事：导出这个类型，以及声明应用能打开它。仅在代码里判断文件名后缀，不会自动让 Finder 建立关联。

在 Xcode 的应用目标中配置导出类型与 Document Types 后，检查最终应用包的 Info.plist。导出类型应能找到类型标识、扩展名及其符合的上级类型；文档类型应引用同一个标识。示例应用若只提供查看能力，将文档角色设为 Viewer，不要声称具备尚未实现的编辑能力。

检查对象是构建后的应用包，而不是工程界面里尚未打进产物的设置。

如果格式实际并非 JSON，就不要为了让示例通过而声明它符合 JSON；类型关系必须反映真实内容。修改声明后重新构建应用，旧应用包不会因为工程设置变化而自行更新。

检查交付包中的声明

先将本次待验收的应用放在固定路径。下列命令以 /Applications/NoteReader.app 为例，运行前将 APP 改为自己的应用路径：

APP="/Applications/NoteReader.app"
test -d "$APP/Contents" || exit 1
plutil -extract UTExportedTypeDeclarations json -o - "$APP/Contents/Info.plist"
plutil -extract CFBundleDocumentTypes json -o - "$APP/Contents/Info.plist"

第一条输出中核对 dev.sample.notejson 和 notejson；第二条输出中核对同一类型标识与文档角色。若 plutil 报键不存在，先回到目标配置和构建产物，不要跳到双击测试。某些工程由构建设置生成最终清单，更要以包内文件为准。

在远程 Mac 上还应确认自己验收的是刚构建的那一份。同名应用若同时留在下载目录和应用程序目录，终端指定路径的测试与 Finder 默认打开的测试可能指向不同副本。记录包路径并移走不参与本次测试的旧副本，比反复修改类型声明更有效。

用两种打开方式分离故障

创建一个临时样本，先明确指定应用打开，再测试系统的默认选择：

APP="/Applications/NoteReader.app"
CASE="$(mktemp -d)"
printf '{"title":"association-check"}\n' > "$CASE/demo.notejson"

open -a "$APP" "$CASE/demo.notejson"
open "$CASE/demo.notejson"

open -a 成功表示指定的应用被要求处理该文件。接下来必须观察应用是否真的显示了样本内容；只看到窗口出现，不等于读取完成。第二条命令不指定应用，才会经过默认打开的选择。也可以在 Finder 中双击同一样本，对照实际进入了哪个应用。

默认关联会受到该 Mac 上已有应用和用户选择的影响。因此验收记录应分别写下“指定应用打开的结果”和“当前用户默认打开的结果”，不能把后者当成所有机器必然一致的结论。若系统弹出选择应用的界面，同样要记录，而不是算作自动关联成功。

按症状定位，避免误修读取代码

表中的后两种情况尤其容易混淆。系统把文件交给应用后，应用仍可能因为样本格式错误而拒绝解析；反过来，应用完全能解析文件，系统也未必默认选择它。先确认路由发生在哪一步，再改对应代码。

验收完成后删除临时样本，并在构建记录中保留应用包路径、类型标识、样本扩展名及两种打开结果。下一次修改 Info.plist 或文档读取代码时，复用同一套检查，就能判断变化发生在类型关联还是应用内部，而不用靠“我双击过一次”作结论。

常见问题