企业官网建设流程全解析

Amethyst Mod Manager 是一款专为 Linux 打造的跨游戏模组（Mod）管理器，支持近 100 款游戏。除了常见的符号链接、硬链接部署之外，它还提供了一种VFS（虚拟文件系统）部署：你的真实游戏目录在整个游戏过程中保持原样，游戏实际读取的是 Amethyst 为每个配置档（Profile）生成的"私人游戏视图"。这套机制由 3 种后端实现——shadow-tree、kernel-overlayfs、fuse-overlayfs。本文用尽量少的术语，带你搞懂它们各自如何工作、何时使用，以及为什么你的游戏目录从此不再"越玩越乱"。

为什么游戏目录总会变乱？

Mod 管理器的核心难题之一是：游戏运行期间会不断往安装目录里写文件（日志、缓存、脚本扩展、生成的清单……），而 Mod 本身又要覆盖游戏自带的文件。如果所有东西都直接写进真实的游戏文件夹：

• 不同 Mod 列表之间切换时，残留文件会互相"污染"；
• 卸载 Mod 后不知道哪些是 Mod 放的、哪些是游戏运行时生成的；
• "还原（Restore）"很难做到干净利落。

传统做法是把 Mod 文件物理复制/链接进游戏目录，再用清单记录、最后逐一删除。而 VFS 的思路是反过来的：游戏启动时给它"看"一个由 Mod 组合成的虚拟视图，游戏以为自己在读真实目录，实际上真实目录一个字节都没被改动。这就是"目录保持整洁"的秘密所在。

先认识 Amethyst 的三种部署方式

在 Amethyst 的游戏配置界面中，你可以为每款游戏选择部署策略，其中 "VFS deploy" 选项就对应本文主角。相关说明可参考 README.md 中的 "Multiple Deploy methods" 特性，以及界面代码 src/gui_qt/configure_game_view.py。

VFS 部署状态下，Amethyst 会在配置档目录里创建一个.amethyst-vfs状态目录（定义见 overlay.py 第 59-73 行），里面保存着部署清单manifest.json、影子视图view/、上层写入目录、运行期快照等。整个状态都是配置档级别的：换一个 Profile，就换一套虚拟视图。

三种后端逐个拆解

三种后端的常量定义在 overlay.py 第 64-66 行：

1. shadow-tree：影子树 + 绑定挂载（默认）

这是目前最推荐、也是默认使用的后端，它的思路非常朴素：

1. 物化（Materialize）：部署时，Amethyst 在配置档内用硬链接（不支持时回退到符号链接/复制）拼出一棵完整的"影子游戏树"。硬链接只占用一份真实数据，所以几千个文件也不会额外占多少磁盘空间。构建过程由 build_layers() 完成，日志里会打印 "VFS deploy: resolving a private game view ..."。
2. 命名空间绑定：游戏启动时，Amethyst 用bubblewrap（bwrap）为游戏进程创建一个私有挂载命名空间，把影子树 bind 到游戏安装路径上。关键点是：只有被启动的游戏进程及其子进程能看到这个视图，系统其他部分看到的仍是原封未动的真实目录。核心包装逻辑在 wrap_command()。
3. 写入捕获：游戏在运行中产生的新文件落在影子树里。下次重新部署或清理时，Amethyst 会按部署时的快照（root-view-snapshot.txt、data-view-snapshot.txt）区分"部署产物"和"运行期新文件"，把后者收进配置档存储或Root_Folder/（见 _capture_shadow_runtime()）。

为什么不用真正的 OverlayFS 挂载而选择影子树？模块头部的注释（overlay.py 第 1-20 行）说得很清楚：让文件读取走内核原生文件系统，性能更好；UMU 和 Steam Linux Runtime 自身会创建挂载命名空间，嵌套在 bubblewrap 里反而可能让 Wine 启动崩溃——因此 UMU/Steam 启动时会直接跑完整影子树（"direct shadow"），不再套一层命名空间。

2. kernel-overlayfs：内核 OverlayFS（旧版）

