引言 ------ 桌面应用的「最后一公里」
第一次做 Flutter Windows 桌面应用的时候
arduino
flutter build windows --releasebuild 完之后， Release 目录几十个 DLL、data、exe、资源文件......
这玩意怎么发给用户？
复制整个目录，然后双击 exe
真正交付用户之后，桌面应用真正困难的不是开发，而是安装。
此时基于安装器场景出发，就凸显出以下几点需求
- 创建开始菜单快捷方式和桌面图标；
- 在控制面板注册卸载入口；
- 建立文件关联，支持双击产物图标能打开应用；
- 支持覆盖升级，但阻止降级；
- 在企业环境允许管理员为所有用户安装，在个人电脑上允许仅当前用户安装。
Windows 作为全球使用人数最多的 PC 平台，在面对客户端打包方案上同样存在多种选择
这些看起来是「基础功能」，但不同打包方案对它们的支持方式和程度截然不同； 摆在面前的选择主要有两个方向：NSIS VS MSIX
一、主流方案，NSIS VS MSIX
NSIS（Nullsoft Scriptable Install System）诞生于 2000 年，是一个命令式的安装器脚本引擎。开发者用类汇编的 .nsi 脚本精确控制安装器的每一步行为：解压哪些文件、写哪个注册表路径、创建哪种快捷方式、检测什么前置条件------一切行为可预期、可调试。
MSIX 是微软在 2018 年推出的现代打包格式，采用声明式清单（AppxManifest.xml）描述应用结构，运行时通过虚拟化层（文件系统重定向 + 注册表虚拟化）隔离应用，安装和卸载由操作系统统一管理。
NSIS 是把刀直接递给你，你想怎么切就怎么切；MSIX 是一套自动切菜机，省心但有边界。
二、国内外使用差异
选安装包方案，不能只看技术先进不先进，还得看用户到底是怎么拿到这个软件的。
对于海外市场，或者 Microsoft Store 生态， MSIX 确实是一个很现代的选择：沙箱隔离、自动更新、卸载干净、权限模型也更规范。但放到国内 Windows 桌面软件场景里，情况就没那么理想了。
国内用户安装桌面软件，最常见的路径是：
搜索引擎搜一下 → 进官网 → 点下载 → 拿到 exe → 双击安装。
这个链路已经被用户教育了很多年，很少有用户想到通过应用商店下载安装软件。你给用户一个 EXE，他会下意识地双击，等待安装向导弹出来，点"下一步"。
虽然 MSIX 支持旁加载，不一定非要走 Microsoft Store，但旁加载本身就意味着你要处理证书、签名、安装策略、系统限制，以及用户机器上各种奇奇怪怪的安全提示。但对于普通用户来说，每多一个弹窗、每多一步配置，安装成功率就可能掉一截。
安装环境差异
要命的是，国内win版本清单多到足够做一个字典。很多政企、传统行业、内网办公机器，依然可能跑着 Windows 7、老版本 Windows 10，甚至是各种定制系统。MSIX 对系统版本有要求，最低也要 Windows 10 1809，这意味着天然会把一部分用户拒之门外。
而 NSIS 作为一个老辈子，是专门处理多系统差异安装的，最早可追溯到XP时代；
通过把安装包打成一个独立 exe，丢到 OSS 或 CDN 上，用户访问官网下载后双击安装。这个模型非常符合国内桌面软件的分发习惯，也最大程度降低了安装门槛。对很多业务项目来说，安装链路越短，用户流失越少，这比安装技术本身是否与时俱进来说更重要。
另外，NSIS 在国内的资料积累也非常深。从早期各种安装包制作教程，到现在大量博客、问答和脚本示例，遇到问题基本都能搜到类似案例。比如创建快捷方式、写注册表、处理卸载逻辑、判断运行环境、做静默安装，这些需求都很常见，团队上手成本也低。
所以这里并不是说 MSIX 不好。MSIX 的设计方向是对的，它更现代、更规范，也更适合 Store 生态和强管控分发场景。只是对我们当前面对的国内 Windows 用户来说，它带来的分发成本，暂时大于它提供的技术收益。
三、看重的点
回到工程决策本身，选择 NSIS，其实可以归结为一句话：
在这个阶段，可预测，比理想化更重要。
对于企业客户来说，我们更关心的是安装包能不能在各种 Windows 环境里稳定跑起来，而不是安装方案看起来有多现代。最终我们的判断是：NSIS 更适合作为当前阶段的主安装方案。它符合国内用户的下载习惯，兼容面更广，行为更透明，团队也更容易维护。
MSIX 当然不会被完全否定。它可以作为后续面向 Microsoft Store 或特定企业分发渠道的独立方案继续探索。但在现阶段，我们不会把它和 NSIS 混在一起用。因为它们解决的不是同一个问题，面向的也不是同一种分发场景。
一句话总结：
NSIS 解决的是"让大多数国内 Windows 用户顺利装上"；MSIX 解决的是"在更现代、更受控的 Windows 生态里规范分发"。当前项目更需要前者。
小结
| NSIS | Inno Setup |
|---|---|
| 插件生态丰富 | 功能丰富（官方） |
| 自定义自由度高 | Pascal Script |
| 社区丰富 | 文档健全 |
| 复杂的自定义安装 | 标准环境安装 |
简单说 NISI 可能对于界面以及官方应用商店支持并不多，但是相较于国内复杂的 win 版本环境，以及整个权限、写入、清除策略上支持更加集成化；
比如对于安装来说，NSIS 做的事情很直接------创建目录，就是在目标路径创建目录；写注册表，就是往真实注册表里写值；创建快捷方式，就是桌面上生成一个 .lnk 文件。它没有太多中间层，也不会把文件和路径藏在某个容器或虚拟化环境里。
这对排查问题非常重要。
比如用户反馈"安装完桌面没有快捷方式"，用 NSIS 的时候，我们可以直接去桌面目录看快捷方式有没有生成，去安装目录看文件有没有复制成功，去注册表看写入是否正常。问题链路是直的，排查路径也是直的。
但如果分发环境本身比较复杂，再叠加 MSIX 的包模型、权限策略和系统版本差异，很多问题就会变成："到底是安装脚本的问题，还是系统策略的问题，还是包容器行为的问题？"这对团队排障效率并不友好。