企业官网建设流程全解析

简介：面向需要制作 MSI 安装包的软件开发者、打包工程师与部署人员，Advanced Installer 20.7.1 提供了图形化的 Windows Installer 编写环境，能够生成符合 MS Windows 认证的安装程序，并支持自定义欢迎界面与安装过程界面。资源包内含约 2000 个文件，压缩后约 161MB，文件构成以 png/jpg/ico 等图形素材、aip 工程文件、xsd/xml 配置模板为主，另有少量 msi 示例包和 rtf/html 说明文档，便于理解安装包结构并复用界面素材。目前已有 940 人学习/下载。通过这批资料，可以快速掌握 Advanced Installer 的项目组织方式，借鉴内置的多种界面模板和本地化配置，直接修改 aip 工程即可生成符合 Windows 规范的 MSI 安装包；丰富的图片、图标与 XAML 资源也为安装界面的视觉定制提供了现成素材。对于希望系统学习安装包制作或需要参考成熟打包方案的技术人员，这是一份实用且完整的工具参考。

1. 为什么要用 Advanced Installer 20.7.1 做软件打包：从“发个 ZIP”到“正规安装包”

做 Windows 软件分发，最掉价也最坑的就是“发个压缩包让用户自己解压”。用户解压完不知道点哪个 exe，杀毒软件把文件当可疑程序隔离，卸载的时候连注册表和快捷方式都清不干净——这些问题所有做过交付的人都遇到过。Advanced Installer 是我拆过一遍后觉得最值得长期用的打包工具，它解决的不只是“把 exe 包一层”，而是把 VC++ 运行库合并、注册表写入、快捷方式管理、升级与卸载逻辑全部收进一个工程文件里，单独发布了 20.7.1 这个稳定版本。适合谁用？主要面向两类人：一类是给客户做交付的 C/S 架构开发者，另一类是把内部工具分发给非技术同事的运维。前者关心 MSI 的干净安装和卸载回滚，后者关心双击下一步就完事、不用解释“环境变量怎么配”。

Advanced Installer 的免费版覆盖了大约 90% 的普通软件打包需求，支持创建 MSI 和 EXE 安装包、内置启动条件检查、支持安装后运行配置，20.7.1 这个版本还完善了 MSIX 支持和更新功能。下面的所有操作我都基于 20.7.1 的免费版做演示，完全够用。

2. 用 Advanced Installer 20.7.1 创建第一个 MSI 安装包：从新建工程到生成产物的完整流程

2.1 工程类型怎么选：MSI 还是 EXE，别一上来就点错

打开 Advanced Installer 20.7.1 后，第一步不是直接拖文件，而是面对一个工程类型选择界面。很多人在这就翻车了——误以为 EXE 工程比 MSI 更高级，选了 EXE，结果后面打包出来的东西既没法做组策略推送，也没法用标准方式做卸载修复。实际上，对于绝大多数 Windows 桌面应用，优先选 MSI 工程，理由很具体：MSI 是 Windows Installer 的标准格式，卸载信息会注册到“程序和功能”面板，支持修复安装，也支持通过 Active Directory 或 SCCM 推送。EXE 工程适合什么场景？适合你需要在安装前跑一段自定义检测脚本、或者要对安装包做自解压和静默参数定制的场景。

在 Advanced Installer 20.7.1 里，新建工程时有六个模板：MSI - 简单版、MSI - 专业版、EXE - 简单版、EXE - 专业版、MSIX 打包、Pure MSI。简单版和专业版的区别在于是否预置了更多功能页面，对多数应用，选 MSI 简单版就够。这里有个判断标准：如果你的应用安装目录默认装在 Program Files 下，且不需要安装时动态生成配置文件，简单版够用；需要安装时让用户输入序列号、或按用户类型勾选功能组件，就选专业版。我一般默认选专业版，省得后期要加功能时发现工程类型锁死，还得重新迁移。

2.2 把文件拖进工程：目录结构决定了安装后的真实布局