旧后端利用 Linux 内核的 OverlayFS：下层（lower）是游戏原始目录 + Mod 层，上层（upper）收集写入，由 bwrap 的--overlay-src / --overlay参数在命名空间内完成挂载（见 wrap_command() 的 kernel 分支）。它对已部署的旧清单依然可读、可启动，也常作为诊断回退手段。新部署不会再走这条路径。

3. fuse-overlayfs：用户态 FUSE（旧版回退）

在无法使用内核 OverlayFS 的环境里（例如某些受限的发行版或容器），可以改用用户态的fuse-overlayfs工具完成同样的叠加挂载。Amethyst 会先检查bwrap、fuse-overlayfs、fusermount3、mountpoint、flock以及/dev/fuse是否可用（fuse_overlay_status()），就绪后由配套的 runtime.sh 脚本在宿主侧拉起挂载，再进入游戏进程。这条路径同样是兼容保留，默认后端仍是 shadow-tree。

一次 VFS 部署到底发生了什么？

把三个后端抽象开，一次 VFS 部署的流程大致是：

1. 写入pending标记，防止构建中途失败后状态不明；
2. 根据 Mod 列表、路由规则（routing rules）、自定义规则，把每个文件解析进root层或data层（Bethesda 系对应游戏根目录和Data目录两层结构）；
3. 物化出影子树view/，原子化地"轮换"旧视图（view.previous）并发布manifest.json；
4. 游戏专属钩子随后执行——链接plugins.txt、配置 INI、存档符号链接、RE 引擎 archive invalidation 等（见 ProfileVFSGameMixin._deploy_vfs()）；
5. 最后对影子视图做快照，日志收尾："VFS deploy complete ...the real game directory was not modified"。

部署失败时会自动回滚已经产生的物理副作用；即使中途断电，.amethyst-vfs里的标记也能让Restore（还原）操作把配置档恢复干净。整个过程由 src/Utils/vfs/ 模块驱动，公共 API 在init.py 中一览无余。

哪些游戏支持？如何开启？

游戏处理器通过混入ProfileVFSGameMixin来"举手报名"（game.py），目前包括：

• Bethesda 全系：Skyrim / Skyrim SE、Fallout 3/4/NV/76、Oblivion、Starfield 等；
• 赛博朋克 2077、RDR2、王国：两位君主 II（KCD2）、骑马与砍杀 2：霸主、星露谷物语、戴斯班克（Daggerfall Unity）、Slay The Spire 2、Subnautica（BepInEx 系），以及多款RE 引擎和UE5游戏。

开启方式很简单：在游戏配置里选择VFS deploy（内部对应设置项vfs_enabled，读写逻辑见 game.py 第 82-92 行），之后点击Deploy再点Play即可。开启 VFS 后，直接绕过 Amethyst 启动游戏会失效——因为虚拟视图只存在于 Amethyst 生成的启动包装里，这也是刻意的安全设计（native_launch_blocked_reason()）。

常见问题速查

• 提示 "bubblewrap (bwrap) is not installed"：安装发行版的 bubblewrap 包即可；AppImage 版本自带非特权回退实现。
• 提示 namespace 创建失败 / permission denied：通常是发行版限制了非特权用户命名空间，需要检查 user-namespace 相关设置与 AppArmor 策略（诊断信息见 _bubblewrap_namespace_status()）。
• Flatpak 版本：所有宿主工具检测都会通过flatpak-spawn在宿主侧进行，如果宿主缺少工具，诊断信息会明确列出缺失项。
• 配置档目录放在游戏目录里：会被直接拒绝（否则影子树会递归地把自己装进自己），需要把配置档/暂存目录移到游戏安装目录之外。

小结

Amethyst Mod Manager 的 VFS 子系统用一句话概括就是："游戏看的是幻影，目录留的是清白"。默认的 shadow-tree 后端以硬链接拼出完整的私人游戏视图，再借 bubblewrap 挂载命名空间对游戏"障眼法"；kernel-overlayfs 与 fuse-overlayfs 则作为兼容路径继续服务旧部署。无论哪种后端，你的真实游戏安装目录都不会被 Mod 和游戏运行时的写入弄脏——这就是游戏目录保持整洁的全部秘密。