iOS文件浏览器从零构建：沙盒机制与FileManager核心实战

1. 项目起点：为什么我决定从零写一个 iOS 文件浏览器

做 iOS 开发这些年，经常看到群里有人问"怎么读取 Documents 目录里的文件""为什么我保存的图片找不到""能不能像安卓一样直接访问手机目录"，问的人多了，我干脆把这块内容系统地梳理一遍，顺便写一个可复用的文件浏览器 Demo。这个项目听起来不大，但真做起来涉及的东西并不少：Sandbox 沙盒机制、FileManager 的完整用法、UIDocumentPickerViewController 跨应用文件交互、Security-Scoped Resource 访问权限管理，还有列表 UI 与文件数据的解耦设计，几乎把 iOS 文件相关的知识点串了一遍。

当时定下的目标很明确：做一个能在模拟器和真机上跑起来的文件浏览器，支持目录层级浏览、文件进入系统级"文件"App 的入口、图片和文本等常见格式的预览，同时保证文件数据与 UI 驱动分离，后续要加搜索、重命名、删除都不会伤筋动骨。

这同时也是给初级开发者的一份"抄作业"指南：从理解沙盒目录结构开始，到 FileManager 的关键 API，再到 Document Picker 的接入，每一步都有完整代码和踩坑记录。无论是为 App 做本地文件管理功能，还是准备面试 iOS 文件相关的问题，这篇文章的内容都够用。

2. 沙盒机制与 iOS 文件架构拆解

2.1 为什么 iOS 要搞一个"沙盒"

第一次接触 iOS 文件管理的开发者，通常会有一个困惑：我以为的 App 内文件访问是全局的，为什么实际总是找不到别人的文件？原因在于 iOS 从设计之初就走了一条和桌面系统完全不同的路：每个 App 有自己的独立存储空间，彼此隔离，App 只能访问自己的那一亩三分地。

这个设计很多人叫它"沙盒"，叫法很形象。每个 App 安装之后，系统会给它分配一个私有目录，相当于一个带锁的房间。你的 App 在房间里面怎么折腾都行，但出不了门，别的 App 也进不来。这种隔离带来的直接好处是安全，某个 App 被攻破，恶意代码最多只在这个房间内活动，伤不到系统和其他 App。代价也很明显：App 之间的文件共享变得麻烦，必须通过系统提供的公开入口（比如 Document Picker）来中转。

理解沙盒是做好文件浏览器的前提，因为你在 App 里能看到的"文件系统"并不是整个手机的目录树，而是这个私有空间加上有限的系统授权访问区域。写代码时，如果路径获取方式不对，拿到的是 Bundle 里的只读资源路径，或者写错目录层级，就会出现"明明保存了，重启之后找不到"的诡异问题。

2.2 沙盒内的三大目录如何选型

iOS 为每个 App 预置了几个标准目录，文件浏览器要展示的、要操作的，主要围绕它们展开。这里我用一个表格帮你快速建立认知，下面再逐个细说。

Documents 目录是文件浏览器的重点，因为用户能感知、需要长期保留的数据都放这里。比如用户从别的 App 导入的文档、自己创建的照片或笔记，保存到 Documents 是合理选择。Library 目录适合放 App 内部数据，比如数据库文件、用户偏好，这些东西一般不希望用户直接看到和改动，所以文件浏览器里我默认把 Library 做成二级入口，而不是直接铺开所有子目录。

Library/Caches 和 tmp 目录需要特别注意：系统在存储空间紧张时可能会清理它们。如果你把用户的重要文件放这里面，然后告诉用户"文件已保存"，那是一场灾难。我在项目里给缓存目录做了明确的标识，提示用户这些文件可能随时会被系统清理。

Bundle 目录是另一个容易踩坑的点：很多人第一次用 FileManager 列目录，把 Bundle 的路径打印出来，发现是只读的，往里写文件报错。结论很简单：Bundle 里是 App 自带的内容，不是用户文件，文件浏览器可以展示，但不能对它做写操作。

2.3 文件浏览器的目录模型怎么设计

文件浏览器这东西，最怕的就是界面和文件操作逻辑揉在一起。试想一下，如果你直接在 ViewController 里写目录遍历代码，下一页目录又要重新写一遍遍历逻辑，加删除功能时还要绑架列表刷新逻辑，改起来有多崩溃。

我当时在工程里建了一个简单的 FileItem 模型，用来描述"一个文件或目录需要展示的信息"：