选择工程类型后进入主界面，左侧是功能树，中间是资源面板。添加程序文件的方法是：在左侧树里展开“文件”节点，右键点击“应用程序文件夹”，选择“添加文件夹”，然后把你的 exe、dll、配置文件全部拖进去。这一步有个关键点——安装包里的目录结构会和最终安装到用户机器上的结构完全一致，所以如果你在开发环境里依赖相对路径读取配置，那拖进去时就必须保持原来的目录层级。很多开发者的习惯是直接选中 Release 文件夹往里拖，这个做法没问题，但要注意把config、logs这类可写目录单独处理，不要放进 Program Files 下的安装目录里，后面权限会在正式环境出问题。

文件添加完后，点一下左侧“应用程序文件夹”，能在右侧属性面板里调整文件和文件夹属性。这里建议勾选“始终安装”选项，避免文件因为版本号相同被安装器跳过。另一个要在这一步处理的点是：如果你的程序依赖 VC++ 运行库，比如基于 MFC 或 Qt 编译出来的程序，普通的文件拖入并不能解决目标机器缺运行库的问题。Advanced Installer 20.7.1 里要在“先决条件”节点里勾选对应项，常见的是“Visual C++ 2015-2022 Redistributable (x64)”，它会自动把运行库合并进安装包或设定为下载安装。两者区别后期我会说清楚。

工程文件与安装内容的对应关系： Applications Folder（对应安装目录，默认 Program Files\{ProductName}） ├── MyApp.exe -> 主程序 ├── MyApp.dll -> 动态库，勾选“始终安装” └── config.ini -> 配置文件，建议移动到 Common AppData 或用户目录

拖入文件只是第一步，真正影响安装体验的是文件和目录的属性设置。在这个面板做三件事：第一，给主程序 exe 设置“始终安装”；第二，如果你有多个版本的 dll 需要共存，关掉“相同版本跳过安装”的默认行为；第三，记录一下你放在应用程序文件夹里的总体积，因为后面配置升级包时，体积差会被用来判断是否需要执行整体替换。

2.3 产品信息与版本号：这里填错会直接导致升级失败

左侧树切到“产品信息”节点，这里的四个字段决定了安装包的身份标识：产品名、版本号、制造商、产品代码。前面三个都好填，版本号格式是主版本.次版本.修订号，比如 1.0.0。最容易踩坑的是“产品代码”这一项——每次生成新安装包时，如果你的程序版本是升级而不是全新安装，产品代码要保持不变，而“升级代码”可以变。Advanced Installer 20.7.1 在新建工程时会自动生成一个随机 GUID 作为产品代码，你只要别手动乱改就行。但如果你用旧工程文件来制作升级包，一定要检查这个 GUID 和上一次发布是否一致，不一致会导致控制面板里出现两个卸载条目。

这里有一个容易被忽略但非常实用的逻辑：升级代码（Upgrade Code）是 Windows Installer 用来识别“同一个产品不同版本”的标识符。你的安装包从 1.0 升级到 1.1，产品代码不变、升级代码不变，安装器才能正确执行“覆盖安装”。如果产品代码变了，安装器会认为这是两个完全不同的软件，旧版本不会被卸载，新版和老版的文件混在同一目录里，各种诡异问题就来了。我用过很多打包工具，这个点没搞清楚的团队不在少数，往往要等用户报“装完新版本程序打不开”才发现是两个版本文件混在一起。

2.4 生成安装包：Debug 与 Release 的差异、签名与输出路径配置

左侧树里找到“构建”节点，展开后能看到发布类型列表，默认是“可本地安装”。双击它，右侧弹出构建配置面板。在这个面板里，你要设置的是输出目录和安装包文件名格式。我建议把输出文件名的格式设为{产品名}_{版本号}_x64，这样你在交付多个版本时，不会出现“最终版 1.0”这种文件名。

构建配置里有一个选项叫“生成 MSI 时同时生成 EXE 引导程序”，建议勾选。这个 EXE 不是另一个安装方式，而是一个引导壳，它会检查目标机器上的 Windows Installer 版本和 .NET Framework 版本，不满足条件时先补环境，再解包执行里面的 MSI。对于给非技术用户分发，直接给 EXE 更省事，静默安装参数也能透传。

签名这一步我单独强调：如果你的公司有代码签名证书，在“安全”节点里导入 pfx 文件，然后勾选“在构建时签名”。没签名的情况下，安装包在 Win10/Win11 上会被 SmartScreen 拦截一次，用户需要手动点“仍要运行”，这直接拉低体验。没有证书的话建议至少做哈希校验文件，后面也能给用户一个验证手段，虽然不是真正的信任链。20.7.1 版本支持 SHA-256 签名，相比旧版强制 SHA-1 是一个升级点。

