MacOS SwiftUI文档类App修改导出类型标识后无法打开自动保存文件

可能残留旧标识符的场景及原因 #

1. 系统Launch Services UTI缓存
   Mac系统会全局缓存所有注册应用的UTI映射关系，你修改应用内的UTI配置后，系统并不会立即刷新缓存，仍会将.dap扩展名和旧的com.example.Dapka.dap标识符绑定，导致自动保存文件的类型识别失败。

2. 已生成文件的元数据绑定
   所有在修改UTI之前创建/自动保存的.dap文件，其扩展属性中已经固化了旧的UTI标识。你可以通过终端执行mdls 你的文件路径 | grep kMDItemContentType 查看文件实际绑定的UTI值，如果显示为旧标识符，即使你改了应用配置，系统也会判定新UTI不匹配无法打开。

3. 应用状态恢复缓存
   NSDocument的状态恢复数据会存储在本地路径 ~/Library/Saved Application State/[你的应用包名].savedState/ 下，这些缓存数据中记录了之前打开文档对应的旧UTI，应用重启时会优先读取这些缓存尝试恢复，触发类型匹配错误。

4. 构建产物缓存
   Xcode的DerivedData中可能残留了旧的Info.plist构建产物，没有将最新的UTI配置打包到应用中，导致实际运行的应用仍在使用旧配置。

5. 代码中遗漏的硬编码
   检查NSDocument子类的readableContentTypes、writableContentTypes属性赋值，以及所有涉及文件类型判断、导入导出逻辑的代码，是否还有硬编码的旧UTI字符串。

临时验证与永久修复方案 #

• 开发阶段快速验证：删除DerivedData、删除应用对应的Saved Application State文件夹，重启Mac后重新构建运行即可确认配置是否生效。
• 兼容旧文件：在CFBundleDocumentTypes的LSItemContentTypes数组中新增旧UTI com.example.Dapka.dap，让应用可以同时识别新旧两种标识符的.dap文件，避免存量用户升级后无法打开旧文档。
• 刷新系统UTI缓存：执行终端命令 /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user 强制刷新全局UTI映射。

内容的提问来源于stack exchange，提问作者Adam M.