不要 assume“时代在进步”，很多东西不倒车已经是不错的了。
SSD 虽然快，但是不同 SSD 的速度也是参差不齐（特别是“便宜”的）。
软件就更别提了，放眼现在的主流文件系统，除了 APFS 之外，所有其他项目的底子都是上古时代的。APFS 倒是够“新”，所以 APFS 有个功能叫“Fast Directory Sizing”，可以直接从文件系统层获得文件夹的大小，不过就连这个好像也是需要手动启用，并且 Finder 自己也没有用上。
而且现在文件系统的痛点不是大文件，而是大量小文件。经过软件抽象后，SSD 把大量小文件操作的速度提升了 1-3 个数量级，但是还不够。我 du 了一下 home 目录下的几个大文件夹，大概需要的时间在 5s-30s 以内。Windows 下用 explorer 看 C:\Windows 文件夹属性，统计大小花了 2 分 15 秒，换了一台 Windows 需要大概 1 分钟。无论是十秒钟还是一分钟都不是 UI 上能接受的量级。当然这么巨大的文件夹是少数（虽然我每次打开 home 或者 C:\ 都会看到 ...），但是问题在于那么程序呐，就都不知道，自己就不可以预料，一个文件夹到底有多大，需要花多长时间，这是个 O(n) 而非 O(1) 的过程。
可以通过缓存把这个过程变成 O(1) 的，比如 Finder 会把算好的文件大小放到 .DS_Store 里面去，不过既然涉及缓存，就必然会涉及到缓存如何更新的问题，这已经被证明是计算机科学中两大最困难的问题之一。比如 Finder 就没有处理好（我也不指望它能处理好）——我现在能看到有很多里面有一堆文件的文件夹大小显示 "Zero byte"，但是这个功能依然是我认为 Finder 是最好的文件管理器之一的最重要原因之一。Finder 并不是唯一一个可以直接显示文件夹大小的本地文件管理器，KDE 套件的 Konqueror 也可以，这货保持了 KDE 的一贯作风，把这个功能藏在了设置深处，但是它是有限制的，如果目录嵌套超过一定的层级就不会显示，而这个阈值可以调整，这倒也是 KDE 的一贯作风。至于 Konqueror 有没有缓存就不清楚了。Konqueror 还有很多有趣的设计，比如和上古时期的 Windows 一样，把文件管理器和浏览器放在一块，它的“收藏夹”菜单（虽然现在貌似流行叫“书签”，但是作为从上古 Windows 玩过来的我还是更喜欢“收藏夹”）既可以放 HTTP URL ，也可以放本地文件夹。可惜这东西现在好像已经基本是被抛弃的状态。还有个比较勉强的是 Midnight Commander ，这货是个 TUI 界面，选中文件夹按 <C-Space> 会现场计算大小并显示在 size 那一列里，多选可以批量做，但是切出去这个信息就没了。
Konqueror 我倒是一般不会用，我日常用的还是 Finder 和 Dolphin ，对比之下发现 Finder 这个功能不仅 bug 多，还有额外的一些代价——比如在访问 HDD （包括使用 HDD 的 NAS ）时，由于 Finder 一直在试图统计文件夹大小（部分情况还会涉及到生成媒体预览图），而 HDD 现在作为仓库盘一般什么乱七八糟的东西都有，就会让 HDD 一直处于忙的状态，很吵，Dolphin 就十分安静。额外生成的 .DS_Store 文件也会有麻烦——做个 Git 仓库，打个压缩包之类的都会掺合进来（ OS X 有个开关可以禁止在网络磁盘上生成 .DS_Store ，但是这不解决根本问题）。另外如果是个移动设备，统计文件夹大小占用的额外资源可能会增大耗电量。从这些角度来说，认为“始终统计文件夹大小”在现行软件栈中有百利而无一害的大概跟喜欢用 Electron 的是一种生物，不是蠢就是坏。
从另一个角度来说，统计文件夹大小真的是那么常用的需求么？对于服务器或者大多数命令行场景来说，一般不是，服务器要想干这个有 du 。如果按照现有体系，O(n) 遍历统计，就意味着你随手敲一个 ls ，就有一定机率需要等 10-20 秒，盲盒在 70 年代被提早发明了！如果把文件夹大小存在文件系统里，那每一次 IO 操作都会附带更新这个信息的开销，而如果这个信息只是偶尔使用，很明显不值得。所以为服务器设计的软件肯定不会考虑这个问题。这个东西在消费者那可能用处稍微多一点，但也不是那么多。要想看谁占磁盘多有 QDirStat 这样的专门软件，并不一定非要文件管理器或文件系统来兼职。一个好用的磁盘占用分析工具实现上可能会涉及到一些优化技巧，不是简单的递归遍历能解决的。作为一个 Linux 用户，从各方面平衡的角度来说，我还是更偏向于 Konqueror 那样的做法，成本大的功能默认不打开，打开之后可以自定义。
再往远处说，“文件”这个抽象，过时了！淘汰了！（
https://zhihu.com/question/472997775 ）上面的讨论已经很清楚了，“文件系统”以及 OS 的文件操作 API ，既需要处理少量大文件也需要处理大量小文件，既包含 sysfs ，也包含 RAM Disk ，Optane ，SSD ，还包含 HDD ，网络，和 5.25 寸软盘。而现在一般用户还有多少机会直接和“文件”打交道呢？ iOS 从发布时就直接隔开了不同 App 的文件存储，用户在笔记软件里的“笔记”也是直接在相关的软件里面访问的，Office 现在也在往云端发展，小而美倒是好像能把聊天记录备份成文件，不过也不能直接看，而且相信我如果小而美有个网盘业务的话，大概不会允许你直接往本地备份。
抽象总是有代价的，专门的需求就需要抛开通用的抽象，用专用的工具解决，比如做 Web 服务器用的是数据库，不是直接把数据 write 到文件里面。
当然这是本地的问题，至于为啥云端的东西不给你看，那答案倒是很简单，因为这些产品和“小而美”的设计思路，精神内核都是高度一致的，都是把用户当 ...
比起这个，我觉得给 Finder 和 Explorer 加上分屏功能倒是更有用。