构建配置设置完成后，点击顶部菜单栏的“构建”按钮，Advanced Installer 开始编译安装包。完成后到输出目录看到生成的 .msi 和 .exe 文件，这两个文件就是最终交付物。把 MSI 发给企业 IT 用户用于静默部署，EXE 发给个人用户安装。

3. 安装流程定制与参数配置：从交互界面到静默安装的完整链路

3.1 安装过程界面怎么定制：对话框顺序与被隐藏的页面

Advanced Installer 20.7.1 的免费版允许修改一部分安装界面文本，但你能控制的不是 UI 设计，而是对话流程的增删。在左侧树“安装程序界面”节点下，能看到安装过程中会出现的一系列对话框页面：欢迎页、信息页、许可协议页、安装类型页、目标文件夹页、就绪页、安装进度页、完成页。

这里我做一个实用推荐：面向企业内部分发时，建议把“安装类型页”去掉，因为绝大多数用户不需要选择“典型/自定义/完整”，自定义安装只会在后续升级时带来“某些组件没装上”的工单。去掉方法是选中该页面，右键选择“禁用”。目标文件夹页看情况保留，如果应用不支持任意盘符安装，比如连的是相对路径的本地数据库，就固定安装路径，此时禁用该页面并把安装路径写死到“产品信息 - 属性信息 - 安装路径”里。

另一个关键配置是“完成页”的选项——这里可以设置安装完成后是否立即运行程序。我建议设置为“不运行”，除非你的程序有首次启动引导配置要跑。原因很简单：安装完自动弹出来的第一视觉，如果出现的是程序主界面而不是用户预期的东西，反而会增加困惑。

推荐保留的安装页面顺序： 欢迎页 -> 许可协议页 -> 就绪页 -> 安装进度页 -> 完成页 禁用：安装类型页、目标文件夹页（当安装路径固定时）

这个顺序能保证安装步骤最少，用户操作最少，出错概率最低。Advanced Installer 里保存了所有这些设置后，Ctrl+S 保存工程文件.aip，备份好这个文件，后面做升级包直接基于它改版本号即可，不要每次从零建工程。

3.2 先决条件配置：让安装包自动带上 VC++ 运行库和 .NET Framework

前面提到过“先决条件”节点，这里把参数一次说清楚。在左侧树里展开“先决条件”，右侧会列出大量可勾选的组件，包括 .NET Framework、VC++ Redistributable、DirectX、WebView2 等。每个组件有两种处理方式：“从网络下载”和“从本地合并”。20.7.1 里默认是下载方式，即安装时从微软官方源获取并安装，好处是安装包体积小，坏处是目标机器没外网时安装直接卡死。内网企业用户建议切换为“从本地合并”，前提是你把对应的安装引导文件放到 Advanced Installer 指定的文件夹里。合并后安装包体积可能增加 20 MB 到 80 MB，换来的是离线可装，这个代价值得。

选先决条件这个环节必须克制。很多人的习惯是看到运行库就全勾上，实际上会造成安装时间翻倍。以我的经验，大多数 VC++ 应用只需要一个vc_redist.x64.exe；用 .NET 开发的程序则只需要对应的 .NET Runtime 或 Desktop Runtime。判断标准很简单：在你干净的 Windows 测试虚拟机上装一次运行你的程序，报什么缺什么就勾什么，不预判需求。

3.3 注册表与快捷方式：安装逻辑中最容易被忽视的两个部分

打包工具最核心的价值不只是把文件拷过去，还在于把软件运行的“周边环境”建好。注册表这部分，Advanced Installer 的“注册表”节点里，你可以预定义安装时写入的键值。我在实际项目中遇到的一个典型需求是：程序需要写HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany\MyApp下的数据库连接字符串，或者需要在注册表里登记一个版本号供外部脚本查询。在注册表节点里操作方式和 regedit 一致，右键新建键、新建值，支持字符串和 DWORD 类型。注意 x64 程序要写在SOFTWARE\WOW6432Node下还是标准路径下，取决于目标程序是 32 位还是 64 位，这个区分错了注册表读不到。

