企业官网建设流程全解析

1. 先给结论：~/.local能删，但"整个删掉"和"删对地方"完全是两码事

~/.local文件夹一口气占了 22G，这个场景我太熟了。第一次在自己的 Arch 系机器上跑du -sh ~/.local看到那个数字的时候，我的第一反应也是"这玩意儿是不是可以一刀切了"。结论先摆在这里：可以删，但绝对不能整个目录rm -rf。原因很直白——~/.local不是某一个软件的临时目录，它是 XDG 基础目录规范划给"用户级应用数据"的那块地盘，里面装着的东西从密码钥匙环到你自己装的 Python 命令行工具，从 Flatpak 应用本体到回收站里上周删掉的那批文件，全都塞在这一个树形结构里。你把它整体删掉，系统不会立刻崩，但接下来几天你会陆陆续续发现：终端里某个命令找不到了、桌面菜单里的图标少了一半、某个应用的登录状态没了、浏览器保存的密码要重新输一遍。

真正该做的动作是先分清哪些是"可再生"的、哪些是"删了就回不来"的，然后只对前者下手，对后者做迁移而不是删除。这篇东西我想把整个判断链路摊开讲：从~/.local的目录语义开始，到怎么在几分钟内定位那 22G 到底堆在哪几个子目录，再到每一类内容该怎么处置、怎么搬到别的分区、搬完怎么验证没搬坏。中间我会把踩过的坑一并写进去，尤其是那几个看起来人畜无害、删完却让你想砸键盘的目录。

对于刚接触 Linux 桌面不久的朋友，这篇能当一份"清理前的安全手册"用；对于已经在用du、ncdu这些工具的老手，中间关于 Flatpak 用户级安装、rootless 容器存储、KDE 索引库这几段的体积构成分析，应该也能帮你省下几次无效排查。22G 这个量级在桌面机器上不算离谱，但它的成因往往出人意料——我自己那次最大的单个目录是 8.6G，而它压根不是我手动装的任何东西。

2. 拆开看：XDG 规范把用户数据摊成了哪几摊

2.1 五个环境变量决定了数据往哪写

要判断一个目录能不能删，得先知道它为什么存在。Linux 桌面这套东西遵循XDG Base Directory Specification，规范里明确规定了五类用户数据各自的落脚点，绝大多数现代应用（包括 GNOME、KDE 自家的组件）都认这套约定。把这几个变量搞清楚，你看到任何一个陌生路径都能立刻判断它的性质：

这张表里最关键的一行是最后一行之外的隐含信息：~/.local同时承载了share、state、bin三个完全不同性质的目录，外加一个不太常被提到但确实存在的~/.local/lib（用户级库文件，主要是 Python 的--user安装产物）。一个目录里混着三类数据，这就是为什么"整体删除"这个念头很危险——你没法用一条规则覆盖三种语义。

我见过不少人把~/.local和~/.cache搞混，觉得"反正都是隐藏目录，都是缓存"。差别大了去了。~/.cache你随便删，删完应用下次启动自己重建，最多第一次打开慢一点。~/.local/share删了就是删了，很多应用不会给你重建的机会，它只会觉得"这是个新用户"。

2.2share和state的实际差别在哪

规范上的定义比较抽象，落到实操上可以这么理解：share里放的是应用认为有价值、需要长期保存的东西，state里放的是有保存价值但丢了也不致命的东西。举个具体例子，一个聊天类应用会把聊天记录数据库放在~/.local/share/下，把窗口位置、上次打开时间这类信息放在~/.local/state/下。前者删了聊天记录没了，后者删了下次打开窗口位置重置一下而已。

我在实际清理时的经验是：state目录几乎从来不是体积大户，它通常是几百 KB 到几十 MB 的量级，因为里面主要是文本日志和小型状态文件。22G 这种规模，99% 的嫌疑都在share下面。所以第一刀切分应该是先du -sh ~/.local/share ~/.local/state ~/.local/bin ~/.local/lib，看一眼比例，然后专心对付share。

