同一份工程出 Steam / Epic 双版本：宏拆分 + Build.cs 配置 + UAT Pipeline

同一款游戏要同时上 Steam 和 Epic，两边的 SDK、插件、部分逻辑都不一样。最干净的做法是拆成两个独立的 game project，但移植项目往往没有这个自由度，只能在一份工程里做兼容——这篇记录这套兼容方案怎么落地。

三个拆分点

1. 用宏拆分逻辑代码。 给 Steam / Epic 各自的逻辑加编译宏区分。

一个坑：不要把这个宏定义写在 Game.Build.cs 里，然后又在引擎工程里用它。一旦引擎代码依赖了定义在 game 侧的宏，引擎工程就没法脱离 game 工程单独编译了。宏的定义位置要和使用位置的模块边界对齐。

2. 在 Game.Build.cs 里按版本引不同的 lib。 Steam 版链 Steam 的库，Epic 版链 Epic 的库，用配置区分。

3. 按版本启用/禁用不同插件。 Steam 版开 Steam 相关插件，Epic 版开 Epic 的，另一边关掉。

UE 构建 Pipeline

程序侧（本地开发）：

1. 跑 GenerateProjectFiles.bat 生成 sln。
2. 编 Editor Win64 工程。
3. 编 exe（Debug + cooked asset）。

构建机侧（出正式包）：

1. 跑 GenerateProjectFiles.bat 生成 sln。
2. 跑 UAT bat 出包，顺序是：
   1. 先编 Editor
   2. 编 Exe
   3. Cook 资源
   4. Stage
   5. Package

调试 UnrealBuildTool

想调 UBT（比如排查某个版本宏/lib 没生效）：

1. 把 UnrealBuildTool 设为启动项目。
2. Start options → Command line arguments 传入目标信息，例如：

YourGame Win64 Development "path/to/YourGame.uproject" -WaitMutex -FromMsBuild -Steam

末尾的 -Steam 这类自定义参数就是驱动 Build.cs 走哪条分支的开关，切成 Epic 分支时换成对应参数即可。

小结

这套单工程双商店最容易翻车的点是宏的定义位置：务必对齐模块边界，放错会毁掉引擎工程独立编译的能力。真有条件还是拆两个 project 最省心，单工程只是移植项目受限时的兼容折中。