我问了下AI,
AI:
原脚本 @ReBase -b 0x400000 %1 && llvm-strip -R .reloc %1 存在几个致命的批处理编写缺陷，导致它在大多数普通用户的电脑上根本无法正常执行。
具体原因如下：
1. 缺少路径指引（%~dp0的缺失）
在 Windows 批处理中，直接写 ReBase 和 llvm-strip，系统会去系统的环境变量（PATH）和当前工作目录里找。
当你把文件“拖拽”到批处理上运行时，Windows 默认的“当前工作目录”通常会变成 C:\Windows\System32 或者是你拖拽文件的源目录，而不是批处理文件所在的目录。
如果这些 .exe 工具没有加在系统的环境变量里，又没有用 %~dp0 强制指明路径，系统就会报“不是内部或外部命令”。
2. && 连接符的“连坐”机制
原脚本中间用了 &&（逻辑与）来连接两条命令。&& 的意思是：只有前一条命令成功执行，才会执行后一条命令。
ReBase 是 Visual Studio / Windows SDK 自带的工具。很多普通用户的电脑上根本没有装 Visual Studio，所以第一步 ReBase 就会因为找不到工具而失败。
一旦 ReBase 失败（报错退出），&& 之后的 llvm-strip -R .reloc 就根本不会被执行。
这就完美解释了你之前遇到的问题：你以为脚本运行了，但因为第一步找不到 ReBase 失败了，第二步 llvm-strip 压根没跑，所以 .reloc 段一直都在，模拟器一点变化都没有。
Blader 很可能是在自己安装了完整 Visual Studio 或 LLVM 工具链的开发环境下测试的，这些工具的路径已经加到了系统的环境变量中。所以他直接写命令名就能跑通，但他忽略了把这些 .exe 放在压缩包里发给普通用户时，普通用户电脑里并没有这些环境变量。
------------------------------------------------
我移除ReBase 部分后的批处理(pcsx2-qt.exe的体积从14.0MB→13.9MB):
@echo off
"%~dp0llvm-strip.exe" -R .reloc %1
pause