至于~/.local/bin，它在你的PATH里（大多数发行版默认会加），里面可能是pipx装的命令行工具、自己写的脚本、AppImage 的软链。这个目录通常很小，几 MB 到几十 MB，删了不影响系统，但你会突然发现poetry、black、http这些命令全没了。我这边的习惯是把它当作"工具箱"看待，清理前先ls ~/.local/bin扫一眼，把还想要的记下来。

2.3 为什么 Arch 系机器上这个目录特别容易膨胀

滚动发行版有个特点：软件更新频繁，而很多"用户级"的包管理器会不断往~/.local/share里堆历史版本。Flatpak 是最典型的例子，它在用户级安装时默认把整个运行时和应用的 ostree 对象库放在~/.local/share/flatpak，每次更新不是覆盖而是新增对象，旧的靠--unused手动回收。你不主动清理，它只增不减。

再加上 Arch 系用户普遍喜欢尝鲜，Steam、各种 Electron 应用、开发工具链一起上，~/.local/share里长到十几二十 G 完全是常态。我在 Manjaro 这类发行版上看到的规律是：装得越杂，share越大；越不爱清缓存，增长越快。而~/.cache反而因为大家知道它能删，常常保持得比较干净。这有点反直觉——真正该定期看的是share，不是cache。

3. 22G 的构成画像：按嫌疑度排序的排查表

3.1 我统计过的一份典型分布

先给一份参考画像。我把自己和周围几个开发者的机器上~/.local/share的超大子目录做过一次汇总，22G 这个量级通常长这样：

这份表最有用的地方在于它揭示了"体积与危险度不成正比"这个反常识现象。keyrings只有几十 KB，但它可能是整个~/.local里最不能碰的东西——删了它，你系统里所有"记住密码"的应用（浏览器、邮件客户端、Git 凭据管理器、SSH 密钥口令）全部失效，而且不是简单重输一遍就完事，某些应用会直接报错打不开。

3.2 几个容易误判的"伪嫌疑犯"

排查时还有几个目录经常被误伤，我单独拎出来说。第一个是~/.local/share/applications，体积通常只有几百 KB，看起来毫无价值，但它存的是你手动添加的桌面菜单项和mimeapps.list（默认应用关联表）。删了之后，双击 PDF 用什么打开、右键"用 XX 打开"里有哪些选项，全部回到默认状态，得重新配一遍。

第二个是~/.local/share/icons和~/.local/share/fonts，这俩是你自己装的图标主题和字体的落点。体积可能几百 MB，属于"删了能用但丑了"的类型，不推荐动。第三个是~/.local/share/recently-used.xbel，一个记录最近打开文件的 XML，通常几十 KB，删了不影响任何功能，属于随手的清理对象。

还有个特别隐蔽的：~/.local/share/Trash下面有两个子目录，files和info。只看du -sh ~/.local/share/Trash可能显示 3G，但如果你只删info不删files，文件本体还在，空间一点没释放。反过来只删files，info里的元数据就成了孤儿。正确做法是用gio trash --empty或者trash-empty这类专门命令一次性清干净，别手动rm。

3.3 开发工具链的隐藏体积

如果你是开发者，还有几个大户值得单独查。~/.local/share/virtualenvs是 pipenv 的默认虚拟环境位置，每个项目的依赖全套独立安装一份，项目多了轻松上 G。~/.local/share/pipx是 pipx 装的命令行工具本体，每个工具一个独立 venv，看着小但架不住数量多。~/.local/share/JetBrains是 IDE 的索引与插件缓存，大型项目索引能到几个 G。

还有一类特别容易被忽略：Electron 系应用的用户数据。很多 Electron 应用把userData目录设在~/.local/share/<应用名>下，里面包含 IndexedDB、Local Storage、缓存快照。这些目录单个可能几百 MB，装十个八个就是好几个 G，而它们既不是你能随便删的（删了要重新登录、丢本地草稿），也不是必须留的（缓存部分可以清）。这种就得进到应用内部的设置里找"清除缓存"，或者只删其中明确标注为 cache 的子目录。

4. 定位实操：从du到ncdu的四步收网

4.1 第一步：先看总量分布，锁定主战场

排查永远从粗到细。第一条命令是看~/.local下一层的分布，注意-x参数（不跨文件系统）在这里不重要，因为~/.local通常在同一分区，但加上更保险：

