不知道各位在使用ubuntu 桌面版时有没有遇到过这个问题，打开本地文件时速度很慢，影响心情。如果你用chrome，某个页面需要上传本地文件时，会发现这个速度更慢，有时候甚至会直接卡死。
今天终于忍无可忍，要把这个问题分析下，并且解决掉。下面首先分析原因，不想看原因分析可以直接跳到后面解决方案部分。
原因分析
我本地设备如下,可以看出并非是硬件性能问题：
系统：Ubuntu 24.04
桌面环境：GNOME
硬件：Intel i7-14700K + DDR5 32GB + NVMe SSD
现象：
打开本地文件夹明显卡顿
双击文件反应慢
浏览器（Chrome / Firefox）上传文件、选择本地文件时更慢
那为什么 Ubuntu / GNOME 打开文件还会如此之慢呢？实际上慢的不是磁盘，也不是 CPU，而是 GNOME 默认启用的一套“文件索引 + 缩略图”机制。核心问题集中在两个东西上：
一、Tracker3：GNOME 的文件索引服务
Ubuntu 24.04 默认启用了 Tracker 3，它的定位是：一个“桌面级全文搜索引擎”。Tracker 主要完成以下的功能：监听家目录下的文件变化，扫描文件系统，解析文件内容和元数据（PDF、图片、视频、Office 文档等），最后把结果写入数据库，供 GNOME 全局搜索、Nautilus 使用。问题就在于Tracker 并不只是“后台慢慢索引”，而是会在你打开文件夹、选择文件时同步参与。于是就出现了打开目录时突然卡几秒、文件一多就明显掉帧、CPU / IO 明明没满，却“假死”的问题。这是设计层面的同步阻塞问题，性能再强也救不了。
二、GNOME 文件管理器的缩略图机制
Nautilus（文件管理器）默认行为是：打开目录时生成图片 / 视频 / PDF 缩略图，读取 EXIF、视频信息。对大文件也照样处理。当目录中存在大图片、视频文件、PDF、素材目录、下载目录时就会出现“打开文件夹 = 同时解码一堆媒体文件”的现象。这在 GNOME 中很多操作还是同步完成的，自然就慢。
至于为什么浏览器“打开本地文件”慢到地老天荒，经常丧心病狂的长达二三十秒，原因并不在浏览器，而是 调用链更长：浏览器→ xdg-desktop-portal → GNOME 文件选择器 → Nautilus → Tracker → 文件系统。这个过程中每一层都要做权限校验、进程通信、查询索引 / 元数据。导致文件选择窗口打开巨慢。这不是 Chrome 或者 Firefox 的锅，而是桌面架构本身的问题。
经过一系列搜索及尝试，终于找到了一个可行方案，虽然不能像windows那样流畅，但是至少不会有十几二十秒甚至直接卡死的情况了。以下是解决方案。
解决方案：
1. Tracker3
Tracker 带来的“全文搜索”对我几乎没用，但性能影响巨大，所以直接禁用。
# 停止 Tracker 服务 systemctl --user stop tracker-miner-fs-3.service systemctl --user stop tracker-extract-3.service # 防止开机自动启动 systemctl --user mask tracker-miner-fs-3.service systemctl --user mask tracker-extract-3.service验证是否生效：
systemctl --user status tracker-miner-fs-3如果看到类似dead或者stop等字样，说明禁用成功。禁用后有什么不良影响吗，有，但是通常不重要。禁用后GNOME 全局搜索无法搜索“文件内容”，只能按文件名，但是不影响文件读写、不影响开发、不影响终端工具。对开发者 / 高性能桌面用户来说，这是净收益。
2. 禁用部分缩略图，只对 ≤100MB 的文件生成缩略图
我并不想完全关掉缩略图，于是采用 GNOME 支持但默认没调好的方案：
# 只对本地文件生成缩略图 gsettings set org.gnome.nautilus.preferences show-image-thumbnails 'local-only' # 限制缩略图生成文件大小（MB） gsettings set org.gnome.nautilus.preferences thumbnail-limit 100含义很关键：小图片 / 小视频：正常显示缩略图。但是对于大视频 / 大素材 / 大 PDF：不再阻塞文件夹打开。这是一个性能和体验的最佳平衡点。设置后重启文件管理器即可：
nautilus -q现在即可测试下，如果速度满是慢，直接重启系统。体验下速度飞升的感觉吧。