企业官网建设流程全解析

OptiScaler Client 是一款现代化的 OptiScaler 管理工具，它的安装引擎通过备份清单（InstallationManifest）与外部备份库，在安装前完整备份游戏原始文件，并在安装失败或卸载时自动无损回滚，同时内置 UE5 目录智能探测机制，自动定位正确的游戏文件目录。本文带你读懂这三项核心机制的实现原理。

一、安装引擎要解决什么问题？

把 OptiScaler 装进游戏目录，本质上是一次"动游戏文件的手术"：要替换dxgi.dll等关键文件，还要新增配置和依赖。一旦中途断电、游戏文件被误删，普通用户几乎没有自救能力。

OptiScaler Client 的安装引擎用三层保险解决这个难题：

二、备份清单：一份会"记账"的安装档案

清单的核心是区分每个文件的两类身份，这是整个无损回滚的根基：

• FilesCreated（新建文件）：安装前不存在，卸载时直接删除
• FilesOverwritten（覆盖文件）：安装前就存在（游戏原始文件），先备份再覆盖，卸载时从备份恢复

每个变动文件都会记一条ManifestFileRecord（见 Models/InstallationManifest.cs#L5-L12），其中ExistedBefore标记文件是否原本存在，PreInstallSha256和PostInstallSha256则记录安装前后的 SHA-256 指纹——这份指纹就是后续"回滚是否真的干净"的验收凭证。

清单的生命周期：三态状态机

清单的OperationStatus字段（Models/InstallationManifest.cs#L33）只有三个取值：

1. in_progress：安装开始前就持久化落盘，中途崩溃也能留下"事故现场"
2. committed：全部文件处理成功后提交，代表一次合法安装
3. failed：出错时标记，触发自动回滚程序

这种设计意味着即使程序在安装到一半时闪退，下次启动也能识别出未完成的操作并自动收拾残局。

备份存在哪里？

备份并不放在游戏文件夹内，而是统一存放在外部备份库%APPDATA%\OptiscalerClient\Backups\{游戏标识}\（见 Services/BackupStoreService.cs#L31-L39）。

游戏标识由ComputeGameSlug生成（Services/BackupStoreService.cs#L298-L322）：取路径末两段的可读名称加 8 位 SHA-256 短哈希，例如bin_x64_3f7a2c1d——既有辨识度，又保证唯一。清单写入采用"先写.tmp临时文件再原子改名"的方式（Services/BackupStoreService.cs#L105-L116），避免写一半损坏档案。

🛡️ 另外还有一套残留探测：安装前会扫描游戏目录，凡是文件名属于 OptiScaler 专属（如OptiScaler.dll、fakenvapi.ini），或 SHA-256 与下载缓存中的文件完全一致的"孤儿文件"，会先清理掉，防止上一次没卸载干净的安装污染本次备份（Services/BackupStoreService.cs#L178-L213）。

📦 老用户的旧版备份（游戏目录里的OptiScalerBackup/文件夹）也会由启动迁移服务自动搬到外部备份库，且迁移幂等、不删除旧文件夹（Services/StartupMigrationService.cs#L49-L87）。

三、UE5 目录智能探测：先找对地方，再动手

现代游戏（尤其是 UE5/Phoenix 引擎项目）的可执行文件往往不在游戏根目录，而在Binaries\Win64之类的深层子目录。装错位置，OptiScaler 就完全无法生效。

第一优先级：Phoenix 目录规则

探测入口DetermineInstallDirectory（Services/GameInstallationService.cs#L1517-L1537）首先检查游戏根目录下是否存在Phoenix\Binaries\Win64且其中包含.exe文件——如果是，直接锁定该目录，跳过后续评分。

第二优先级：给所有 exe "打分"

找不到 Phoenix 结构时，引擎会扫描安装目录下的全部可执行文件并逐项打分：

Crash、Redist、Setup、Launcher、UnrealCEFSubProcess等明显不是游戏主程序的 exe 会被直接排除（Services/GameInstallationService.cs#L1564-L1571），得分最高者的所在目录就是安装目录。

把探测结果"钉死"在清单里

🎯 探测结果会写入清单的InstalledGameDirectory字段（Models/InstallationManifest.cs#L52-L57）。注释里写得很直白：对 UE5/Phoenix 游戏，这里存的是Phoenix\Binaries\Win64子目录而非根目录，卸载时直接读取该字段，避免二次探测失败导致恢复错目录。

四、无损回滚：失败时把目录恢复原状

回滚逻辑集中在 Services/GameInstallationService.cs 的RollbackFailedInstall，步骤与清单身份严格对应：

1. 删除FilesCreated中记录的每个新建文件
2. 恢复FilesOverwritten中记录的每个原始文件（从外部备份库拷回）
3. 回滚完成后删除本次备份库条目，游戏目录回到"从未安装"的状态

崩溃也能自愈

启动时若发现某游戏的清单停留在in_progress/failed状态，RecoverIncompleteInstallIfNeeded（Services/GameInstallationService.cs#L829-L887）会自动执行回滚并做二次校验，用户完全无感。

回滚后的"验收"

ValidateAndHealPostUninstall（Services/GameInstallationService.cs#L1029-L1126）是最后一道安全网：卸载结束后，对每个被覆盖文件重新计算 SHA-256，与清单里记录的PreInstallSha256逐一比对——指纹不一致或文件缺失，就从备份再恢复一次，直到与安装前状态完全一致。

升级场景的防覆盖细节

升级（覆盖安装）时有个隐蔽陷阱：备份库里的原始文件备份不能被 OptiScaler 自己的 DLL 冲掉，否则卸载时"恢复"回来的其实是 Mod 文件。引擎在安装前会先读取旧清单（Services/GameInstallationService.cs#L127-L155），把"游戏原始文件"和"OptiScaler 自建文件"分成两个集合：升级时跳过已有原始备份的文件、只删除旧安装自建的文件，从而保证备份库里永远存着第一次安装前的游戏原件。

💡 若一切校验都不可信，还备有ForceFolderCleanup强制清理入口（Services/GameInstallationService.cs#L1128-L1208）：无条件清除全部已知 OptiScaler 产物，用于从损坏的安装状态中恢复。

五、相关源码速查

• 清单数据模型：Models/InstallationManifest.cs
• 外部备份库与残留探测：Services/BackupStoreService.cs
• 安装/卸载/回滚/目录探测：Services/GameInstallationService.cs
• 旧版备份启动迁移：Services/StartupMigrationService.cs
• 功能特性总览：README.md

小结：备份清单负责"记账"，外部备份库负责"保管"，目录探测负责"找对位置"，三态状态机与 SHA-256 验收负责"善后"。这套组合让 OptiScaler Client 的安装过程对用户而言只有两个结果——成功生效，或恢复原样，没有中间态。