du -h --max-depth=1 ~/.local 2>/dev/null | sort -hr

输出会按体积倒序列出share、lib、state、bin各自的占用。绝大多数情况下share会吃掉 95% 以上。确认这一步之后，把火力集中过去：

du -h --max-depth=1 ~/.local/share 2>/dev/null | sort -hr | head -25

head -25是个实用习惯——share下可能有上百个子目录，看前二十几个就够定位了，剩下的加起来往往不到总量的 5%。我自己的经验是，前五个目录通常能覆盖 80% 以上的体积，如果前五个加起来还不到一半，说明体积是"平均分布"型的，那多半是某些应用在到处撒数据，得换个思路查。

4.2 第二步：ncdu交互式下钻，比du省心得多

du适合拿快照，真要一层层往下钻，用ncdu效率高一个数量级。它是 TUI 界面，方向键进出目录，按d能直接删（这个键我要重点提醒：默认行为是直接删，不进回收站，别手滑），按g切换显示百分比/大小/数量，按n按体积排序。

ncdu -x ~/.local/share

-x的意义是不跨越文件系统边界。这条参数在你做过 bind mount 或者软链迁移之后特别关键——如果一个子目录已经挂到了另一块盘上，没有-x的话ncdu会把它算进来，你会看到一个数字巨大但你根本删不掉任何东西的目录。装的话，Arch 系一条sudo pacman -S ncdu就完事。

用ncdu的时候有个技巧：进到某个可疑目录后按c看条目数，按a看"实际占用 vs 表观大小"。两者的差值大，说明该目录里有大量稀疏文件或者硬链接，比如容器镜像的 overlay 层、虚拟机磁盘文件。这时候删掉它释放的空间可能远小于显示的数字，别被误导。

4.3 第三步：抓大文件，直捣黄龙

有时候体积不是被"很多小文件"堆起来的，而是几个巨型文件。这种用find直接捞：

find ~/.local -xdev -type f -size +500M -printf '%s\t%p\n' 2>/dev/null | sort -nr | head -30

-printf '%s\t%p\n'输出的是字节数加路径，sort -nr按数值倒序，这样最大的排最前面。-size +500M这个阈值可以按需调，22G 的场景我建议直接从 1G 起步筛，命中率更高。这条命令的威力在于它能立刻暴露那些藏在深层目录里的大家伙——比如某个容器镜像的 tar 包、某次数据库备份的 dump 文件、Steam 的着色器缓存包。

顺手再查一个常被忘记的：孤立的符号链接和空目录。它们不占空间，但会让你的目录树看起来很乱，find ~/.local -xtype l能列出所有断链，清理时顺手删掉。

4.4 第四步：交叉验证，别只看一个数字

定位到具体目录后，别急着删，先做个交叉验证。做法是：拿du的结果和该应用自己的"关于/存储占用"界面对一下，看看数字是否吻合。如果差得远，说明该目录里可能有硬链接共享（容器镜像常见），或者有被删除但进程还占着的文件。

后者是个经典坑：你用rm删了某个大文件，但持有它的进程还没退出，du看不到它了，可df显示空间没释放。查这种"幽灵文件"：

lsof +L1 2>/dev/null | head -20

输出里能看到被删除但仍被占用的文件句柄和对应进程。解决办法是把那个进程重启或者杀掉，空间立刻回来。我自己遇到过一次：某个后台服务把日志文件写到了~/.local/state下，我删了文件但服务没重启，df上那 2G 一直挂着，查了十分钟才想起来这一出。

5. 分类处置清单：哪些直接删、哪些一个字都别动、哪些该搬走

5.1 放心删：可再生或本就该消失的东西

先给能痛快下手的清单。回收站是第一顺位，gio trash --empty一条命令解决，删之前如果想留个心眼，可以先用du -sh ~/.local/share/Trash/files看一眼体积，心里有数。baloo索引库也可以直接删，KDE 的语义搜索索引，删了之后文件管理器首次启动会重建，代价是那段时间搜索变慢，功能不受影响。

