最近项目要发布Windows桌面版，产品那边要求给客户一个能双击安装的exe安装包，而不是让用户自己解压文件夹去点运行。我本来以为Cocos Creator构建个Windows平台也就点两下的事，真正走了一遍才发现，从编辑器构建出exe到做出一个合格的Windows安装包，中间有非常多值得梳理的细节。这篇文章我就把整个流程里那些文档里没写清楚的东西摊开讲：构建参数怎么配、产物里哪些文件不能删、安装包脚本怎么写、杀毒软件误报怎么处理、运行库缺失怎么规避。
我使用的环境是Cocos Creator 3.8.2，目标是构建一个x64的Windows桌面游戏。整个流程不管你是2.4.x还是3.x版本，思路都通用，只是面板参数和产物目录结构略有差异。
1. 先判断清楚：这个项目到底适不适合构建Windows桌面版
很多人一上来就问“怎么打包成exe”，但我建议先想清楚“为什么需要exe”。Cocos Creator是跨平台引擎，构建Windows桌面版意味着你要额外维护一套桌面端的输入适配、分辨率适配、性能和兼容性问题，成本并不低。
我接触过的项目中，适合构建Windows桌面版的有三类。
第一类是核心玩法依赖鼠标键盘或者大屏显示的产品，比如模拟经营、卡牌策略、数据可视化大屏。这类产品放在PC上体验远好于手机小屏，而且通常需要通过安装包分发给企业客户或者终端用户。
第二类是渠道要求。上Steam、WeGame这类PC游戏平台，或者走官网下载渠道，正常情况下都需要做一个规范的安装包。你不可能让用户在官网下载一个文件夹解压完去点exe，这体验太原始了，转化率也会受影响。
第三类是工具型应用、互动展示项目。用Cocos Creator做展厅互动程序、产品配置器、培训课件的人越来越多，交付给客户时几乎都要求一个能双击安装的Windows程序，而不是裸奔的项目文件。
反过来讲，如果项目本身就是为手机触屏设计的轻量休闲游戏，又没有明确的PC分发需求，我通常不建议做Windows版。原因很简单，你要处理一堆适配问题，最终ROI往往不划算。项目早期就确定好是否需要桌面版，能省掉后面大量的返工成本。
还有一点提醒：如果只是内部测试、给同事看一看，完全不需要做安装包，直接用构建出来的exe加resources目录压缩成一个zip就行。真正需要做安装包的场景，是面向外部用户的产品级分发。
2. 构建前的准备：环境、项目检查与关键参数
2.1 构建环境配置
Cocos Creator构建Windows平台不是纯编辑器内操作，它底层依赖CMake和Visual Studio工具链。我第一次构建失败就是吃了环境没配好的亏，所以环境这块多说几句。
以3.8.x为例，构建Windows时Creator会生成CMake工程并调用MSBuild编译C++壳工程。因此你的电脑上必须安装了Visual Studio，且必须包含“使用C++的桌面开发”工作负载。只装了VS Code或者只装了.NET开发组件是不够的。
我自己的环境是Visual Studio 2022 Community版本，只勾选了“使用C++的桌面开发”，后面构建全程没出过编译工具链的问题。版本选择上VS2019或VS2022都可以，注意3.x对VS2022的支持更成熟一些。
Cocos Creator编辑器版本建议使用稳定的正式版。不要用Beta版去构建发布包，我在2.4时代踩过Beta版构建出来的包在某些机器上黑屏的坑。发布环境求稳，编辑器版本也求稳。
2.2 项目层面的检查清单
构建之前建议先过一遍项目检查，这三项是我踩坑次数最多的。
一个是资源路径和项目路径，必须保证全英文，路径不能有中文和空格。虽然新版Creator对中文路径的兼容有一定改善，但发布环境我们没必要赌这个。特别是项目路径如果带中文，CMake生成那块很容易出问题，报错还很隐晦。
第二个是代码里的平台判断。如果项目之前只做过Web或微信小游戏，代码里可能有大量平台相关的逻辑，比如调用了wx对象、navigator接口、浏览器专属API。构建Windows时这些代码会在原生环境下执行，一旦没有平台判断，直接白屏崩溃。
第三是纹理压缩格式。手机上常用的ETC2、ASTC格式，Windows平台并不直接支持。如果你在项目里手动设置了纹理的平台覆盖只针对Android/iOS，那么构建Windows时引擎会自动转成RGBA8888。这里容易坑的一点是，如果图集资源很大，转格式后包体和显存占用会明显上升，做性能评估时要留出余量。
2.3 构建任务的关键参数解读
打开项目 → 构建发布，新建一个构建任务，平台选择Windows。我把常用的参数结合实际经验逐个说一下。
输出路径尽量放到磁盘根目录下一级的纯英文目录，比如D:/build。不要放到桌面，不要放到带中文的用户目录下。Windows用户名是中文的情况很常见，这会连带构建路径变成中文，容易出问题。
调试模式这个选项，发布时一定不要勾选。勾选后代码不压缩且生成调试信息，包体变大，运行效率降低，而且某些场景下会默认开启远程调试端口，有安全风险。平时排查问题可以在本地构建时打开，正式发布包一定关闭。
MD5 Cache建议打开。如果项目后续做热更新或者频繁发版，这个选项会给构建资源名加上MD5哈希值，便于增量更新和缓存控制。缺点是资源文件名变长，但对构建产物没有实质影响。
起始场景要检查一下是不是你想要的入口场景。项目早期大家都会新建一堆测试场景，构建时如果选错起始场景，打出来的包一进去就是个空场景，排查起来非常困惑。
还有一些渲染相关的选项，比如是否使用GPU粒子、是否开启光照，这些根据项目实际用的功能勾选，我没有统一建议。但有一条：构建Windows平台时，如果项目用了比较新的渲染特性，目标机器的显卡不能太老，这个兼容性问题后面单独说。
3. 构建发布Windows平台的完整实操流程
3.1 执行构建任务
参数配置完毕，点击构建按钮。第一次构建会很慢，通常5到15分钟，因为需要跑CMake配置、编译C++壳工程、处理资源、生成脚本绑定代码，整个链路很长。
构建过程中，底部控制台会输出大量日志。看到CMake相关输出时可以多留意一下，如果这里报错，大概率是VS环境问题而不是项目问题。比如提示找不到Visual Studio、找不到C++编译器，基本就是VS没装C++工作负载，或者Creator无法自动探测到VS版本。
3.8版本构建完成后，输出目录里可以看到类似这样的结构：
D:/build/MyGame/ ├─ MyGame.exe ├─ resources/ │ ├─ builtin/ │ ├─ native/ │ └─ assets/... ├─ src/ ├─ jsb-adapter/ ├─ data/ ├─ main.js ├─ project.json └─ ...这里我要强调一个重要结论：exe不能脱离整个目录单独拷贝运行。MyGame.exe只是可执行入口，resources目录、data、src这些文件共同构成一个完整的运行时环境。很多人把exe复制出来发给别人，双击打不开，然后以为是构建有问题，其实只是缺了旁边的resources目录。
Cocos Creator构建Windows产物的运行机制可以类比一个壳：exe是一个原生C++宿主程序，游戏逻辑是JS编译后的脚本，由内置的JavaScript引擎执行。启动时exe会加载同级的resources目录，读取游戏资源与脚本，然后创建窗口渲染画面。所以整个产物文件夹要整个交付，不能只带走exe。
3.2 本地验证：不要拿到exe就直接打包
构建完先别急着做安装包，本地先按照交付标准验证三件事。
第一步是直接在构建目录里双击exe，确认能正常启动到起始场景，主菜单、场景切换、几个核心玩法功能都点一遍。这个过程发现的问题都是代码层面的，此时修正成本最低。
第二步是模拟用户拿到文件后的真实场景：把整个构建产物文件夹复制到一个全新的目录，比如C:/Users/<某用户>/Desktop/TestGame，再运行一次exe。这一步能暴露相对路径依赖、权限问题。我遇到过一次资源加载失败就是因为路径写死了绝对路径，代码里用了__dirname拼接路径，换目录后就不对了。
第三步建议在有条件的情况下，把构建产物放到一台干净的Windows虚拟机里跑一遍。不用装Cocos Creator、不用装VS，就是模拟用户电脑的真实环境。这一步能提前暴露两件事：缺运行库（VC++ Redistributable相关的DLL）和系统兼容问题。真等客户反馈“双击没反应”再来排查，到时候既摸不到对方的机器，沟通成本也高。
这三步做完，构建物才算达到可以包装分发的状态。
4. 用Inno Setup制作Windows安装包
4.1 安装包工具选型
Windows上的安装包工具我比较过几款。InstallShield功能全面但偏重，商业授权价格不低；NSIS脚本能力强，但语法相对晦涩，中文资料虽然多，配置灵活度高的同时坑也多；Setup Factory上手快，却也是商业软件。
我目前最常用的方案是Inno Setup，原因有三点：免费开源，授权友好；脚本是类Pascal语法，可读性强，易于入库维护版本；对Unicode和中文的支持很好，不会出现安装界面乱码的问题。
Inno Setup目前由jrsoftware维护，官网直接可以下载，安装后自带编译器ISC和IDE可视化编辑界面。虽然IDE可以做可视化配置，但安装包这种事情要做出版本管理，脚本入Git是正道，所以实际使用中主要写脚本。
4.2 一个可直接复用的安装脚本模板
下面这个脚本是经过多个项目实测过的模板，可以直接替换关键字段使用。保存为MyGameSetup.iss，用Inno Setup打开编译即可。
; MyGameSetup.iss [Setup] AppId={{8B5E9A1C-3D7F-4E9B-A2C6-7F7C9B0E5D21} AppName=MyGame AppVersion=1.0.0 AppPublisher=YourStudio DefaultDirName={autopf}\MyGame DefaultGroupName=MyGame UninstallDisplayIcon={app}\MyGame.exe OutputDir=D:\build\installer OutputBaseFilename=MyGameSetup_1.0.0 Compression=lzma2 SolidCompression=yes ArchitecturesAllowed=x64 ArchitecturesInstallIn64BitMode=x64 [Files] Source: "D:\build\MyGame\*"; DestDir: "{app}"; Flags: recursesubdirs ignoreversion Source: "D:\build\vcredist\VC_redist.x64.exe"; DestDir: "{tmp}"; Flags: deleteafterinstall [Icons] Name: "{group}\MyGame"; Filename: "{app}\MyGame.exe" Name: "{autodesktop}\MyGame"; Filename: "{app}\MyGame.exe"; Tasks: desktopicon [Tasks] Name: "desktopicon"; Description: "创建桌面快捷方式"; GroupDescription: "附加任务:" [Run] Filename: "{tmp}\VC_redist.x64.exe"; Parameters: "/install /quiet /norestart"; StatusMsg: "正在安装系统运行库..."; Flags: skipifdoesntexist Filename: "{app}\MyGame.exe"; Description: "启动 MyGame"; Flags: nowait postinstall skipifsilent脚本里几个关键点我单独说明，这些是容易踩坑的地方。
DefaultDirName我使用的是{autopf}，对应Program Files目录。如果游戏需要写存档、生成日志、保存配置，Program Files目录会面临权限限制。这种情况下建议改成{userpf}，也就是安装到当前用户的Program Files下，这样无需管理员权限也基本不会遇到写权限问题。具体怎么选看你的游戏是否需要写运行时文件，我大多数项目直接就用{userpf}减少售后问题。
ArchitecturesAllowed和ArchitecturesInstallIn64BitMode这两个参数，如果你只构建了x64版本，一定要加上。否则安装包在32位系统上也能装，装了也跑不起来，用户体验很差。
[Files]段里用recursesubdirs递归包含构建产物整个目录。注意我用的路径是D:\build\MyGame\*，这个路径必须指向构建输出目录而不是上层目录，否则会把无关文件一并打包进去。
VC_redist.x64.exe我会放在一个单独目录D:\build\vcredist里。[Run]段里通过{tmp}解压后静默安装，参数/install /quiet /norestart是VC运行库官方支持的静默安装参数。这一行能解决困扰大量用户的“双击exe没反应”问题，因为目标机器上很可能没有对应的VC++运行库。
4.3 脚本化构建与版本号管理
安装包制作也应该脚本化。Inno Setup自带的ISCC.exe命令行编译器可以集成到批处理或CI流程中。
"C:\Program Files (x86)\Inno Setup 6\ISCC.exe" MyGameSetup.iss我给团队搭建的流程是：改版本号 → 使用Cocos Creator命令行构建新包 → ISCC编译安装包 → 输出带版本号的exe安装包。整个流程全自动，不用打开Creator界面点鼠标。
版本号管理上有个小技巧：安装包的OutputBaseFilename里带上版本号，比如MyGameSetup_1.0.0.exe，方便归档、回滚和排查“用户装的是哪个版本”这类问题。
4.4 安装包体积与压缩优化
Cocos Creator构建产物本身就包含引擎资源和游戏资源，包体体积通常不小。Inno Setup的lzma2压缩算法在默认参数下压缩率已经比较理想，不需要额外配置。
如果安装包超过1GB，我建议用SolidCompression=no来换取更快的安装速度，或者考虑改用Compression=lzma/ultra来提高压缩率但加长压缩时间。这取决于你的分发场景：走官网下载，包体越小越好，压缩时间长点在构建机多花几十秒完全值得；走本地U盘分发，安装速度更重要，压缩率可以适当放宽。
另外一个小经验：如果构建产物里包含大量音频视频资源，可以观察一下这些资源的编码格式。比如BGM是未经压缩的wav，构建产物会非常大。这种情况下更适合在项目资源层面做压缩优化，而不是指望安装包压缩算法，因为安装包压缩后用户安装时还需要解压，解压后文件还是那么大。
5. 常见问题排查与优化手段
5.1 exe双击没反应
这是Windows桌面版最常见的售后问题。原因通常是两个：运行库缺失、或者exe被单独拷贝。
运行库缺失的排查方法：在构建机上装一个干净的Windows虚拟机，把exe复制进去双击，Windows会弹错提示缺少某个DLL。实际操作中，最常缺的是VCRUNTIME140.dll和MSVCP140.dll，这两个文件都属于VC++ 2015-2022 Redistributable。解决方案就是前面安装包脚本里加的VC_redist.x64.exe静默安装。
exe被单独拷贝的问题，不仅是外部用户容易犯，有时候公司内部测试也会犯。把整个构建文件夹压缩成一个zip再分发给测试同事，能从根本上避免这个问题。如果后续要做安装包，这个问题自然就不存在了。
5.2 白屏或黑屏
如果exe能启动但画面是白屏或者黑屏，优先级从高到低排查。
第一步，打开Windows事件查看器 → 应用程序，看有没有对应的错误日志。如果日志中有应用程序错误，比如模块崩溃信息，说明是JS层跑挂了。构建时临时打开调试模式重新构建，就能通过远程调试看到具体的报错堆栈。
第二步，确认显卡驱动的兼容性。Cocos Creator 3.x默认走的是图形API，如果目标机器显卡太老，尤其是虚拟机环境，容易出现渲染问题。一些集成显卡的老笔记本也会碰到。我在一个政府客户的台式机上就遇到过一次黑屏，最后是更新显卡驱动解决的。
第三步，排查是否用了目标机器不支持的纹理格式或Shader特性。如果素材的纹理格式设成了只有移动端支持的方式，且平台覆盖设置混乱，Windows上会加载异常。把资源管理器里对应的平台覆盖删掉，让引擎走默认格式构建，通常能解决。
5.3 杀毒软件误报与数字签名
自己构建的exe没有数字签名，很容易被Windows Defender和第三方杀软件误报。这个问题在开发圈子里见得太多了，一个大团队费半天劲做了一个游戏，用户下载安装包一运行直接被杀软干掉。
短期解决方案是引导用户手动加白名单。在安装包界面放一句提示“如果杀毒软件误报，请添加信任”，能挡掉一部分售后问题，但体验很差。
中期解决方案是申请代码签名证书，给exe和安装包加上数字签名。个人版证书几百元一年，企业版（OV）证书会贵一点，但能明显降低误报率。签名后的exe在Windows SmartScreen上会显示“已验证的发布者”，这对用户信任度的提升非常明显。
还有一个小经验：构建机环境要保持干净。如果构建机上装了各种调试工具、内存补丁软件，构建出来的exe文件特征容易被杀软扫描并标记。我在团队里规定发布包必须在专用构建机上产出，不允许在个人开发机上直接出正式包，误报率降了很多。
5.4 分辨率与显示适配
Cocos Creator构建的Windows程序默认窗口大小，是由游戏初始化时的设计分辨率和适配模式决定的。你在设置里配的设计分辨率是750x1332的话，直接打开桌面版就是一个竖屏小窗口，这在PC上怎么看怎么别扭。
桌面版发布前，在代码启动阶段要判断平台并设置合理的窗口大小。比如使用screen.windowSize设置窗口为1280x720或者1920x1080，同时把适配模式设置为适配高度或者等比例缩放，确保画面不要变形。
还有一点容易被忽略：高分屏缩放。Windows系统缩放比例如果是125%、150%，旧的引擎版本会出现界面模糊的问题。3.8版本对DPI的适配比旧版好了一些，但如果项目里有用到自定义的DOM元素或系统对话框，还是要逐个检查清楚。
5.5 单实例运行
Windows桌面程序还有一个细节：如果用户连续双击两次exe，会启动两个游戏进程。对大部分游戏这个不是致命问题，但如果是联机游戏或者有本地服务器逻辑，多个实例会引发各种诡异的问题。
解决方案是给exe加单实例限制。Cocos Creator原生壳实现单实例需要改原生代码，如果不想动原生工程，可以用一个取巧的办法：在游戏启动逻辑里检测本地Socket端口是否被占用，如果被占用说明已有实例在运行，直接退出。这个方法简单稳定，还不用动原生工程，适合团队快速验证。
还有个更实用的方案是做一个“启动器”exe，引导玩家先通过登录器检查版本、更新资源、再拉起游戏主进程。这种做法在PC游戏里非常常见，一方面解决了单实例问题，另一方面也为后续热更新提供了入口，有条件的话很推荐。
6. 命令行构建与团队协作落地
6.1 Cocos Creator命令行构建
如果项目发布频率高，或者团队里有多个人需要出包，我建议把构建发布流程脚本化。
Cocos Creator本身支持命令行构建。以3.8.x为例，可以直接调用编辑器可执行文件传入构建参数：
"C:\ProgramData\cocos\editors\Creator\3.8.2\CocosCreator.exe" --project D:\MyGame --build "platform=windows;debug=false;md5Cache=true"命令行支持的参数非常多，包括构建平台、输出目录、起始场景、DEBUG开关等。真正落地时，我会在项目根目录维护一个build-config.json，把常用的构建参数固化在里面，然后写一个批处理脚本循环读取并调用编辑器构建。
这个方案的好处非常明显：不再依赖某个人电脑上的编辑器配置；新同事拉下代码之后一条命令就能出包；构建流程可以接入CI，比如每天凌晨自动出包，早上测试同学直接取最新的包测试。
6.2 构建产物与安装包的仓库管理
构建产物和安装包属于典型的大二进制产物，不适合直接进Git。团队内部通常用两种方式管理：上传到内部文件服务器或对象存储，由构建脚本统一命名归档；或者使用CI平台如Jenkins/GitHub Actions，构建产物作为流水线产出物留存。
归档命名我统一使用这个规范：[项目名]_[平台]_[版本号]_[构建时间]，比如MyGame_windows_1.0.0_20250115.exe。版本号必须在构建配置里统一管理，不要每次手填。我见过太多次“最终版最终版”这样的命名，等到用户反馈bug时根本对不上是哪个包。
如果项目后续要做热更新，建议从第一天就开始记录每个版本的构建信息，包括Creator版本、引擎版本、源码commit号、构建时间。这些元数据在排查问题上能帮大忙，尤其是遇到“这个包是不是新代码”这类问题时，一份完整的版本记录能省下一个下午的扯皮时间。
6.3 多版本分发策略
不同用户群体可能需要不同的版本。企业客户可能要求32位兼容版，线上渠道更倾向64位版。如果确实需要同时维护32位和64位，我的建议是构建阶段就分开，安装包也分开命名，不要试图做一个“万能安装包”同时兼容两种架构。
另外，Windows桌面版的更新策略也要在规划阶段想清楚。如果游戏需要频繁更新内容，安装包模式下每次发版用户都需要重新下载安装，体验很差。可行的方案是做一个轻量更新器：主程序启动时检查服务器上的版本号，如果是新版本，先下载增量资源和脚本，再重启进入游戏。Cocos Creator的热更新方案在原生端是可以落地的，虽然配置麻烦一些，但对于长线运营项目，这个投入是值得的。
7. 一些踩坑后的真实体会
最后分享几个我在多个项目里反复验证、最终沉淀下来的原则。
构建发布要在项目早期就完整走通一次。不要等到游戏开发到后期才第一次尝试构建Windows包。提早暴露问题，比如路径兼容、平台判断、纹理格式、运行库依赖，这些问题越早发现成本越低。我见过一个项目上线前一周才发现Windows构建产物打不开，原因是启动代码里有平台专属API没有加判断，那两天团队加班到凌晨，整个节奏全乱了。
构建产物当作正式交付物管理。发布包不是本地调试用的临时文件夹，要单独归档、打标签、带版本号，和源码仓库的commit对应起来。没有版本管理的发布流程是灾难，特别是在多人协作和客户对接的场景里，谁都不敢拍着胸脯说“这个包就是最新的”。
把“装得上、打得开、不被杀软拦”当作安装包的最低标准。在这三个基础上再谈后续的体验优化。我通常会在正式对外发布前，找一台完全没有开发环境、没有装过任何运行库的干净Windows电脑走一遍安装流程，这一步能过滤掉80%的售后问题。
最后分享一个小技巧：把自己的电脑系统用户名设置成英文。Windows用户名如果是中文，会直接影响Cocos Creator的构建路径和部分临时目录，很多奇怪的构建失败其实都源于此。环境干净、路径规范、流程脚本化，这三件事做好了，Cocos Creator构建Windows发布包这件事，基本就是一条稳定的流水线了。