快捷方式不是简单地把桌面快捷方式和开始菜单快捷方式建好，而是要考虑卸载时的清理。你需要选中主程序的 exe 文件，右键选择“创建快捷方式”，这样创建的快捷方式和文件是绑定关系，卸载时自动识别删除；如果手动去模拟创建，卸载后桌面上会遗留坏掉的快捷方式。如果你的程序是 64 位版本，要为shellexecute参数设置工作目录，部分程序双击快捷方式找不到配置文件，就是因为启动时的当前目录不对。在快捷方式属性里把“开始位置”填成主程序所在目录，这个问题直接解决。

3.4 静默安装与常用命令行参数：给运维兄弟留一条路

Advanced Installer 生成的 MSI 安装包天然支持 Windows Installer 的标准命令行参数，这个能力不需要额外配置。测试静默安装时，在命令行里输入下面这段：

msiexec /i "MyApp_1.0.0_x64.msi" /qn /norestart

参数说明：/i表示安装，/qn表示完全静默不显示任何 UI，/norestart表示安装完成后不自动重启。如果 MSI 里包含先决条件并且配置为“从本地合并”，静默安装会一次性处理完所有内容；如果配置为“从网络下载”，静默模式下仍会弹出下载提示，因为网络下载需要用户确认，所以在企业环境里必须先做本地合并。

卸载同样走命令行：

msiexec /x "MyApp_1.0.0_x64.msi" /qn

如果要给某些需要指定安装路径的场景设置参数，在构建配置里启用“公开属性”支持，就能通过命令行传INSTALLDIR属性：

msiexec /i "MyApp_1.0.0_x64.msi" INSTALLDIR="D:\MyApp" /qn

这个功能必须在 Advanced Installer 的“属性信息”里把INSTALLDIR注册为公开属性，否则 MSI 会忽略命令行传入的路径值，命令行属性直接失效。这是一个非常典型的配置坑，后面我会放在避坑清单里再提一次。

4. 避坑指南：四个最常见的 Advanced Installer 翻车现场、原因与补救

4.1 安装包双击没反应：日志全在事件查看器里

现象：生成好的 MSI 在 Windows 10 企业版上双击之后没有任何界面弹出，进程列表里 msiexec 闪一下就消失。原因通常有两个：一是目标机器上 Windows Installer 服务被组策略禁用；二是安装包启动了提升权限提示，当前账号权限不够，UAC 默认策略下直接被忽略。解决：先确认 msiexec 服务存在，再检查事件查看器里的安装日志。我的习惯是第一时间用带日志的方式重跑安装命令，把日志写到本地文件，再逐行排查。从事件查看器定位到 MSI 的MsiInstaller事件，报错代码能直接指示问题方向。注意免费版不提供可视化日志分析器，只能靠 Windows 系统日志，这一点要提前想清楚，别现场抓瞎。

4.2 升级安装后桌面出现两个快捷方式

现象：用户从 1.0 升级到 1.1 后，桌面没有出现新版快捷方式，反而出现两个名字只差一点点旧版快捷方式。原因：1.1 版本打包时修改了产品代码或升级代码，Windows Installer 没有把它识别为“同一产品版本升级”，而是当成两个独立软件分别安装了各自的快捷方式。解决：回到 1.1 工程文件，核对“产品信息”中的产品代码与 1.0 保持一致，重新构建发布。在那之后我形成了强制习惯，每次为老工程做新版本，第一步先打开工程文件确认产品代码，再改版本号和文件内容，不再临时新建一个工程来碰运气。

4.3 静默安装时 INSTALLDIR 属性被忽略

现象：用命令行传INSTALLDIR=D:\MyApp执行静默安装，装完发现程序还是装到了默认的 Program Files 目录。原因：MSI 默认只允许二分之一的属性从命令行传入，属性必须是“公开属性”，即属性名全大写且出现在Property表里。解决：Advanced Installer 里打开“属性信息”，点击属性列表右上角的“编辑”，找到INSTALLDIR这一行，勾选“公开”列，然后重新构建。另一个办法是直接传APPDIR，因为安装包默认把安装目录的公开属性名定为APPDIR，这是 Advanced Installer 的默认行为，用APPDIR传参大概率可以直接生效。我遇到一次后用回APPDIR参数，之后所有工程统一用这个，不再依赖自动检测逻辑省事，省得再踩坑。

4.4 64 位程序在 32 位系统上直接安装失败