各级缓存性质的子目录都算这一类。比如各种 Electron 应用里的Cache、Code Cache、GPUCache，Flutter/Dart 的Pub/Cache，~/.local/share/Steam/steamapps/shadercache（着色器缓存，删了游戏首次启动会重新编译，慢一次而已）。判断标准很简单：这个目录删掉后应用重新启动能不能自己生成出来——能，就可以删。

还有一类是卸载不干净留下的残骸。你卸载了某应用，但它的用户数据还在~/.local/share下留着。这种可以通过对比"当前安装的应用列表"和"share下的目录列表"找出孤儿。Arch 系上pacman -Qqe列出手动安装的包，再ls ~/.local/share对一遍，名字对不上且自己也认不出来的，基本可以判定是残留。删之前最好先mv到一个临时目录观察一周，别直接rm。

5.2 千万别动：体积小但杀伤力极大

这份清单不长，但每一条我都建议你刻在脑子里。keyrings/前面说过，存着所有"记住密码"的加密凭据，删了之后应用级的凭据全部失效，某些加密钱包类工具甚至会因为找不到密钥直接拒绝启动。applications/存用户级.desktop文件和默认关联，删了桌面菜单和你自定义的"用 XX 打开"选项全没。

~/.local/share/dbus-1/和~/.local/share/polkit-1/这两个很少被提到，但如果里面有内容（某些应用会写会话级的服务定义），删了会导致相关功能静默失效，而且极难排查——你不会看到任何报错，只是某个操作就是没反应。gnupg/如果存在于这个位置（有些配置会把它指过来），那是 GPG 密钥环，删了等于把加密身份扔了。

还有个容易忽略的：~/.local/share/mime/。这是用户级的 MIME 类型数据库，删了之后文件关联会乱，图标也可能显示异常。体积通常只有几 MB，完全不值得动。

提示：在动手之前，先把~/.local/share/keyrings、~/.local/share/applications、~/.local/share/mime这三个目录打个包备份到别的盘上。命令是tar -C ~/.local/share -czf /path/to/backup/local-critical.tar.gz keyrings applications mime，总共不到 10MB，但能救你一次重装。

5.3 该搬走：留在系统盘就是浪费

第三类是最值得花时间的——体积大、访问频率低、且路径可配置。这类东西的正确处置不是删，是搬到数据盘上然后做个链接指回来。典型的候选：

• flatpak/：用户级 Flatpak 的全部数据，几 G 到十几 G，一年也未必打开几次那些应用
• Steam/steamapps/：游戏本体，几十 G 都正常
• containers/：rootless 容器的镜像和层，开发用完就该清或者搬走
• lib/python3.*/site-packages：如果--user装的包很多，这个也能搬
• virtualenvs/：pipenv 的虚拟环境，纯开发产物

搬家前先确认这个目录没有正在运行的进程持有文件句柄。查法：lsof +D ~/.local/share/flatpak 2>/dev/null | head，有输出就说明还在用，先退出相关应用。这一步跳过的话，mv会失败或者搬出个半残状态。

6. 搬家而不是删除：软链接与 bind mount 的取舍

6.1 软链接方案：简单但有边界

最轻量的搬家方式是软链接。三步走：先mv到目标位置，再在原路径建链，最后验证应用能正常读到。

# 假设目标盘挂在 /data mkdir -p /data/userdata mv ~/.local/share/flatpak /data/userdata/flatpak ln -s /data/userdata/flatpak ~/.local/share/flatpak

软链接的好处是零配置、随时可逆、出问题一条rm加mv就回滚。缺点是有些应用会主动检查路径是否为符号链接然后拒绝工作，或者在某些沙箱环境下解析不到真实路径。Flatpak 本身对软链是容忍的，我用这个方案挂过一段时间没问题；但容器运行时（尤其是 rootless 的 overlay 存储）对软链就比较敏感，容易出现"存储驱动报错"这类问题。

还有一个隐性问题：软链接会让某些备份工具和du的行为变得不直观。备份时如果用了-L（跟随链接），会把数据盘的内容也备一遍，体积翻倍；不用-L又只备了个链接，恢复时数据全无。这一点在做定期备份脚本时务必想清楚。

6.2 bind mount 方案：更彻底，应用完全无感

