脚本调整方案一：
json
{
"scripts": {
"start": "electron-forge start",
"package": "electron-forge package",
"make": "electron-forge make",
"package:win32": "electron-forge package -p win32", // 新增
"make:win32": "electron-forge make -p win32", // 新增
"publish": "electron-forge publish",
"lint": "eslint --ext .ts,.tsx ."
}
}脚本调整方案二：
shell
npm run make -- --platform win32解题思路（可选）
解决具体问题的过程中要习得方法论。
思索问题
这个问题进一步拆解，会有哪些问题？
- 首先要确认能否支持？
- 若能支持，环境如何配置？
- 若能支持，项目如何配置？
线索推理
步骤一：找到功能模块：生成window包的模块。
通过官网的目录结构，有两种方式来快速锁定：
- 阅读 Overview 来快速了解各个模块。
- 通过基本演绎法推理 + 阅读简介论证的方式。
细讲方式二：Makers本身最趋向于"打包"的意思，通过简介论证确实如此。
同理：Squirrel.Windows 带个"Windows"八成就是了（推理），看到生成的是exe的文件（验证）。
步骤二：确认 maker-squirrel 模块是否支持。
上面找到的文章并没有相关的线索提及。因此需要重新找资料。
这里需要用到两个重要的常识。
重要常识1：官网的API文档基本都会有对应模块的说明信息。
重要常识2：可以通过项目的链接找到该模块的README文件，里面一般有关键信息或地址。
最终你会找到关键信息：
至此前两个问题已有了明确的解决方案。
步骤三：了解项目该如何配置相关参数。
这里我走了弯路：一开始并没有从脚本参数角度去思考。在自我探索无果后开始了搜索相关博客，直到看到cli参数才点醒了我。
从官网的CLI篇可以找到了关键信息：
重要常识3：及时将博客里的关键信息结合官方文档来进行对照，一来验证方法如今是否可行，二来是建立与官方文档的认知链路。毕竟博客的迭代成本大于官网，而动机又小于官网。
至此，问题就得到了解决。
复盘进阶
吸取了CLI的教训，我大致又浏览了官网其他资料，发现guide模块有一些常见的问题，其中就包括linux环境window包的问题：（真的是蓦然回首，答案却在灯火阑珊处......）
重要常识4：在正确的指令下，好的项目对于问题有日志来引导。
针对常识2与常识5可以为开源社区做贡献：
常识2： 参与一些文档的翻译和更新工作。
常识4： 对于一些日志提示缺失，不合理等提出改进。