上周帮人把一台旧机器上的 UE 环境整体挪到新加的大容量盘上，引擎目录、项目、资产包一个字节都没少，结果打开启动器一看，十几个条目全变成了"未安装"，库页面空空如也。折腾了两个多小时才定位到根因：问题根本不在那几个几十 GB 的引擎文件夹上，而在几个加起来不到 1MB 的文本文件里。这套东西就是我下面要讲的"用户配置文件"——启动器自己的设置、引擎的用户级 ini、项目里的 Saved 配置，以及那两份决定了"我到底装了什么"的清单记录。很多人把"配置文件"理解成主题、语言、下载限速这些显性开关，其实真正会让你返工的是隐藏在前者背后的索引结构：启动器判断某个版本装没装，第一依据是清单文件里的一条记录，而不是去硬盘上扫目录。所以文件在、记录丢，结果就是"未安装"。
这篇内容适合三类人看：一是准备换机器、换盘、重装系统，又不想把几十 GB 环境从头下一遍的；二是遇到"启动器识别不到引擎""双击 .uproject 提示找不到版本""改完设置重启又变回去"这类问题的；三是团队里负责统一编辑器配置、希望新人拉下项目就能用的。下面我会把路径、字段、覆盖顺序、迁移流程和排障链路一层层拆开，能直接抄的部分我会给出现成命令和步骤，需要判断的地方我会说明为什么这么选。文中所有路径以 Windows 端为主，各版本之间字段名和目录细节会有细微差异，判断标准永远是你机器上实际存在的那个文件，不要照抄网上流传的旧路径。
1. 先分清"用户配置文件"到底指哪三堆东西
1.1 三层结构：启动器的、引擎的、项目的
很多人一上来就搜"UE 配置文件在哪"，搜出来一堆路径，然后挨个去删，最后环境彻底乱掉。原因是这个概念本身是三层叠在一起的，混着看必然出事。
第一层是启动器自身的配置。它管的是这个"商店 + 下载器 + 版本管理器"长什么样、缓存在哪、下载限速多少、登录状态怎么维持。这一层出问题的典型表现是启动器卡在加载界面、库页面空白、下载任务丢失。
第二层是引擎的用户级配置。引擎装好之后，每个版本都会在用户目录下留一份自己的设置，比如编辑器布局、视口渲染选项、自动保存间隔。这一层是按"版本号"分目录的，你装了三个版本就有三份，互不影响。删掉它不会损坏引擎，但你的编辑器会回到刚装完的默认状态。
第三层是项目的配置。这一层又分两半：Config/目录下的Default*.ini是跟着项目走的、应该进版本库的；Saved/Config/下的才是你这个人在这个项目上的本地偏好，绝不该进版本库。这两半混在一起提交，是团队协作里最常见的一种污染。
理解这三层之后，"为什么我改了设置另一台机器上不生效"这种问题就不用再问了——因为你改的多半是第三层的Saved，而它天生就只属于你这一台机器。
1.2 一张能直接对照的路径表
下面这张表是我自己在用的速查表，Windows 端为主。注意环境变量写法比硬编码用户名可靠得多，%LOCALAPPDATA%就是C:\Users\你的用户名\AppData\Local，%PROGRAMDATA%一般是C:\ProgramData。
| 层级 | 用途 | 典型路径 |
|---|---|---|
| 启动器 | 启动器界面与行为设置 | %LOCALAPPDATA%\EpicGamesLauncher\Saved\Config\Windows\ |
| 启动器 | 运行日志 | %LOCALAPPDATA%\EpicGamesLauncher\Saved\Logs\ |
| 启动器 | 崩溃转储 | %LOCALAPPDATA%\EpicGamesLauncher\Saved\Crashes\ |
| 启动器 | 已安装应用索引 | %PROGRAMDATA%\Epic\UnrealEngineLauncher\LauncherInstalled.dat |
| 启动器 | 每个应用的安装明细 | %PROGRAMDATA%\Epic\EpicGamesLauncher\Data\Manifests\*.item |
| 引擎 | 某个版本的用户级编辑器设置 | %LOCALAPPDATA%\UnrealEngine\<版本号>\Saved\Config\WindowsEditor\ |
| 引擎 | 多版本共享的派生数据缓存 | %LOCALAPPDATA%\UnrealEngine\Common\ |
| 项目 | 团队共享的默认配置 | <项目>\Config\DefaultEngine.ini等 |
| 项目 | 本机用户覆盖 | <项目>\Saved\Config\WindowsEditor\ |
有两个细节值得单独拎出来。第一，LauncherInstalled.dat和Manifests不在同一个父目录下，一个在Epic\UnrealEngineLauncher、一个在Epic\EpicGamesLauncher，名字只差几个字母，我以前复制命令时眼睁睁看着自己粘错目录排查了半小时。第二，打包后的游戏和编辑器读的目录名不一样：编辑器是WindowsEditor，打包产物是Windows，所以你在编辑器里调好的GameUserSettings.ini直接搬到打包版本里，可能根本不会被读。
macOS 端的结构基本对称，落在~/Library/Application Support/Epic/和共享目录一带，思路完全一样，只是路径前缀不同，本文的排查逻辑可以平移过去。
1.3 哪些能删、哪些碰不得：一个分级的处理策略
配置文件不是都不能删，也不是都能删。我按"删了之后的后果"分成三档，日常维护时按这个来判断就行。
第一档，随便删：Saved\Logs、Saved\Crashes、Saved\webcache这类缓存和日志。删了最多是下次启动慢一点、日志从零开始写。启动器出现白屏、卡加载、页面元素错乱时，第一反应就该是关掉进程再删缓存目录。
第二档，可以删但要有心理准备：Saved\Config下的 ini。删掉等于恢复出厂设置，编辑器会重新走一遍首次启动向导。删之前把整个Saved\Config目录复制一份出来，出问题能原样贴回去。
第三档，删之前必须做快照：LauncherInstalled.dat和Manifests目录。这两个是"账本"，账本一乱，几十上百 GB 的已装内容就在启动器眼里凭空消失了。虽然很多时候启动器会自己重新扫描并部分恢复，但这个过程不可控，AppVersion 之类的字段很可能丢，之后更新会重新下载。
注意：所有 ini 和 dat 的修改都要在启动器与引擎全部退出之后做。引擎在运行时会把内存里的配置在退出时回写，你改的文件会被直接覆盖，看起来就像"改了没用"。任务管理器里确认
EpicGamesLauncher.exe和UnrealEditor.exe都消失，再动手。
2. LauncherInstalled.dat 与 .item 清单：启动器认不认你的安装，全看这两份账本
2.1 索引加明细的二元结构
这套记录方式的设计其实很朴素：一个总索引加上一堆明细。LauncherInstalled.dat是总索引，格式是 JSON，里面有一个InstallationList数组，每条记录至少包含三个信息——应用标识（AppName，比如引擎版本对应的条目名）、版本号（AppVersion）、安装路径（InstallLocation）。启动器的库页面就是遍历这个数组渲染出来的。
而Manifests目录下每个已安装应用对应一个.item文件，也是 JSON，内容比索引详细得多：文件清单、安装时记录的校验信息、可执行文件位置、依赖关系等等。索引负责"快速画出列表"，明细负责"实际管理和校验"，两者缺一不可。
想快速看清账本内容，不用装任何工具，PowerShell 两行就够：
Get-Content "$env:ProgramData\Epic\UnrealEngineLauncher\LauncherInstalled.dat" -Raw | ConvertFrom-Json | Select-Object -ExpandProperty InstallationList | Format-Table AppName, AppVersion, InstallLocation -AutoSize跑完你会看到一张表，一眼就能判断是"记录丢了"还是"记录在但路径指错了"。这两种情况的修法完全不同：前者要把记录补回来，后者只需要把InstallLocation改成实际路径。先分清是哪一种，再动手，别一上来就删文件重建——重建意味着重新下载。
2.2 一个 .item 里到底有什么
.item的结构因应用类型而异，引擎和资产包、插件的内容并不完全一样，但有几类信息是通用的，认识它们你就知道该看哪儿。
第一类是身份信息：应用名、版本、安装路径。这几个字段和总索引里的记录必须对得上，对不上就会出现"库里有卡片但点下载/点启动没反应"这种诡异状态。
第二类是文件清单：安装时记录下来的文件与大小/摘要。启动器的"验证"功能就是拿这份清单去比对你硬盘上的实际情况。验证卡在某一步、或者验证完提示一堆文件缺失，往往是清单本身和实际文件已经脱节了。
第三类是可执行入口：引擎版本会记录编辑器可执行文件的相对位置，启动器点"启动"时就是按这个去找的。
看.item时有个实用技巧：文件不大但结构嵌套，直接用浏览器打开反而比编辑器舒服——现代浏览器对本地 JSON 有折叠和搜索，找某个字段比在几千行里翻快得多。改之前同样先复制一份，改完用 JSON 校验工具过一遍，少一个逗号整份文件就废了。
2.3 手改账本的安全流程
我不建议把"手改清单"当成常规操作，但它确实是某些场景下唯一的路——比如只搬了盘符、路径整体变化、又不想重新下载几十 GB。要做的话按这个顺序来。
**第一步，全量快照。**把LauncherInstalled.dat和整个Manifests目录复制到别的地方，命名带上时间戳。这不是形式主义，我遇到过改坏之后想回滚、结果发现覆盖掉的那份才是好的。
**第二步，先测一个。**账本里可能有二三十条记录，不要一次性全改。挑一条路径最简单、体积最小的先改，重启启动器验证效果。成功了再批量处理，失败了损失也可控。
**第三步，路径分隔符和结尾斜杠。**JSON 里的路径反斜杠要转义，写成C:\\Program Files\\...，这是最常见的翻车点。结尾有没有多余的反斜杠也可能影响匹配，保险做法是照抄原来那条记录的格式，只替换盘符和目录名。
**第四步，改完不要马上开引擎。**先开启动器，确认库页面显示正常、状态是"已安装"、能点启动，再去开引擎。顺序反了，出问题时你分不清是账本的问题还是引擎的问题。
提示：如果只是单纯换了盘符，有个更省事的思路——用目录联接把旧路径指向新位置，账本一个字都不用改。命令是
mklink /J "旧路径" "新路径"，需要管理员权限。好处是零风险可回退，缺点是旧路径这个"壳"得一直留着，删了联结就断。
3. 引擎与项目的 ini 覆盖链：谁把谁的设置吃了
3.1 Base 到 Default 再到 Saved 的三层覆盖
ini 这套机制的核心是"层层覆盖"，同名 section 下的同名键，后加载的把先加载的盖掉。顺序大致是：引擎自带的Base*.ini→ 项目的Config\Default*.ini→ 平台相关的默认覆盖 → 用户目录下的Saved\Config\<平台>\*.ini→ 命令行参数。
理解这个顺序，很多"玄学"就消失了。比如你在项目DefaultEngine.ini里改了一个渲染参数，同事那边生效、你这边不生效——大概率是你的Saved\Config\WindowsEditor\Engine.ini里有一条同名键把它压住了。因为用户层在最上面，它的优先级最高。
再比如你从别人那儿拷了一份"优化 ini"覆盖到项目的Config目录，结果一半生效一半不生效——那说明被覆盖的键里，有些在你的用户层已经有值了。**排查 ini 冲突的第一动作永远是：先把用户层的Saved\Config整个挪走（不是删，是移走），看问题还在不在。**在，说明问题在项目层或引擎层；不在，说明就是用户层盖的。
这个"移走再测"的手法我用得非常多，因为它把"二分查找"这件事变得极其廉价：一次移动就能砍掉三分之一的搜索空间。
3.2 GameUserSettings 和 EditorPerProjectUserSettings 各管什么
项目Saved\Config\WindowsEditor\下最常打交道的两个文件，很多人分不清区别，结果是"改错文件、白折腾"。
GameUserSettings.ini管的是运行期的画面与性能表现：分辨率、窗口模式、垂直同步、帧率上限、各种画质档位。它里面的 section 名通常是[/Script/Engine.GameUserSettings]，键名类似ResolutionSizeX、ResolutionSizeY、FullscreenMode、FrameRateLimit这种。这个文件的特点是可被游戏内或编辑器内的设置界面自动改写——你在界面上点了"应用"，退出时它就把值写回去了。所以想手改它，必须先确保进程已退出。
EditorPerProjectUserSettings.ini管的是编辑器里的个人操作习惯：蓝图编辑器开没开某些面板、内容浏览器的视图模式、某些自动化提示还弹不弹。它跟"这台机器上你这个人怎么用编辑器"强相关，所以天生属于本地。
区分方法很简单：问自己"这个设置换个人来用要不要跟着变"。要变（画面、分辨率）就往GameUserSettings想；不该变（你的面板布局）就往EditorPerProjectUserSettings想。这个问题一问，八成能定位对文件。
3.3 团队协作里 ini 的正确分工
这里有一条我认为必须守住的线：Config\Default*.ini进版本库，Saved\Config\永不进版本库。前者的每一次改动都应该走代码评审，后者压根不该被 Git 看见。
推荐的做法是在项目根目录的忽略文件里明确列出Saved/、Intermediate/、DerivedDataCache/、Binaries/这几项。新人克隆项目后，引擎会自动在本地生成属于他自己的Saved/Config，不需要你操心。
如果团队确实需要统一一批个人偏好（比如大家都用同样的自动保存间隔、同样的源码管理配置），正确姿势是写进Config\DefaultEditorPerProjectUserSettings.ini，而不是让别人去改自己的Saved。前者是全队共享的默认值，后者是个人覆盖，混用会导致"新人永远配不对"。
改 ini 时有三个具体语法点值得记住，它们能省掉大量试错：
+Key=Value表示向数组追加一项，不会覆盖已有的-Key=Value表示从数组里移除匹配项!Key=ClearArray表示清空整个数组
还有编码问题。Windows PowerShell 5.1 的Out-File默认编码是 UTF-16LE，用它写 ini 会让文件变成引擎读不懂的二进制开头，表现为"设置完全不生效"甚至引擎报配置解析错。要用脚本写 ini，就明确指定编码：
$path = "<项目>\Saved\Config\WindowsEditor\GameUserSettings.ini" $content = Get-Content $path -Raw $content = $content -replace 'FrameRateLimit=.*', 'FrameRateLimit=60.000000' Set-Content -Path $path -Value $content -Encoding UTF8 -NoNewline-NoNewline也别省，多出来的空行在某些解析器下会带来莫名其妙的边界问题。
4. 换机器或换盘：配置迁移的完整流程
4.1 动手前的盘点与快照
迁移这件事最容易犯的错，是直接从"复制文件夹"开始，而不是从"盘点"开始。我的习惯是先花十分钟把现状摸清楚，后面能省两小时。
盘点要回答三个问题。**第一，装了哪些版本？**把前面那条 PowerShell 命令跑一遍，把输出另存成文本，这就是迁移前的基准。**第二，哪些是引擎、哪些是资产包和插件？**引擎通常是几十 GB 的独立目录，资产包可能只有几百 MB 但数量多。两类东西的迁移风险不一样：引擎目录相对自包含，资产包更依赖清单里的文件级记录。**第三，哪些路径会变？**如果只是同一个盘的目录改名，风险很低；如果换盘符甚至换机器，路径整体变化，就必须处理账本。
然后把三样东西打包快照：%LOCALAPPDATA%\EpicGamesLauncher\Saved\Config、%PROGRAMDATA%\Epic\EpicGamesLauncher\Data\Manifests、%PROGRAMDATA%\Epic\UnrealEngineLauncher\LauncherInstalled.dat。这三样加起来通常不到几 MB，压缩一下随手存着，出问题就是救命稻草。
还有一个容易被忽略的点：先确认新位置的剩余空间和文件系统。把引擎目录搬到一块容量刚好够的盘上，之后每次更新都会失败，而启动器的报错往往只说"磁盘空间不足"，不会告诉你具体差多少。另外，如果目标盘是网络位置或者某些特殊格式的存储，部分文件属性和长路径支持可能出问题，迁移完验证通过再删旧目录。
4.2 引擎目录搬家：清单、注册表、版本选择器三处都要对
这一步是整篇文章里最容易出岔子的地方。引擎"被系统认识"这件事，实际上依赖三个独立的登记处，任何一处不对，都会出现某种特定的症状。
第一处是启动器的账本，也就是第 2 节讲的那两份文件。账本不对，启动器里显示未安装。
**第二处是注册表里的安装记录。**对于启动器安装的正式版本，系统范围内的记录指向引擎根目录。这块信息决定了"版本选择器"能不能找到这个引擎。路径大致在HKEY_LOCAL_MACHINE\SOFTWARE\EpicGames\Unreal Engine\<版本号>下的InstalledDirectory值。改注册表前一定先导出备份，这是常识但总有人跳过。
**第三处是用户级的源码构建登记。**如果你自己编译过引擎，那份构建不是通过启动器安装的，它登记在HKEY_CURRENT_USER\Software\Epic Games\Unreal Engine\Builds下面——值名通常是一串像 GUID 的标识，值数据是引擎根目录。这就是为什么"我自己编的引擎为什么在版本选择器里看得见"——它走的是另一条路。搬家之后这里如果不同步，选择器列表里就会出现一条指向不存在路径的僵尸项。
三处的处理顺序建议是：先改账本、再改用户级登记、最后改系统级注册表。理由是风险从低到高，前一步的失败不会污染后一步。
至于.uproject文件右键里的"切换引擎版本"功能，它依赖一个随引擎安装的版本选择器组件。如果搬家之后这个功能整个消失了，说明负责注册它的组件在新位置上没有被正确重新注册，通常重装一次引擎能修复，但更轻量的做法是先确认注册表那两处路径是否都指对了。
4.3 迁移完成后的一份逐项自检清单
我不太相信"感觉没问题了"这种判断。每次迁移完我会按下面这串动作走一遍，全过才算完事。
| 顺序 | 检查动作 | 期望结果 |
|---|---|---|
| 1 | 打开启动器，进库页面 | 所有条目在列，状态为已安装，没有转圈或空白卡片 |
| 2 | 点某个版本的"启动" | 编辑器正常拉起，无"找不到可执行文件"提示 |
| 3 | 编辑器内看"关于"信息 | 版本号与预期一致 |
| 4 | 双击任意.uproject | 版本选择器弹出或直接用正确版本打开 |
| 5 | 在编辑器里打开一个蓝图资产 | 能正常编译，不报找不到模块 |
| 6 | 检查项目Saved\Config | 目录已生成，里面的 ini 属于本机 |
| 7 | 跑一次"验证"（如果有需要） | 进度能走完，不报大量文件缺失 |
| 8 | 确认旧目录已可安全删除 | 上面的都过了之后，再删 |
第 5 项特别值得说。引擎搬家之后很常见的一个现象是：编辑器能开，项目也能打开，但一编译蓝图就报找不到某个模块。这往往不是配置文件的问题，而是派生数据缓存和中间产物还指着旧路径。处理方式不是去改 ini，而是删掉项目目录下的Intermediate和Saved里跟缓存相关的子目录，让引擎重新生成。遇到"能用但一编译就报错"这类症状，先想到缓存，别急着怀疑配置。
5. 三条真实排障链路：从症状倒推到底该动哪个文件
5.1 症状一：文件明明在，启动器说未安装
这是最经典的场景。排查链路我一般这么走。
**先看账本在不在。**按 2.1 节的命令读一遍LauncherInstalled.dat。如果命令直接报错说文件不存在，那答案就有了——账本丢了，启动器没有可读的索引，库页面自然是空的。这种情况不用慌，启动器在启动时会尝试扫描并重建，但重建质量不稳定。稳妥做法是先把之前备份的那份贴回去，再启动。
**账本在，就逐条看路径。**如果某条记录的InstallLocation指向的目录根本不存在，说明搬家时路径变了但账本没跟着改。这时候有两个选择：改账本，或者用 2.3 节提到的目录联接把旧路径指过去。我一般倾向后者，因为改账本涉及 JSON 转义，出错概率不低；目录联接是一条命令的事，而且随时能删掉。
**路径也对，那就去查明细。**打开Manifests目录，找对应应用的那个.item，看里面的安装路径和索引里的是否一致。两者打架的时候，表现通常是"卡片显示已安装，点启动没反应"或者"点更新直接把整个包重下"。修法是让两处对齐，改哪一处都行,但别只改一处。
还有一种更隐蔽的情况：账本和明细都对，路径也对，但启动器就是不认。这时候去看日志。%LOCALAPPDATA%\EpicGamesLauncher\Saved\Logs\下的日志文件是按启动会话追加的，搜一下你那个应用标识，通常会有一行明确的错误说明，比如某个文件校验不通过、或者某个字段解析失败。日志这东西平时没人看，但它比任何猜测都快。
5.2 症状二：双击项目文件提示找不到引擎
这个症状的排查方向和第 5.1 节完全不同，因为它根本不经过启动器的账本，走的是注册表那条路。
**第一步，确认版本选择器还在不在。**如果右键菜单里连"切换引擎版本"这个选项都没有了，说明负责注册的组件失效了，先解决这个，后面的排查才有意义。
**第二步，看注册表里登记的路径。**系统级的那一处要指向新位置。路径还是老路径的，改成新的。改之前照例导出备份。
**第三步，区分"启动器安装的"和"自己编译的"。**如果这个引擎是你自己编的，它登记在用户级的那一处，跟系统级的是两套东西。很多人只改了系统级，然后困惑于"为什么我自定义的引擎还是打不开"。这两处的键结构不一样，别混着改。
第四步，检查项目文件里记录的引擎关联。.uproject本身带一个引擎关联信息，绑定到某个版本。如果这个版本已经不存在了，打开时就会卡住。这种情况可以用选择器手动手动指定另一个版本，或者直接编辑项目文件里那段关联信息。
提示：升级引擎大版本之后，老项目打不开是常态，不一定是配置坏了。我的习惯是先复制一份项目，在副本上做版本升级，原项目保持可回退。配置文件出问题还能修，资产升级搞坏了就真的回不去了。
5.3 症状三：设置改完，重启又变回原样
这个症状最气人，因为它看起来像"设置没保存"，实际上几乎总是下面四个原因之一。
**原因一，进程没退干净。**你在界面上改完设置、点了应用，但进程还在后台，退出时它用内存里的旧值回写了文件。表现是"我明明改了，重启就没了"。解法：改之前先在任务管理器里确认进程消失。
**原因二，文件是只读的。**有些教程教你把自己不想被覆盖的 ini 设成只读，这招确实有效，但副作用是之后所有通过界面的修改都静默失败。如果你接手的是别人的机器，先右键看属性里那个只读勾有没有被勾上。
**原因三，改错了层级。**你改的是项目的Default*.ini，期望全机器生效，但用户层的Saved里有一条同名键把它盖住了。这是最常见的认知错位，用 3.1 节的"移走再测"一次就能确认。
**原因四，编码被改坏了。**用错编码写回去之后，引擎解析失败，于是整份文件被忽略，表现出来就是"改了什么都没用，全是默认值"。检查方式很简单：用十六进制查看器看文件开头两个字节，如果是FF FE或FE FF，那就是被写成了 UTF-16，需要转回 UTF-8。
这四条我按发生频率排的序，实际遇到的里面第一条和第四条加起来能占到七成以上。所以排障顺序也建议照这个来：先确认进程退出，再检查编码，再确认只读，最后才去纠结层级冲突——这个顺序能让你用最少的动作命中最多的问题。
6. 把配置当资产来管：备份、只读锁与几个常见误区
6.1 一份够用的自动备份脚本
手动备份靠不住，人会忘。我给自己写了个很短的脚本，放在计划任务里每周跑一次，一年多下来救过两次场。
$stamp = Get-Date -Format "yyyyMMdd_HHmmss" $dest = Join-Path "D:\UEBackup" $stamp New-Item -ItemType Directory -Path $dest -Force | Out-Null $targets = @( @{ Path = "$env:LOCALAPPDATA\EpicGamesLauncher\Saved\Config"; Name = "LauncherConfig" }, @{ Path = "$env:PROGRAMDATA\Epic\EpicGamesLauncher\Data\Manifests"; Name = "Manifests" }, @{ Path = "$env:PROGRAMDATA\Epic\UnrealEngineLauncher"; Name = "InstalledIndex" } ) foreach ($t in $targets) { if (Test-Path $t.Path) { Copy-Item -Path $t.Path -Destination (Join-Path $dest $t.Name) -Recurse -Force } else { Write-Warning "未找到: $($t.Path)" } } # 只保留最近 10 份 Get-ChildItem "D:\UEBackup" -Directory | Sort-Object Name -Descending | Select-Object -Skip 10 | Remove-Item -Recurse -Force这脚本没什么技术含量，但有两个设计上的取舍值得说。一是把路径做成哈希表而不是简单数组，因为备份过去的目录名如果全是Config、Data这种通用名，回滚的时候你会分不清哪份是哪份。二是保留最近十份而不是按天数删，因为我的使用频率不固定，按份数保留更符合实际。
恢复的时候不要整个目录覆盖回去。正确做法是把备份里的文件和当前文件对比，只把差异项贴回去。原因很简单：当前文件里可能有你后来做的、更符合现状的改动，全量覆盖会把它们一起冲掉。
6.2 只读锁、多版本共存与几个我踩过的误区
**关于只读锁。**把某个 ini 设成只读，确实能防住"被自动覆盖"这件事，但它会连带禁掉所有正常的界面修改路径。我的用法是：只有在已经确定一份配置正确、并且短期内不打算再改的情况下才加只读，而且会在旁边放一个记事本文件写明"这个文件为什么是只读的、怎么解锁"。不写说明的话，三个月后接手的人（可能就是你自己的另一台机器）会一头雾水。
关于多版本共存。同时装多个引擎版本是很正常的，配置文件天然按版本分目录，所以彼此不干扰。真正会打架的是派生数据缓存和项目里的Intermediate。同一个项目如果用两个版本分别打开过，第二次打开时引擎可能提示需要重建，这时候不要慌，让它重建就行。反过来说，如果你频繁在两个版本之间切换同一个项目，每次都重建的话，把项目复制成两份分别绑定一个版本，效率会高很多。这个做法看起来浪费磁盘，实际上省的是每次十几分钟的等待。
**关于"清理配置能提速"这个说法。**网上有些说法称删配置、清缓存能让引擎变快。我的实测结论是：清派生数据缓存对"编辑器启动慢"有一定帮助，尤其是在机械盘上；但删Saved\Config对性能几乎没影响，只会让你重新配一遍界面。把这两件事混在一起宣传，是很多人被误导的源头。
**关于"配置文件全局通用"这个误区。**不同引擎版本之间、甚至同版本的不同小版本之间，ini 的键名和结构都可能变化。把一份别人的"最佳配置"直接覆盖过去，最常见的后果是某些键被忽略、某些键取到了意料之外的值。想复用配置,正确做法是只抄你确认过键名的那几行,其余全部保留原样,改完立刻验证一遍效果。
最后一个我自己用过很久的小习惯：在项目的Config\DefaultEngine.ini顶部加一段注释，写清楚这个文件里哪些段是被团队刻意改过的、为什么改、改的人是谁（写工号或昵称都行）。这东西看起来土，但当下一个人（或者半年后的你）想要动那几行时，会省下大量"这行是谁加的、能不能删"的考古时间。配置文件本身是死的，让它带上上下文，它才变成真正的团队资产。