要让应用彻底感知不到路径变化，用 bind mount。它是在挂载层面把一个目录"镜像"到另一个路径，对上层完全透明，lstat拿到的就是普通目录。

临时挂载（重启失效，适合先试试水）：

sudo mkdir -p /data/userdata/flatpak sudo mount --bind /data/userdata/flatpak ~/.local/share/flatpak

确认没问题后写进/etc/fstab固化。注意 fstab 里的路径不能写~，必须写绝对路径，而且user那一项要换成你自己的用户名：

/data/userdata/flatpak /home/yourname/.local/share/flatpak none bind 0 0

bind mount 的坑在于挂载顺序。如果目标路径所在的分区（比如你放数据的那块盘）在启动时挂载失败，~/.local/share/flatpak就会变成一个空目录，应用会以为"用户数据全没了"，直接初始化一份新的。等你下次把数据盘挂回来，两个版本就对不上了。所以我建议在 fstab 里加上nofail之外的兜底——或者干脆用systemd的自动挂载单元，配合依赖关系确保顺序。

注意：用 bind mount 之后，du -x ~/.local/share/flatpak会显示实际占用，但du -sh（不加-x）不会跨越挂载点，结果是 0 或者很小。别被这个数字误导以为搬家失败。

6.3 用应用自己的配置项搬家，最省事

有些应用本身就支持改数据目录，这是最干净的方案，不用折腾链接和挂载。Flatpak 可以用flatpak --installation=...或者直接设置FLATPAK_USER_DIR环境变量指定用户级安装目录；Python 的--user安装可以用PYTHONUSERBASE改根路径；pip 的缓存位置用PIP_CACHE_DIR控制。

# 让 flatpak 的用户级安装落到数据盘 export FLATPAK_USER_DIR=/data/userdata/flatpak

环境变量写在~/.config/environment.d/下的.conf文件里，桌面会话启动时会读取。这个方案的优势是应用全程按正常路径读写，没有任何链接层，沙箱和权限检查都不会有意见。缺点是并非所有应用都提供这种可配置项，得逐个查文档。

我的实际选择是混着来：Flatpak 用环境变量，Steam 用软链接（它自己有库文件夹管理功能，其实更推荐直接在 Steam 设置里添加数据盘作为库目录，那样连链接都不用），容器存储用 bind mount。三种方案各用其所，没有哪个是万能的。

7. 删错之后的症状对照与抢救

7.1 症状对照表：出了问题怎么快速定位

万一已经删了，别慌，先按症状对照定位到底缺了什么。这张表是我自己攒的，每次帮人抢救都翻它：

表里"最痛"的一行是 Flatpak 那条。因为 Flatpak 的应用数据和应用本体是绑在一起的，删了flatpak/目录之后，你的应用列表、每个应用的设置、本地文件全没了，重装只能装回空壳。这也是我为什么在前面反复强调这个目录只能搬不能删。

7.2 密钥环被删的重建流程

这个场景值得单独展开，因为它最容易触发且最让人抓狂。删掉~/.local/share/keyrings/之后，你的凭据管理器变成空的了，所有之前"记住密码"的应用会弹窗要求重新输入。有些应用很友好，输一次就存回去；有些则直接报"无法访问密钥环，请检查配置"，因为它连加密存储的容器都找不到了。

重建的做法是先让gnome-keyring或kwallet重新初始化一个空存储：

# GNOME 系 mkdir -p ~/.local/share/keyrings # 下次登录时会自动提示设置新的登录密钥环 # KDE 系 # 打开"系统设置 -> KDE 钱包"，新建一个钱包，类型选 Blowfish 或 GPG

新建之后，逐个打开需要凭据的应用重新登录一次，密码就会重新写进去。整个过程十分钟左右，但那些你自己都想不起来密码的账号会比较麻烦——这也算是删除前先把密码管理器导出一次的理由。

7.3 从备份恢复的最小操作

如果动手前按我前面说的打了那个 10MB 的包，恢复就很快：

# 先看备份里有哪些东西 tar -tzf /path/to/backup/local-critical.tar.gz | head -20 # 恢复到原位置（会覆盖同名文件，注意） tar -C ~/.local/share -xzf /path/to/backup/local-critical.tar.gz