现象：安装包在特殊环境（如某些低配测试机）上安装报错，提示不是有效的 Win32 应用程序，安装终止。原因：目标系统是 32 位 Windows，而安装包中没有任何引导逻辑判断系统架构，也没有禁用安装或替换为 32 位版本。解决：在 Advanced Installer“启动条件”里，添加一条“操作系统类型”检测规则，设置为“64 位操作系统”，并在“不满足条件时显示的消息”里写上“当前系统为 32 位，无法安装本软件”。如果你同时维护 32 位和 64 位两个版本，更好的方案不是在安装阶段拒绝，而是生成两个独立的安装包分别分发。这条规则在构建配置里是“系统架构”，每次新建工程我都会先确认这个条件，避免后续安装到一半才报错，回滚麻烦得多。

5. 命令行打包与高级构建配置：把 Advanced Installer 20.7.1 接入持续集成流程

5.1 命令行编译工具 aic.exe 的基本用法与参数说明

Advanced Installer 20.7.1 自带命令行工具aic.exe，路径通常在安装目录的bin\x86子文件夹下。它的作用是让你摆脱手动点击“构建”按钮，通过脚本完成打包流程。这在需要每日构建或频繁发版时很有价值，人肉点按钮永远不会比脚本构建更稳定，尤其当你有多个版本的工程文件要分别打包时。用法很简单：

"C:\Program Files (x86)\Caphyon\Advanced Installer 20.7.1\bin\x86\aic.exe" /build "MyApp.aip"

/build后会直接按照工程文件里最后一次保存的构建配置生成安装包。aic.exe在没有安装完整 Advanced Installer 的环境中不可用，它依赖注册的 COM 组件和许可证状态。所以无论你用 Jenkins 还是 GitLab CI，构建机都必须完整安装 Advanced Installer，并在首次启动时完成许可证登录。这一步常常被忽略，是 CI 接入过程中最常见的断点。

5.2 构建前自动更新版本号：利用构建事件执行 PowerShell 脚本

如果你不想每次都手工在工程文件里改版本号，20.7.1 支持“构建”节点下的“外部工具”和“事件”配置。在“构建”节点的“事件”页面中，可以配置"构建开始前"执行一段命令行脚本。我在这里做的是：构建前运行一个 PowerShell 脚本，读取工程文件里的版本号并做增量更新，然后重新写入.aip文件。一个可参考的脚本结构如下：

# 自动将 1.0.0 递增为 1.0.1 的示例脚本，供 Advanced Installer 构建事件调用 $path = "C:\Build\MyApp.aip" $content = Get-Content $path -Raw # 匹配类似 <Version>1.0.0</Version> 的节点并递增修订号 $content = $content -replace '(<Version>)(\d+\.\d+\.)(\d+)(</Version>)', { $prefix = $_.Groups[1].Value $middle = $_.Groups[2].Value $rev = [int]$_.Groups[3].Value + 1 $suffix = $_.Groups[4].Value "$prefix$middle$rev$suffix" } Set-Content $path -Value $content

这段脚本做的事是按正则匹配替换.aip文件中的版本号。(\d+\.\d+\.)匹配前两位数字加句点，(\d+)匹配当前修订号，替换时加一。运行后工程文件版本号变化，随后触发的构建命令会直接产出新版本的安装包。注意脚本执行时.aip文件不能被 Advanced Installer GUI 打开着，否则文件被锁定写入失败，会是预期之外的报错。这是唯一的注意点，其他没有坑。

使用该方案的逻辑是：发布版本由 CI 构建次数驱动，避免手工修改版本号造成的漏改或重复。大批量使用时，你也可以把版本号来源改成一个独立文本文件，让构建脚本从文本读取并填入，而不是每次改工程文件，后期更灵活，不至于版本冲突。

5.3 构建产物自动复制到发布目录：后续步骤直接接上传流程

打完包之后把产物复制到共享目录或 FTP，还有一个更直接的思路：在 Advanced Installer 的构建配置中指定输出目录，并配合同一脚本把 MSI 和 EXE 复制到最终发布目录。一个完整构建脚本段落大致如下：

