企业官网建设流程全解析

• 桌面应用
• CLI

导读

Ludusavi 是一款跨平台、跨平台的 PC 游戏存档备份工具。本文围绕其「重定向（Redirects）」机制展开：当存档的备份位置与原始位置不一致时，如何通过配置重定向规则，让备份与恢复过程自动完成路径映射。读完本文，你将掌握三类重定向（Backup / Restore / Bidirectional）的适用场景、GUI 与配置文件中的完整配置方式，以及重定向链式处理的顺序规则——包括应对链式双向重定向恢复错位的「恢复时反转顺序」选项。

Redirects 是什么

Ludusavi 默认在扫描到游戏存档后，将文件原样写入备份目录，恢复时也原样写回原路径。但现实中常出现两种情况：

1. 存档原来在C:/Games，后来你把整个目录迁移到了D:/Games，备份里记录的还是旧路径；
2. 同一份存档在多台电脑、多个用户目录之间流转，路径前缀不同，但内容完全一致。

重定向（Redirect）就是为了解决这类「备份/恢复目标位置 ≠ 原始文件位置」的问题。在 docs/help/redirects.md 中，Ludusavi 明确将重定向定义为：使用重定向，你可以把数据备份或恢复到与原始文件不同的位置。

从实现上看，重定向作用于每一个被扫描的存档文件：在 src/scan.rs 的game_file_target函数中，原始路径会依次经过所有用户配置的重定向规则，通过前缀替换（redirected.replace(source, target)）生成最终的有效目标路径，并交由后续的备份/恢复逻辑使用。

在 GUI 中配置重定向

重定向在 Ludusavi 图形界面中集中管理。入口位于「Other（其他）」页面（对应 src/gui/screen.rs 的other界面），操作方式是：

1. 进入「Other」页面；
2. 点击加号（+）按钮添加一条新的重定向规则；
3. 为这条规则填写两个字段：
   • Source（源）：备份执行时的原始位置；
   • Target（目标）：新的位置。

界面实现位于 src/gui/editor.rs：每条规则包含一个类型下拉框（可选值来自RedirectKind::ALL）、Source 输入框、Target 输入框、两个「选择文件夹」按钮以及删除按钮；同时 Source / Target 输入框接入了撤销/重做历史（RedirectHistory，见 src/gui/shortcuts.rs），误操作时可以回退。

界面文案可在 lang/en-US.ftl 中看到：field-redirects = Redirects:、field-redirect-source、field-redirect-target，以及类型名称redirect-bidirectional = Bidirectional和选项reverse-redirects-when-restoring。

三种重定向类型

每条重定向都有「类型（kind）」，决定它在备份与恢复两个阶段各自如何生效。依据 docs/help/redirects.md 与 src/resource/config.rs 中的RedirectKind枚举，共有三种：

默认类型是Restore（RedirectKind的#[default]标注，以及 docs/schema/config.yaml 中kind的默认值restore均可印证）。

底层方向逻辑在 src/scan.rs 中一目了然：