恢复 keyrings 之后有一个细节：文件权限必须对。密钥环文件的权限是600，属主是你自己。如果解包时用了sudo或者从别处复制过来导致权限变成644甚至属主是 root，密钥环守护进程会拒绝加载，症状是"明明恢复了但应用还是提示找不到密钥"。修法：

chmod 700 ~/.local/share/keyrings chmod 600 ~/.local/share/keyrings/*

这个坑我踩过一次，当时排查了快一个小时才想起来看权限。类似的问题在~/.local/state下也可能出现，某些服务对状态目录的权限同样敏感。

8. 长期治理：让~/.local不再失控的几个习惯

8.1 给"体积监控"建个基线

清理只是治标，不建立监控的话，三个月后你还会看到同样的 22G。我的做法很简单：写一个极小的脚本，每周跑一次，把~/.local/share下前十个子目录的体积记到一个日志文件里。这样做的价值不是"及时清理"，而是能看出增长趋势。某个目录从 500M 涨到 2G，你会立刻注意到并去查原因；如果只在涨到 20G 时才看，就已经失去观察窗口了。

#!/usr/bin/env bash # ~/.local/bin/local-size-watch LOG="$HOME/.local/state/local-size-watch.log" echo "=== $(date '+%F %T') ===" >> "$LOG" du -h --max-depth=1 "$HOME/.local/share" 2>/dev/null | sort -hr | head -10 >> "$LOG"

配合cron或者systemd定时器每周跑一次，日志攒半年就能看出规律。我自己那份日志里最明显的规律是：每次大版本升级后flatpak/会跳一截，然后稳定下来。知道这个之后，我就养成了升级完顺手跑一次flatpak uninstall --unused的习惯。

8.2 把"清理"拆成月度小动作而不是年度大手术

比起攒到 22G 再兴师动众地排查，我更推荐把清理拆成几个一分钟就能做完的动作，按月执行。清单如下，都是低风险操作：

• flatpak uninstall --unused：清掉不再被依赖的运行时，通常能回收几百 MB 到几 G
• gio trash --empty：清空回收站
• pip cache purge：清 pip 下载缓存（这个在~/.cache，但顺手）
• pipx reinstall-all --force之前先pipx list看一眼有没有已经不用的工具，卸载掉
• podman system prune -a（如果你用 rootless 容器）：清掉所有未使用的镜像和层
• 检查~/.local/share/virtualenvs下有没有对应项目已经删掉的孤儿环境

这一套下来通常每月能控制住增长，不会出现"突然发现 22G"这种惊吓。关键是这些命令全都可逆或者低风险，不像rm -rf那样一失手成千古恨。

8.3 该不该把share也定期整体备份

最后说个策略层面的判断。~/.local/share值得备份吗？我的答案是部分值得，具体就是前面反复强调的那几个小目录（keyrings、applications、mime，如果你用 KDE 再加上kwalletd相关配置），加起来不到 20MB。其余的（Flatpak 应用、Steam 游戏、容器镜像、Python 包）全都可以重新拉一遍，备份它们纯属浪费空间和时间。

真要给整个家目录做备份的场景，我建议在备份工具里显式排除这几个大户。rsync的话用--exclude一条条排除，或者更省事的做法是用--exclude-from读一个排除列表文件：

# excludes.txt .local/share/flatpak/ .local/share/Steam/steamapps/ .local/share/containers/ .local/lib/python3.*/site-packages/ .cache/

这样一份家目录备份能从几十 G 压缩到几 G，备份时间从一小时降到十分钟，恢复的时候也快得多。我现在的做法是排除列表 + 关键目录单独打包，两条线并行，既不丢重要的，也不浪费时间备没用的。

最后分享一个我用了很久的小习惯：每次准备对~/.local动手之前，先跑一条du -sh ~/.local把当前数字记在便签上，清理完再跑一次，两个数字一减就是你实际回收的空间。这个动作看起来多余，但能帮你逐步建立起"哪类操作真正有效"的直觉——我最初几次清理完发现只回收了 200M，才意识到自己一直在清那些本来就不大的缓存，真正的大头根本没碰。有了这个反馈闭环，后面每一次清理的命中率都会明显提升。