那天审完一套网盘命令行工具，我顺手做了几次实测。根目录列目录大约用了0.37秒，全盘搜索大约用了0.3秒，连一个关键词都能很快找到。于是我产生了一个很自然的问题：既然网盘里的东西都能这么快找到，那把整个网盘的目录树列出来，应该也差不多快吧？
后来我发现，这个推断把几件完全不同的事混在了一起。搜索是在问服务端“有没有符合条件的对象”，列目录是在问“这个文件夹的下一层有哪些对象”，而递归遍历是在不断追问“这一层的每个文件夹里面又有什么”。它们看起来都叫“查看网盘”，但请求数量根本不是一个量级。
先把当时的问题放回现场
这次排查本来不是从性能开始的。前面先处理了几个更容易造成实际损失的问题：下载失败时不能把半成品留在目标位置，所以改成先写临时文件，完整写完再原子改名；分享文件名可能带有../，不能直接拼到本地路径里，于是只保留安全的文件名部分；分页接口有时缺少总数，也要补上“不满一页就停止”的兜底。
这些修复完成后，我用小文件、8.5 MiB的分片文件和分享链路做了回查，上传后的文件可以下载回来，sha256一致。事情做到这里，才有余力问一个更像使用习惯的问题：如果我只是想知道网盘里有什么，或者想找一个文件，是不是所有动作都能秒级完成？
当时的实测给了一个很容易误读的答案。根目录13项，列目录约0.37秒；一个有16项的子目录，约0.72秒；全盘关键词搜索约0.3秒；搜索限定返回100条结果，约0.68秒。数字都很小，所以我一开始也差点把“单次请求很快”理解成“任何范围的浏览都很快”。
搜索为什么能覆盖很深的目录
全盘搜索的关键，不是客户端很聪明地替我们走遍了每一个文件夹，而是服务端已经有自己的索引。我们提交一个文件名关键词，服务端在自己的数据结构里匹配，再返回符合条件的一页结果。客户端没有必要先拿到根目录，再拿到第1层、第2层，最后才知道某个深层文件是否存在。
所以，搜索的耗时主要和一次接口请求、结果数量以及网络往返有关，而不直接和文件藏在第几层有关。实测中，关键词命中子目录里的测试文件时，搜索过程并没有先进入那个目录。它是一次全盘范围的服务端查询，不是一次从根开始的人工翻箱倒柜。
搜索快的本质，是把“遍历所有位置”这件事提前交给服务端索引，而不是让客户端现场遍历。
不过，搜索也有边界。它主要按文件名做匹配，不等于搜索文件内容；结果里能拿到父文件夹标识，但不会直接给出完整路径。也就是说，搜索很适合回答“有没有这个文件”，却不一定马上回答“它完整地位于哪一串目录里”。如果我需要展示路径，还要根据父目录标识继续补查。
这也是一个重要区别：搜索把“发现对象”做得很快，但没有承诺把对象周围的全部结构一并交付。很多时候，我们以为自己要的是一个结果，实际上还要它的上下文；后者往往需要额外请求。
列一层目录，问的是另一个问题
单层列目录的请求模型更直接。给服务端一个文件夹标识，它返回这个文件夹的下一层项目。根目录只有13项时，一次请求就能拿完；子目录有16项时，也只需要把这一层交回来。即使目录里有100项，服务端按每页100项返回，仍然可以保持相对简单的请求链。
它的速度因此通常不错，但这里已经出现了分页。结果不止一页时，客户端需要继续请求下一页；如果总数信息缺失，就不能把“第1页返回成功”误判成“目录已经完整”。这次补分页兜底时，我特意验证了“不满一页即停”，因为一个看似方便的停止条件，直接关系到结果是否漏项。
表面上，列目录只是读取；实际上，它也在维护一条关于完整性的承诺。用户看到一个列表，会自然认为这就是这一层的全部内容。如果分页不完整，系统未必报错，却会悄悄给出错误印象。
如果不处理这个边界，后面会出现一种很麻烦的结果：搜索能找到文件，单独列某层却少了文件；使用者会以为服务端数据不一致，实际上只是客户端过早停止了分页。速度快并不能抵消结果不完整。
递归为什么会突然变慢
递归列目录树不是“把单层列目录放大一点”，而是把请求放进了一个不断扩张的任务里。先请求根目录，拿到其中的文件夹；再对每个子文件夹分别请求；如果子文件夹里面还有文件夹，就继续往下。每发现一个目录，就可能增加一个新的请求目标。
假设根目录下面有10个文件夹，下一层又各有10个文件夹，哪怕每次请求只要0.3秒，客户端也不能只乘一个深度。它需要等待很多次网络往返，还要处理分页、失败、限流、重复进入和中途停止。目录树越宽，请求数就越接近文件夹数量；目录树越深，等待链条就越长。
这件事表面上是“递归比较慢”，实际上是请求模型从“一次全盘查询”变成了“按文件夹数量逐个查询”。如果网盘有几百个文件夹，几十秒并不奇怪。速度慢的不是某个循环写得不够漂亮，而是客户端必须逐个向服务端确认那些目录的存在和内容。
把一次搜索的速度外推到整棵目录树，是把服务端索引查询误当成了客户端结构遍历。
最容易误判的错误捷径，就是为了找一个文件，先把所有子目录递归展开。这样做既浪费时间，也增加失败点：中间某个目录请求超时，整棵树可能停住；某一页漏掉，后面就会缺一支；请求太密集，还可能遇到服务端限制。为了回答一个“文件在哪里”的问题，先获取一份完整树，通常是把问题做大了。
我会怎样按目标选操作
我现在会先把目标分成3类。第一类是找文件：知道关键词、后缀或部分名称时，优先用服务端全盘搜索。它能在一次请求里覆盖多层目录，先快速确认对象是否存在。若还需要完整路径，再用返回的父目录标识补查，而不是一开始就递归全盘。
第二类是看某个位置的内容：我只列目标层级，先确认这一层有哪些文件和子目录。需要继续往下时，再明确指定下一层。这样每一步都能看到结果，也能在遇到异常时停在可判断的位置，不会为了获得全貌而承担整棵树的等待。
第三类才是确实需要结构核对，例如整理目录、检查层级关系或做迁移前盘点。这时递归是合理工具，但我会把它当成长任务处理：按目录逐个请求，保留分页状态，允许单个目录失败后记录并继续，最后报告哪些分支已经完成、哪些分支还需要补查。它的目标不是“看起来快”，而是结构真的完整。
我选择这套顺序，是因为它先用最小请求回答最小问题。找文件不需要先知道全部结构，浏览结构也不需要一次拿完整个网盘。只有在任务本身要求完整树时，才接受递归带来的请求成本。
下次我会怎么做
下次遇到类似需求，我会先问自己：我是在寻找一个对象，还是在确认一套结构？如果是前者，先搜索；如果只是想看某个文件夹，单层列目录；如果要完整树，提前按文件夹数量估算请求量，不再拿0.3秒的搜索结果做乐观预算。
我也会把返回结果分成“发现”和“定位”两步。搜索结果只能说明找到了匹配项，父目录标识还需要继续反查；分页返回成功只能说明拿到了一页，不代表这一层已经完整。把这两个边界写进流程，才能避免速度快却信息不全。
这件事让我重新意识到，工具的快慢很少只是一个数字。真正影响体验的，是我们让它回答了什么问题。一个流程成熟的标志，不是所有操作都能秒回，而是知道什么时候该用索引，什么时候只读一层，什么时候必须接受递归的成本。
省时的网盘操作，不是永远追求更快的接口，而是让请求范围和任务目标保持一致。