let (source, target) = match scan_kind { ScanKind::Backup => match redirect.kind { RedirectKind::Backup | RedirectKind::Bidirectional => (&redirect.source, &redirect.target), RedirectKind::Restore => continue, // 备份阶段跳过 Restore 规则 }, ScanKind::Restore => match redirect.kind { RedirectKind::Backup => continue, // 恢复阶段跳过 Backup 规则 RedirectKind::Restore => (&redirect.source, &redirect.target), RedirectKind::Bidirectional => (&redirect.target, &redirect.source), }, };

值得注意的是，代码中还会跳过 Source 或 Target 为空字符串的规则（redirect.source.raw().trim().is_empty()），因此配置时务必保证两个字段都填写完整。

两个典型应用场景

场景一：目录迁移后的恢复重定向

假设你之前从C:/Games备份过存档，随后把整个目录搬到了D:/Games。此时创建一个Restore 类型的重定向即可让旧备份恢复到新位置：

• Source：C:/Games
• Target：D:/Games

恢复时，备份中的C:/Games/xxx路径会被自动改写为D:/Games/xxx，无需重新备份。

场景二：两台电脑共享同一份备份

假设你在两台电脑上玩同一个游戏，用户名分别是 "A" 和 "B"，存档路径分别为C:/Users/A与C:/Users/B，其余内容完全一致。希望两台电脑共用同一份备份时，可以创建两条Bidirectional重定向：

• 电脑 A：SourceC:/Users/A，TargetC:/Users/main
• 电脑 B：SourceC:/Users/B，TargetC:/Users/main

这样两台电脑的备份都会以虚构用户 "main" 的路径为基准，备份完全一致、可互相复用；而恢复时，Bidirectional 规则会把C:/Users/main重新映射回各自电脑的真实用户目录，实现「统一备份、各自归位」。

重定向的处理顺序（Sequence）

重定向按列表从上到下依次处理，且前一条规则产生的输出会继续参与后一条规则的处理（见 docs/help/redirects.md）。这正是它能够支持「链式映射」的原因。

官方示例：存档位于C:/Title/save.dat，配置两条双向重定向：

1. C:/Title→C:/Games/Title
2. C:/Games→D:/Games

备份时的变换链为：

C:/Title/save.dat → C:/Games/Title/save.dat → D:/Games/Title/save.dat

在 src/scan.rs 的实现中，可以看到每条规则依次执行redirected.replace(source, target)，后一条规则确实作用在前一条的输出上。

恢复时的顺序与「反转」选项

默认情况下，恢复阶段使用与备份相同的顺序。对于链式双向重定向，这可能产生不符合预期的结果：

• 备份路径：D:/Games/Title/save.dat（已按上文链式映射）；
• 恢复时若仍按原顺序执行，D:/Games/Title/save.dat不会触发第一条规则（因为前缀不匹配C:/Title），最终只会被还原到C:/Games/Title/save.dat，而不是C:/Title/save.dat。

解决方案是启用「恢复时反转重定向的顺序（reverse sequence of redirects when restoring）」选项。勾选后，恢复阶段会从列表底部向上逐条反向应用规则，从而正确还原出原始路径。该选项在源码中体现为：当处于恢复模式且开启反转时，迭代器使用redirects.iter().rev()（见 src/scan.rs）。

在配置文件中，该选项对应restore.reverseRedirects，默认值为false（见 docs/schema/config.yaml 与 docs/schema/config.yaml）；GUI 中的开关文案是「Reverse sequence of redirects when restoring」（lang/en-US.ftl）。

在 config.yaml 中配置重定向

重定向不仅可以通过 GUI 管理，也能直接写入 Ludusavi 的配置文件config.yaml（其完整结构定义见 docs/schema/config.yaml 与 docs/help/configuration-file.md）。

顶层redirects是一个数组，每个元素（RedirectConfig）包含三个字段（docs/schema/config.yaml）：

kind的合法取值为backup、restore、bidirectional（camelCase 命名）。一个完整的示例：

redirects: - kind: restore source: "C:/Games" target: "D:/Games" - kind: bidirectional source: "C:/Users/A" target: "C:/Users/main" - kind: bidirectional source: "C:/Users/B" target: "C:/Users/main" restore: reverseRedirects: false

对应的 Rust 数据结构定义在 src/resource/config.rs，其中source与target均使用StrictPath类型保存，序列化时自动转为 camelCase 的redirects键名。命令行（CLI）模式同样会读取配置文件中的redirects与restore.reverse_redirects并传给扫描流程（见 src/cli.rs）。

用预览验证重定向效果

官方文档特别建议（docs/help/redirects.md）：编辑重定向时，先运行一次预览（Preview），并展开部分游戏的文件列表查看。这会直观显示每条重定向在真实执行时的映射结果，避免恢复后才发现路径不对。

• 在 CLI 输出中，被重定向的文件会显示Redirected from: ...或Redirecting to: ...标记（lang/en-US.ftl）；
• 在 GUI 文件树中，重定向前后的路径会以徽章形式标注，如FROM: {path}与TO: {path}（lang/en-US.ftl）；
• 在 API 输出结构中，若某文件被恢复到了重定向位置，则originalPath记录其原始路径；若被备份到了重定向位置，则redirectedPath记录其在备份中的位置（docs/schema/general-output.yaml）。

补充：自动 Wine/Windows 重定向

除了用户手动配置的规则，Ludusavi 还内置了一种自动生成的跨平台路径映射：scan.redirectWine选项（默认false，见 docs/schema/config.yaml）。开启后，扫描过程中会基于源环境的元数据（semantic::Wine，见 src/scan/layout.rs）生成「尽力而为」的 Windows/Wine 路径重定向，用于在 Linux（Wine/Proton）与 Windows 之间迁移存档。它与用户手动配置的重定向相互独立：在 src/scan.rs 中，只有用户规则没有改变路径时，才会尝试生成这类语义级恢复重定向。

最佳实践小结

1. 方向要对：只影响备份用Backup，只影响恢复用Restore，备份/恢复对称且希望多机共享时用Bidirectional；
2. 顺序即优先级：规则按从上到下依次叠加，链式映射时务必把「更通用的前缀」放在后面（如C:/Title → C:/Games/Title之后才是C:/Games → D:/Games）；
3. 恢复场景考虑反转：若配置了多条链式 Bidirectional 重定向，恢复时建议勾选「恢复时反转顺序」，并在预览中确认最终落点；
4. 先预览后执行：每次改动后都用 Preview + 展开文件列表核对路径映射，再执行真实备份或恢复；
5. 字段不能留空：源码实现会跳过 Source / Target 为空的规则，避免无效配置干扰后续规则。

重定向是 Ludusavi 处理「存档路径漂移」的核心手段，配合预览机制与 CLI/配置文件支持，可以安全地覆盖目录迁移、跨用户共享、跨系统恢复等常见备份运维场景。相关底层实现可继续查阅 src/scan.rs、src/resource/config.rs 与 docs/schema/config.yaml。

• 桌面应用
• CLI