struct FileItem: Identifiable { let id: URL let name: String let isDirectory: Bool let size: Int64? let modificationDate: Date? let fileURL: URL }

所有需要展示的属性，一次性从文件系统里读出来，缓存成模型数组，UI 层只跟这个模型数组打交道，不直接碰 FileManager。目录切换时重新扫描，生成新的 FileItem 数组，列表自然刷新。这样 UI 和文件系统就被解耦了。

大文件场景下还要注意一个细节：文件大小计算很耗时，如果列表有几百个文件，逐个计算大小会卡主线程。所以 FileItem 里的 size 用了可选值，默认不读取。列表展示时优先显示名称和时间，等到用户点进文件详情，再计算大小和类型信息。这个设计后面会在性能优化章节展开讲。

3. FileManager 核心操作与实战细节

3.1 目录遍历的两种方式，以及性能对比

FileManager 提供了两种获取目录内容的方式，看起来差不多，实际差别很大。

第一种是 contentsOfDirectory(at:includingPropertiesForKeys:options:)，只读取当前一层目录；第二种是 enumerator(at:includingPropertiesForKeys:options:)，递归遍历所有子目录。我的文件浏览器用的是第一种，因为它是分级浏览，每次只需要当前层级的内容，第二种更多用在搜索功能里，或者做"统计整个文件夹大小"这种场景。

这里有一个特别重要的性能知识点：获取文件列表时，尽量用 FileManager 的批量 API，一次性把所有文件的属性都读出来，而不是每个文件分别调用 attributesOfItem。文件数量多的时候，逐个调用相当于给磁盘发了几百个请求，卡顿是必然的。批量 API 配合 URLResourceKey 可以一次拿到类型、大小、修改日期等关键属性：

func loadItems(at directoryURL: URL) -> [FileItem] { let keys: [URLResourceKey] = [.isDirectoryKey, .nameKey, .contentModificationDateKey, .fileSizeKey] let fileManager = FileManager.default guard let urls = try? fileManager.contentsOfDirectory(at: directoryURL, includingPropertiesForKeys: keys, options: [.skipsHiddenFiles]) else { return [] } return urls.compactMap { url in guard let values = try? url.resourceValues(forKeys: Set(keys)) else { return nil } return FileItem( id: url, name: values.name ?? url.lastPathComponent, isDirectory: values.isDirectory ?? false, size: values.fileSize.map { Int64($0) }, modificationDate: values.contentModificationDate, fileURL: url ) } .sorted { $0.isDirectory && !$1.isDirectory } }

列表做了排序，目录排在前面，文件排在后面，符合主流文件浏览器的习惯。排序也有讲究：文件数量少可以直接在内存里排，但如果目录里有上万个文件，内存就会变得紧张。这种场景我建议惰性加载或者分页，不过常规 App 到不了这个量级，可以后面再优化。

3.2 创建、移动、重命名、删除的封装思路

文件浏览器最常用的操作就是增删改查，这些操作 FileManager 都提供对应的 API，但实际使用中有很多边角情况需要注意。

创建目录用 createDirectory(at:withIntermediateDirectories:attributes:)，其中一个关键参数是 withIntermediateDirectories。设为 true 时，系统会自动创建路径中缺失的所有层级目录，设为 false 的话，如果父目录不存在，直接报错。日常使用中我基本都设置成 true，省心，逻辑也安全。

移动和重命名在 FileManager 里是同一个 API 的两种表现：moveItem(at:to:)。重命名就是移动的目标路径不一样。这里有一个经典坑：如果目标路径已经存在同名文件，moveItem 会直接抛错，而不是覆盖。做文件浏览器时，必须在移动前先检查目标路径是否存在，如果存在，需要弹出提示让用户选择"替换"或者"取消"。

删除是相对简单的一个，removeItem(at:) 可以删文件也能删目录。但我在项目里做了一个特殊处理：回收站。与其直接物理删除，不如把文件挪到 tmp/Trash 目录下。用户反悔了还能恢复。这个体验比系统自带文件 App 还好，很多第三方文件管理器也是这么做的。

func deleteItem(at url: URL) throws { let trashURL = FileManager.default.temporaryDirectory .appendingPathComponent("Trash", isDirectory: true) try FileManager.default.createDirectory(at: trashURL, withIntermediateDirectories: true) let destination = trashURL.appendingPathComponent(url.lastPathComponent) if FileManager.default.fileExists(atPath: destination.path) { try FileManager.default.removeItem(at: destination) } try FileManager.default.moveItem(at: url, to: destination) }