# 编译并复制安装包到发布共享目录 "$AI_BIN\aic.exe" /build "MyApp.aip" $version = (Select-String -Path "MyApp.aip" -Pattern '<Version>.*</Version>').Matches[0].Value $dest = "\\build-server\releases\MyApp_$version" New-Item -ItemType Directory -Path $dest -Force Copy-Item "Output\*.msi" $dest Copy-Item "Output\*.exe" $dest

这段脚本的要点是：$version从工程文件里重新提取一次，保证目录名和实际包内的版本号一致。Copy-Item会把所有安装包复制过去。使用文件服务器作为发布目录的好处是，后续测试团队可以直接从这个目录获取版本，不需要让运维手动拷贝分发。如果你用的是 CI 内置的产物存档功能，这一步可以省略，但仍然建议至少把安装包统一命名，方便后续追溯。这个环节的唯一禁忌是重复构建时覆盖旧安装包，生产环境说不清哪个版本在用。所以我在复制命令之前会先建带版本号的子目录，避免覆盖。

6. 安装包质量验证的实用技巧：虚拟机快照、日志对比与卸载干净度检查

6.1 用虚拟机维护一个“已验证环境”：不要用你自己的工作机测试安装包

我坚持的验证方法是：维护两台虚拟机，一台是干净的 Win10 21H2 x64，另一台是干净 Server 2019 x64。每台机器上只安装最基础的运行库和出厂补丁，不做任何额外环境配置。验证打包结果前，先给虚拟机拍一个快照，然后在此快照基础上测试安装。测试内容有三项：安装成功后检查“程序和功能”里是否有你要的条目；安装目录下文件数量是否和打包源一致；并手动打开程序确认功能正常。测试完成回滚快照，再测下一个版本安装包。这样做有两个好处：一是保证每次验证的环境一致，不会因为目标机器残留旧版本软件而污染测试结果；二是快速定位问题时排除环境因素干扰。不使用工作机直接测安装包，因为开发机上装了 VS、各种 SDK 和运行库，缺什么依赖都会因为系统里已有环境而被隐藏，测不出真实用户的环境问题。

6.2 通过 MSI 日志对比找到安装失败真实原因：不要靠猜

当安装失败时，用日志定位比读事件查看器高效得多。手动安装时加上日志参数：

msiexec /i "MyApp_1.0.0_x64.msi" /l*v "install_log.txt"

/l*v表示输出详细日志，install_log.txt是日志文件路径。用文本编辑器打开日志后，搜索Return value 3这个关键字，这是安装失败的通用标志。再从它的上下文往上翻几百行，找到MainEngineThread is returning之前的最后一行错误描述。常见错误是Cannot find a file，说明文件缺失；The installer has insufficient privileges说明权限不足。对比正常安装日志和失败日志，差异只集中在报错位置附近的几十行，这种对比能快速定位是权限问题还是文件缺失，不再靠直觉猜。建议对每次失败都保留日志，下次再遇到类似报错时直接找规律，效率高很多。

6.3 卸载干净度检查：卸载后是否残留注册表和目录

很多人验证安装包只测“装上能不能用”，忽略了卸载后系统是否被污染。我会在 VirtualBox 快照环境里，安装完再卸载，然后检查三处：注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall下是否还有该产品的条目；安装目录是否还残留文件；开始菜单快捷方式是否还被留下。如果卸载不干净，用户重装时遇到旧配置文件残留会导致奇怪问题，这种问题最难排查。

要解决卸载残留，需要回到 Advanced Installer 工程文件，检查是否设置了“删除安装目录”选项。具体的做法是：在“文件”节点里，右键你的应用程序文件夹，属性面板中勾选“卸载时移除整个文件夹”。这一步很容易漏掉，尤其在简单版工程里，默认识别的移除范围只有你安装时新建的文件，如果程序运行后在安装目录下生成了缓存文件，卸载后它会被留下。注意：config和logs目录不建议勾选删除，因为卸载软件不应该删掉用户数据和配置信息，但主程序目录要清理干净。这个取舍做完之后再做卸载验证，才敢把安装包放出去。

从那以后，我每次打完安装包都强制在虚拟机里走一遍完整流程：装、开、卸、查注册表、查残留目录，所有验证过了才往发布目录放。这套流程虽然半天时间搭好虚拟机，但换来的是发布后用户环境零报错，希望这一整套从建工程到验证的流程帮到你，也帮你少走几次我走过的弯路。

本文还有配套的精品资源，点击获取