3.3 路径处理：为什么不能用字符串拼接

初学文件操作最容易犯的错，是用字符串拼接路径：把目录路径当成字符串，后面加个 "/" 再拼文件名。这在大多数情况没问题，但遇到 iOS 这种对路径处理很严格的环境，迟早出事。比如文件名里有特殊字符，或者目录路径本身末尾就带斜杠，字符串拼接的结果可能你根本想不到。

正确的做法始终是使用 URL 的 appendingPathComponent 方法：

let directory = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0] let fileURL = directory.appendingPathComponent("user", isDirectory: true) .appendingPathComponent("profile.json")

URL 是结构化的，它知道每个路径组件之间怎么拼接最合理，还会自动处理特殊字符的转义。我在项目里所有涉及文件路径的地方，一律用 URL 类型传递，字符串只用于展示和日志输出。这个习惯让我避开了很多莫名其妙的"文件路径不对"问题。

另外还有一个隐藏问题：大小写敏感。iOS 模拟器的文件系统可能大小写不敏感，但真机上的文件系统行为不一定和模拟器一致。如果你的 App 在不同环境表现不同，检查一下是不是路径大小写的问题。稳妥做法是存取路径时完全统一大小写规则，例如统一用小写文件名。

4. Document Picker 接入：打破沙盒壁垒的正确姿势

4.1 为什么需要 Document Picker

沙盒机制严格限制了 App 间的文件访问，文档类 App 必须有办法让用户从其他来源打开文件，比如从 iCloud Drive、从微信收到的文件，或者从 U 盘导入。Apple 给出的标准方案是 Document Picker，对应 UIKit 里的 UIDocumentPickerViewController。它的意义在于：用户主动选择某个文件授权给你的 App 读取，你的 App 借用户的授权去访问沙盒之外的文件，全程不需要越狱，也符合苹果的规则。

实际开发中很多需求都依赖它：文件管理器要能"导入"外部文件到沙盒；协作类 App 要能打开用户从网盘下载的文件；笔记类 App 要能添加 PDF 附件。还有 iOS 自带的 Files App，本质上也是一个系统级的文件浏览器，但它不会把所有文件给第三方 App 直接访问，而是提供一个文件选择界面，让用户来授权。

我对 Document Picker 的评价是：它是 iOS 文件生态里最优雅的设计之一。你的 App 不需要拥有系统目录的完全访问权，用户始终控制着自己文件的去向。

4.2 两种模式：导入（Import）与打开（Open）

UIDocumentPickerViewController 支持两种模式：import 和 open。这在选择和取舍时非常重要。

Import 模式会把选中的文件复制一份到你 App 的沙盒目录中，一般是 Documents/Inbox，你的 App 获得的是这份副本。它的好处是，之后你再也不需要源文件做什么，副本完全归你所有，不存在访问权限过期的问题。但代价是如果文件很大，复制需要时间和空间。

Open 模式不复制文件，直接给你一个指向原始文件的安全作用域 URL（Security-Scoped URL）。你的 App 可以在授权期间直接读取源文件，但必须显式调用 startAccessingSecurityScopedResource 开始访问，用完还要调用 stopAccessingSecurityScopedResource 结束访问。这个模式对大文件非常友好，不占空间，读取即时。缺点是离开安全作用域之后，URL 会失效，不能长期持有。

我的文件浏览器两个入口都保留了：导入操作对应 import 模式（用户主动把文件放进沙盒），浏览操作对应 open 模式（主要为了浏览和预览外部文件）。这样既满足了长期保存的需求，又支持临时查看大文件。

4.3 安全作用域访问的完整写法

如果选择 open 模式，处理安全作用域 URL 的方法有严格的规范。以下是项目里验证过的完整实现：

func handlePickedDocument(at url: URL) { let shouldStopAccessing = url.startAccessingSecurityScopedResource() defer { if shouldStopAccessing { url.stopAccessingSecurityScopedResource() } } // 复制文件到本地沙盒，或读取内容 let destinationURL = FileManager.default .urls(for: .documentDirectory, in: .userDomainMask)[0] .appendingPathComponent("Inbox") .appendingPathComponent(url.lastPathComponent) try? FileManager.default.copyItem(at: url, to: destinationURL) }

细节都在代码里：

• startAccessingSecurityScopedResource 返回 Bool，表示你是否真的需要调用停止访问的方法。如果返回 false，意味着 App 对这个 URL 有完整的访问权限，不需要停止。
• stopAccessing 必须和 start 成对调用，而且要尽早调。我记得早期版本没调 stop，结果 App 运行一段时间后，再打开其他文件时就报 permission denied 了。
• 所有读取操作必须在 start 和 stop 之间完成。如果你想长期持有这个文件，唯一的正确做法是在授权窗口内把它复制到自己的沙盒目录里。

4.4 配置 UIDocumentPickerViewController 的细节

初始化 UIDocumentPickerViewController 有两种方式。一种是直接指定支持的文档类型（UTType），另一种是指定打开目录。核心代码如下：

let picker = UIDocumentPickerViewController(forOpeningContentTypes: [.item], asCopy: true) picker.delegate = self picker.allowsMultipleSelection = false present(picker, animated: true)

forOpeningContentTypes 参数很重要。想支持所有文件类型，传 [.item] 即可。如果只想让用户选图片，可以传 [.image]；只想选 PDF，传 [.pdf]。UTType 是 iOS 14 之后的推荐 API，旧版本用的 kUTType 系列已经不建议使用了。

asCopy 参数等价于把 open 模式和 import 模式做了高级封装。传 true 时，系统会在 picker 内部自动把文件复制到你的沙盒里，你拿到的 URL 直接可用，不需要安全作用域访问。传 false 时，你拿到的是原始 URL，需要自己管理访问权限。项目里默认传 true 省心，但在大文件场景下传 false 更合理。

picker 还有一行容易被忽略的代码：picker.shouldShowFileExtensions = true。用户选文件时能看到文件扩展名，这对文件浏览器类 App 特别重要，不然用户不知道这个文件是 PDF 还是 Word。

Delegate 回调在 iOS 14 之后统一收敛到了 didPickDocumentsAt，旧的 didPickDocumentAt 已经废弃。实现里需要注意同时处理取消的情况，didPickDocumentsAt 在用户取消时不会调用，但不意味着 App 什么都不用做，至少 UI 上要恢复到可操作状态。

5. 文件浏览器的 UI 层与数据层配合

5.1 列表驱动：从 FileItem 到 SwiftUI 或 UITableView

文件浏览器的界面无非两种主流方案：SwiftUI 的 List 和 UIKit 的 UITableView/UICollectionView。两者各有优劣，但核心思路一致：数据源是一个 FileItem 数组，界面只是对数组的映射。

用 SwiftUI 写起来很直观：

struct FileListView: View { let items: [FileItem] let onTap: (FileItem) -> Void var body: some View { List(items) { item in Button { onTap(item) } label: { HStack { Image(systemName: item.isDirectory ? "folder" : "doc") Text(item.name) } } } } }

这套做法的核心优势是，文件操作和界面完全解耦。点击某个目录，外面只需要重新扫描一次目录，生成新的 items 数组，整个列表就会自动刷新。删除或重命名后，刷新数组，界面同步，不用手动操作 Cell 的增删，省掉了很多麻烦。

不过用 SwiftUI 要注意一个坑：List 会对大数据集做懒加载，但 FileItem 数组如果是几百上千个文件，初始化时预留的数组能力是足够的，真正需要担心的是磁盘读取。只要你遵守前面说的批量读取原则，用 SwiftUI 做文件列表不会有明显的性能问题。

5.2 文件类型判断与图标映射

文件浏览器的体验好坏，很大程度取决于文件类型的展示。用户看到 docx、pdf、jpg、png、mov，内心已经有了预期，你的界面最好能直观反映出来。

我项目里用了 UTType 来推断文件类型，并映射到 SF Symbols 上：

func iconName(for url: URL) -> String { guard let type = try? url.resourceValues(forKeys: [.contentTypeKey]).contentType else { return "doc" } if type.conforms(to: .folder) { return "folder" } else if type.conforms(to: .image) { return "photo" } else if type.conforms(to: .movie) { return "film" } else if type.conforms(to: .audio) { return "music.note" } else if type.conforms(to: .pdf) { return "doc.richtext" } else if type.conforms(to: .text) { return "doc.text" } return "doc" }

UTType 的 conforms(to:) 方法支持层级判断，非常方便。图片、视频、音频、文本、PDF 都能被识别出来。注意这个判断也是有开销的，所以 UI 层可以直接在 cell 的构建时调用，但不要在 cell 滚动时反复调用，最好把 icon 名称也缓存到 FileItem 里，一次读取多次使用。

5.3 文件预览：Quick Look 与 WebView 的取舍

文件浏览器的收尾动作是预览。很多需求不需要完整编辑能力，只要用户点一个文件，系统能弹出预览界面就够了。iOS 提供了现成的解决方案：QLPreviewController。

QLPreviewController 支持非常多的格式：图片、PDF、文本、Office 文档、视频等。接入方法也简单，实现 QLPreviewControllerDataSource 协议即可：

class PreviewManager: NSObject, QLPreviewControllerDataSource { private let url: URL init(url: URL) { self.url = url } func numberOfPreviewItems(in controller: QLPreviewController) -> Int { return 1 } func previewController(_ controller: QLPreviewController, previewItemAt index: Int) -> QLPreviewItem { return url as NSURL } }

这里有个小细节：QLPreviewItem 要求的是遵守协议的 NSURL，所以直接把 URL 转成 NSURL 就行。项目里我把 PreviewManager 保存成属性，避免被提前释放，否则会出现"界面还没弹出来，代理对象已经销毁"的诡异 bug。

对于 Quick Look 支持不好的格式，比如某些老旧格式或加密文件，用一个 WKWebView 做兜底预览也不是不行，但要注意 WKWebView 的沙盒读文件限制。iOS 14 之后 WKWebView 默认不能读本地文件路径，需要显式调用 loadFileURL(_:allowingReadAccessTo:)，允许的访问目录越具体越好，直接传父目录虽然省事，但安全性打折扣。

6. 进阶话题与性能优化

6.1 大目录遍历不卡界面的几种方案

文件浏览器最容易翻车的地方，就是遇到一个几千个文件的目录。如果用 SwiftUI 的 List 直接绑定大数组，初始加载那一瞬间的磁盘读取和模型创建会把主线程卡死，用户看到的直接是"App 未响应"。

我的做法是后台扫描加主线程刷新：

func scanDirectory(_ url: URL, completion: @escaping ([FileItem]) -> Void) { DispatchQueue.global(qos: .userInitiated).async { let items = self.loadItems(at: url) DispatchQueue.main.async { completion(items) } } }

扫描用到 FileManager 和 URLResourceValue，放在后台线程没有问题，读取到的数据模型是 value type，线程安全。真正需要注意的只有 UI 更新必须回到主线程。每次进入目录时先显示 loading，扫描完成后再刷新列表，体验会好很多。

6.2 文件协调与冲突处理

当你的文件浏览器需要支持多窗口打开同一文件，或者同一个文件被系统 Files App 和你的 App 同时编辑时，普通的 FileManager 读写可能遇到数据不一致的问题。iOS 设计了一套协调机制，NSFileCoordinator。

NSFileCoordinator 的核心思想是：所有对共享文件的读写，都要通过协调器来安排，它负责加锁、等待其他操作完成、然后才执行真正读写。比如两个进程同时改同一个文件，如果没有协调器，其中一个的写入可能被另一个覆盖，数据丢失。

代码如下：

let coordinator = NSFileCoordinator(filePresenter: nil) var error: NSError? coordinator.coordinate(readingItemAt: url, options: [], error: &error) { coordinatedURL in let data = try? Data(contentsOf: coordinatedURL) // 处理 data }

在实际项目中，我主要把 NSFileCoordinator 用在了文件和 iCloud 同步的配合上。如果 App 开启了 iCloud 能力，用户从 Files App 编辑了文件，你的 App 再次读取时，必须通过协调器让系统先同步最新版本，否则你读到的可能是旧数据。这个知识点面试中经常被问到，实际项目里也经常被忽略。

6.3 文件大小计算优化的一个实操技巧

计算单个文件大小很简单，FileManager 的 attributesOfItem 可以拿到 fileSize。但计算一个目录的总大小就麻烦了，因为要遍历所有子文件并累加。

我项目里封装了一个方法：

func folderSize(at url: URL) -> Int64 { guard let enumerator = FileManager.default.enumerator( at: url, includingPropertiesForKeys: [.fileSizeKey], options: [.skipsHiddenFiles] ) else { return 0 } var totalSize: Int64 = 0 for case let fileURL as URL in enumerator { if let values = try? fileURL.resourceValues(forKeys: [.fileSizeKey]), let size = values.fileSize { totalSize += Int64(size) } } return totalSize }

这里顺手强调一下 enumerator 的性能特性：它每枚举一个文件只读取了约定的 fileSizeKey，比逐个调用 attributesOfItem 高效得多。而且它在后台线程执行时，即便目录很大也不会卡界面。不过这种遍历毕竟耗时间，展示给用户前最好先显示一个"计算中"状态，并且把结果缓存起来，避免每次进入目录都重新计算。

7. 实操中遇到的坑与排查技巧

7.1 开机后目录找不到的灵异事件

项目开发到一半，测试同事反馈了一个诡异问题：App 内创建的文件，重启 App 后不见了。我一开始以为删除逻辑有 bug，后来发现是写入路径选错了，把文件写到了 tmp 或者 Library/Caches 目录。这两个目录在设计上就是"系统可以随时清理"的位置，重启 App 或者存储空间紧张时，文件很可能就没了。

排查方法其实很简单：在 App 里加一个"路径信息"的调试页面，把当前写入的完整路径和沙盒目录的结构打印出来。这样用户在文件浏览器看到的路径和服务端逻辑里写入的路径，能一一对应上，问题立刻暴露。

7.2 Document Picker 的 Security-Scoped URL 失效

有段时间用户反馈：从 Files App 打开文件后，可以正常预览，但退出文件浏览器再回来，这个文件就打不开了。原因就是 open 模式下，拿到的是安全作用域 URL，没有正确管理访问声明，原来的访问权限已经失效。

我的处理方案是规范化流程：拿到 URL 后，要么立即复制一份到沙盒内，要么在每次访问时重新调用 startAccessingSecurityScopedResource 并配对调用 stop。绝对不持有原始 URL 跨会话使用。UI 层面也做了处理：外部文件的预览页会提示用户"此文件来自外部，如需长期使用请导入到 App"，这样用户也能理解这个文件为什么又打不开了。

7.3 大文件复制的内存峰值问题

Document Picker 复制大文件时，如果直接用 Data(contentsOf:) 读取整个文件再写出去，内存会直接飙到一个非常危险的高度。2GB 的视频文件，这么做直接 Crash。

正确做法是流式复制，边读边写：

let inputStream = InputStream(url: sourceURL) let outputStream = OutputStream(url: destURL, append: false) inputStream?.open() outputStream?.open() let bufferSize = 1024 * 1024 let buffer = UnsafeMutablePointer<UInt8>.allocate(capacity: bufferSize) while inputStream?.hasBytesAvailable == true { let read = inputStream?.read(buffer, maxLength: bufferSize) ?? 0 if read == 0 { break } outputStream?.write(buffer, maxLength: read) } buffer.deallocate() inputStream?.close() outputStream?.close()

缓冲区选择 1MB，既保证了效率，内存占用也可控。这是复制大文件的标准方案，我在项目里把它封装成了带进度回调的版本，UI 上可以展示复制进度。

7.4 文件清单速查表

日常开发中最常见的问题，我整理了一张表，新人照着排查基本能定位 80% 的问题。

这个表格不是凭空写的，每条都是在这个 App 开发过程中真实踩过的坑。文件浏览器看起来简单，真要做到稳定流畅，需要注意的细节比想象中多得多。

8. 项目后续可扩展的方向

文件浏览器做完了基础版，如果你想继续深挖，有几个方向很值得尝试。

第一个是支持 iCloud Drive 的接入。利用 iCloud 的 API，让文件浏览器直接浏览云端文件目录，配合 NSFileCoordinator 处理冲突，体验会完全不一样。

第二个是全文搜索。iOS 提供 spotlight 的接口，通过索引可以让用户从系统搜索框直接搜到 App 内的文件。这里需要建立文件元数据的索引，包括文件名、文件类型、内容摘要等，是一个不小的工程。

第三个是自定义文件预览。虽然 QLPreviewController 覆盖面很广，但如果你的 App 需要处理自定义格式（比如工程文件、配置文件、日志），可以自己写预览界面，把文件内容按结构化方式渲染出来。

第四个是操作队列。把移动、复制、删除操作做成队列，支持撤销和重做，还能展示操作进度。文件操作一旦多起来，没有队列管理，后续做批量操作会很吃力。

就我个人的经验来说，文件管理是每个 App 最终几乎都会碰到的领域，哪怕你的 App 只是需要保存一张图片。搞懂沙盒机制、FileManager 的 API 边界、Document Picker 的授权规则，这套知识在今后做任何涉及文件的 App 时都能复用。最后再分享一个小技巧：文件浏览器这类工具型 App，调试时尽量用真机，模拟器的文件系统行为和真机存在差异，尤其是权限和 iCloud 相关功能，用模拟器验证经常得出错误结论。这个问题不算难，但能早避一日就别晚避一日。