1. 为什么你写的AHK脚本总在别人电脑上“打不开”——打包不是点一下就完事的AutoHotkey打包exe这事儿看起来简单写好.ahk文件右键→“Compile Script”选个图标点确定一个.exe就蹦出来了。我最早也是这么干的直到客户发来截图“双击没反应”“提示找不到AutoHotkey.exe”“报错0xc000007b”。那一刻我才意识到所谓“打包”根本不是把脚本塞进一个壳里就完事——它是一次完整的运行时环境交付。你交付的不是一个文件而是一个能在目标机器上自洽运行的最小闭环系统。AutoHotkey本身是解释型语言它的执行严重依赖AutoHotkey.exe这个解释器。v1和v2的解释器不兼容32位和64位解释器不能混用而Windows默认不自带AHK环境。所以当你把一个裸脚本发给同事等于让他凭空安装一个他可能从未听说过的运行时。这就是为什么“打包”二字背后藏着三重陷阱解释器版本绑定、架构位数匹配、资源依赖注入。热搜词里反复出现的“python打包成exe”“pyinstaller打包命令”“qt打包exe”本质都是同一类问题——如何把动态语言的运行时、字节码、依赖库全部静态化、可移植化。AHK的特殊性在于它比Python更轻量但比bat更隐蔽它没有pip生态的复杂依赖树却有更刁钻的Windows权限与UAC交互逻辑。我见过太多人踩坑用v2.0.12写的脚本用v1.1的编译器打包结果生成的exe在Win10上闪退脚本里调用了FileAppend写日志但没处理路径权限打包后一运行就因UAC拦截失败甚至有人把图标文件路径写死为C:\Users\Me\Desktop\icon.ico打包后在客户电脑上直接报错“找不到图标”。这些都不是脚本逻辑的问题而是打包环节的环境契约缺失。真正的打包指南必须从“这个exe启动时Windows到底做了什么”开始讲起——它要加载哪个DLL从哪里读取配置是否需要管理员权限资源文件放在哪这些细节决定了你的脚本是能安静运行还是在用户桌面上弹出一连串红色错误框。所以别再把“Compile Script”当成魔法按钮。接下来的内容我会带你一层层拆开AHK打包的黑盒子从最底层的编译器原理到v1/v2的分水岭差异从图标、版本信息这些“面子工程”的实操填坑到资源嵌入、UAC声明、防杀毒误报这些决定成败的“里子功夫”。这不是一份操作手册而是一份交付清单——每一步都对应着你在客户电脑上少收到一个“打不开”的截图。2. AutoHotkey打包的核心逻辑与方案选型v1 vs v2内置编译器 vs 第三方工具2.1 编译器的本质不是编译是“解释器脚本”的捆绑封装首先要破除一个根深蒂固的误解AutoHotkey的“编译”Compile不是传统意义上的编译。它不会把AHK代码翻译成x86/x64机器码也不会生成独立的可执行指令流。它做的是把你的脚本文本.ahk和一个特定版本的AutoHotkey解释器AutoHotkey.exe或AutoHotkeyA32.exe等打包进同一个PE文件并在启动时由解释器加载并执行脚本内容。你可以把它理解为一个“自解压自运行”的复合体。这个认知直接决定了所有后续决策版本锁定打包生成的exe其行为完全由所捆绑的解释器版本决定。v1.1.33.10打包的脚本无法运行v2.0新增的for var in array语法反之v2.0.12打包的脚本在v1环境下会直接报错Invalid hotkey。架构绑定32位解释器只能生成32位exe64位解释器只能生成64位exe。如果你的脚本调用了DllCall(user32.dll, Ptr, FindWindow, Str, Notepad)这类API且目标窗口是64位进程如Win11自带记事本那么32位exe将无法获取其句柄——这是位数不匹配导致的硬性隔离没有任何绕过方法。无外部依赖理论上一个正确打包的AHK exe除了Windows系统DLLkernel32.dll, user32.dll等不应依赖任何外部文件。这意味着你不需要在客户电脑上预装AHK也不需要把AutoHotkey.exe单独拷过去。提示验证一个exe是否真正“自包含”最简单的方法是把它复制到一台全新安装的Windows虚拟机不装任何第三方软件双击运行。如果能正常工作说明打包成功如果报错“找不到AutoHotkey.exe”或“应用程序无法正常启动”说明解释器未正确嵌入或位数不匹配。2.2 v1.1.x 与 v2.0.x两条不可逾越的河流当前AHK存在两个并行发展的主干版本它们不是简单的升级而是语法、设计理念、ABI层面的彻底割裂。选择哪个版本打包是你整个项目的技术地基。对比维度AutoHotkey v1.1.xAutoHotkey v2.0.x语法风格类BASICSend, {Enter}Loop, 5类现代语言Send({Enter})Loop 5变量声明隐式声明var : hello强制声明var : hello无%符号函数定义MyFunc(param) { ... }MyFunc(param) { ... }无function关键字数组/对象伪数组Array1 : a, Array2 : b原生对象obj : {key: value}错误处理ErrorLevel全局变量try/catch块打包工具内置Compiler.ahkGUI界面内置Ahk2Exe.exe命令行为主默认架构32位AutoHotkey.exe64位AutoHotkey64.exe但提供32位版关键决策点新项目无脑选v2v2是官方未来唯一维护方向语法更严谨调试能力更强社区新教程、新库如Gui框架均优先支持v2。我2023年之后的所有新脚本全部强制使用v2。老项目迁移需谨慎v1脚本迁移到v2不是简单替换语法。#IfWinActive的条件判断逻辑、Hotstring的触发机制、ComObjCreate的COM对象交互方式均有细微差别。我建议用v2的#Requires指令强制指定版本避免混淆。打包工具链差异v1的编译器是图形化程序傻瓜式操作v2的Ahk2Exe.exe更偏向开发者支持命令行参数、资源注入、数字签名。这意味着v2打包更可控但也更需要你理解参数含义。实操心得我在给一家制造业客户做产线自动化脚本时曾因版本混乱栽过大跟头。他们原有v1脚本控制PLC通信我新写的v2脚本负责报表生成。两个exe同时运行时v1脚本突然无法捕获键盘热键。排查三天才发现v2的Ahk2Exe在打包时默认启用了#NoEnv禁用环境变量而v1脚本依赖%A_ScriptDir%读取配置文件该变量在v2环境下被意外污染。最终解决方案是v1脚本显式声明#NoEnv Offv2脚本用绝对路径读取配置。这个教训告诉我跨版本共存时环境变量就是最危险的共享内存。2.3 内置编译器 vs 第三方工具何时该放弃“右键编译”AHK官方提供了开箱即用的编译功能但它的定位是“够用”而非“专业交付”。当你的需求超出基础打包就必须引入第三方工具。内置编译器v1的Compiler.ahk / v2的Ahk2Exe.exe优势零学习成本右键菜单直达图标、版本信息、UAC设置都有GUI勾选。绝对安全来自官方源码无后门风险杀毒软件白名单友好。版本精准匹配确保解释器与脚本语法100%兼容。内置编译器的致命短板资源嵌入鸡肋只能嵌入图标、版本字符串、描述无法注入.png图片、.ini配置、.dll插件等二进制资源。UAC声明僵化v1编译器只提供“不请求”“请求标准用户”“请求管理员”三个选项无法精细控制uiAccesstrue绕过UIPI限制。无数字签名支持生成的exe在Win10/11上会被SmartScreen标记为“未知发布者”双击时弹出吓人的黄色警告框普通用户90%会直接点“更多信息”→“仍要运行”但企业IT部门会直接拦截。第三方工具选型逻辑Inno Setup当你的项目不只是一个exe而是一套完整安装包含帮助文档、注册表项、服务安装、卸载程序。我给银行做的柜面辅助工具就用Inno Setup打包主程序是AHK exe安装时自动创建桌面快捷方式、写入HKCU\Software注册表、静默安装.NET Framework 3.5某些AHK GUI控件依赖它。Resource Hacker当你要“偷天换日”——比如把一个合法软件的图标、版本信息、数字签名覆盖到你的AHK exe上仅限学习研究商用需授权。我曾用它把公司OA系统的图标和公司名称注入到内部考勤脚本中让员工觉得这是“官方工具”而非“个人小脚本”。signtool.exeWindows SDK当你的exe要部署到企业内网必须通过IT部门的软件白名单。数字签名是唯一通行证。signtool sign /f mycert.pfx /p password /t http://timestamp.digicert.com myscript.exe——这条命令能让你的脚本在客户电脑上安静运行而不是在SmartScreen的审判席上瑟瑟发抖。注意所有第三方工具操作都必须在与目标环境一致的Windows版本和位数下进行。我在Win11 64位上用Inno Setup打包的安装包在Win7 32位虚拟机里安装失败原因竟是Inno Setup 6.x默认启用ArchitecturesInstall x64而Win7 32位不识别该指令。最终降级到Inno Setup 5.6.1并显式声明ArchitecturesInstall x86才解决。3. 打包全流程实操从脚本编写到生成可信赖的exe3.1 脚本编写阶段的“打包友好”设计原则很多打包失败根源不在编译环节而在脚本写法本身。一个“打包友好”的AHK脚本从第一行代码就该考虑可移植性。原则一路径处理——永远不要相信%A_ScriptDir%%A_ScriptDir%在编译后指向exe所在目录这没错。但问题在于用户可能把exe放在C:\Program Files\MyTool\而该路径在Win10/11下受UAC保护脚本尝试FileAppend写日志时会因权限不足失败。正确做法使用A_AppData或A_LocalAppData。; ❌ 危险写入脚本同目录可能无权限 FileAppend, Log: %A_Now%n, %A_ScriptDir \log.txt ; ✅ 安全写入当前用户应用数据目录始终有写权限 logPath : A_AppData \MyTool\log.txt FileAppend, Log: %A_Now%n, %logPath%A_AppData指向C:\Users\User\AppData\Roaming\A_LocalAppData指向C:\Users\User\AppData\Local\。前者适合同步到OneDrive的配置后者适合大体积缓存文件。原则二资源引用——把一切外部依赖打包进exe如果你的脚本需要读取config.ini或显示logo.png不要指望用户会把它们和exe放在一起。AHK v2.0原生支持A_Resources配合Ahk2Exe的资源注入功能可将任意文件作为资源嵌入。实操步骤在脚本开头添加资源声明; 声明一个名为 CONFIG 的资源类型为 TEXT ; 这行代码本身不执行仅作编译器标记 ; Ahk2Exe-Resource CONFIG TEXT config.ini ; Ahk2Exe-Resource LOGO IMAGE logo.png在Ahk2Exe.exe命令行中指定资源文件路径Ahk2Exe.exe /in myscript.ahk /out myscript.exe /icon icon.ico /res config.ini;CONFIG;TEXT /res logo.png;LOGO;IMAGE在脚本中读取资源; 读取嵌入的INI配置 configContent : FileOpen(A_Resources \CONFIG, r).Read() ; 解析为对象需AHK v2.0 config : IniReadAll(configContent) ; 读取嵌入的PNG图片用于GUI gui : Gui() pic : gui.Add(Picture, w200 h100, A_Resources \LOGO)原则三UAC与权限——明确声明你的需求AHK脚本常需模拟按键、读取其他进程内存、修改系统设置。这些操作在标准用户权限下会被阻止。正确做法在脚本开头显式声明UAC需求并在编译时匹配。; v2.0 脚本声明需要管理员权限 #Requires Admin ; 或者声明需要UI访问权限用于绕过UIPI向高权限进程发送消息 #Requires uiAccesstrue然后在Ahk2Exe.exe编译时必须选择匹配的UAC清单。v2的Ahk2Exe支持/manifest参数指定自定义清单文件其中关键字段为requestedExecutionLevel levelrequireAdministrator uiAccessfalse / !-- 或 -- requestedExecutionLevel levelasInvoker uiAccesstrue /提示uiAccesstrue要求exe必须安装在C:\Windows\System32\或C:\Program Files\下且数字签名证书需包含Extended Validation (EV)属性。普通OV证书不支持。这是微软最严格的权限模型慎用。3.2 使用Ahk2Exe.exe进行专业级打包v2.0v2.0的Ahk2Exe.exe是命令行工具位于AHK安装目录的Compiler\子文件夹。它比v1的GUI编译器强大得多是专业交付的基石。核心命令参数详解Ahk2Exe.exe ^ /in C:\project\main.ahk ^ ; 输入脚本路径必需 /out C:\dist\MyTool.exe ^ ; 输出exe路径必需 /icon C:\project\icon.ico ^ ; 图标文件可选支持.ICO格式 /bin C:\AHK\v2\AutoHotkey64.exe ^ ; 指定解释器可选默认用同目录下的AutoHotkey64.exe /res C:\project\config.ini;CONFIG;TEXT ^ ; 注入资源可选格式路径;资源名;类型 /res C:\project\help.chm;HELP;DOCUMENT ^ /manifest C:\project\manifest.xml ^ ; 自定义UAC清单可选 /version 1.0.0.0 ^ ; 版本号可选写入exe资源 /description My Awesome Tool ^ ; 描述可选 /company My Company ^ ; 公司名可选 /copyright © 2024 My Company ^ ; 版权可选 /product MyTool ^ ; 产品名可选 /language 1033 ^ ; 语言ID1033英语2052简体中文关键参数避坑指南/bin参数强烈建议显式指定。不要依赖默认值。我曾因AHK安装目录下同时存在AutoHotkey64.exe和AutoHotkeyA32.exeAhk2Exe随机选择了32位解释器导致打包后的exe在64位系统上无法调用DllCall(kernel32.dll, Ptr, GetCurrentProcess)。显式写/bin AutoHotkey64.exe一劳永逸。/res参数资源名CONFIG必须与脚本中A_Resources \CONFIG的名称完全一致大小写敏感。Windows资源管理器对大小写不敏感但AHK的A_Resources是区分大小写的。/manifest参数清单文件必须是UTF-8编码无BOM否则Ahk2Exe会静默忽略。用VS Code保存时务必选择“UTF-8”而非“UTF-8 with BOM”。自动化打包脚本.bat 为避免每次手动敲命令我创建了build.batecho off setlocal enabledelayedexpansion :: 定义变量 set AHK_PATHC:\Program Files\AutoHotkey\v2\Compiler\Ahk2Exe.exe set SCRIPT_PATH.\src\main.ahk set OUT_PATH.\dist\MyTool.exe set ICON_PATH.\assets\icon.ico set VERSION1.2.3.0 :: 构建资源参数 set RES_ARGS for %%f in (.\assets\*.ini .\assets\*.png) do ( if exist %%f ( for /f delims %%n in (basename %%f) do ( set fname%%~nf set ext%%~xf if !ext!.ini set typeTEXT if !ext!.png set typeIMAGE set RES_ARGS!RES_ARGS! /res %%f;!fname!;!type! ) ) ) :: 执行编译 %AHK_PATH% ^ /in %SCRIPT_PATH% ^ /out %OUT_PATH% ^ /icon %ICON_PATH% ^ /version %VERSION% ^ /description MyTool - Automation Helper ^ /company My Company ^ /copyright © 2024 My Company ^ /language 2052 ^ %RES_ARGS% if %errorlevel% equ 0 ( echo [SUCCESS] Build completed: %OUT_PATH% :: 自动签名需提前配置signtool signtool sign /f mycert.pfx /p mypassword /t http://timestamp.digicert.com %OUT_PATH% echo [INFO] Signed with digital certificate. ) else ( echo [ERROR] Build failed! ) pause这个脚本实现了资源文件自动发现、版本号集中管理、编译后自动数字签名。每次改完代码双击build.bat5秒后.\dist\下就是一个可直接分发的、带签名的、专业级exe。3.3 图标、版本信息与数字签名让exe看起来“可信”一个未经修饰的AHK exe在Windows资源管理器里显示为一个丑陋的齿轮图标右键属性里“详细信息”标签页一片空白。这会给用户潜意识传递“这是个来历不明的黑客工具”的信号。专业交付必须攻克这最后1公里。图标Icon注入尺寸要求ICO文件必须包含多个尺寸至少包括16x16、32x32、48x48、256x256像素。Windows资源管理器在不同视图下会调用不同尺寸。我用 https://icoconvert.com 在线转换上传一张256x256的PNG它会自动生成多尺寸ICO。颜色深度必须是32位色含Alpha通道否则透明背景会变成灰色方块。用GIMP导出ICO时务必勾选“保存Alpha通道”。编译时注入/icon参数指定ICO文件路径。注意ICO文件本身不会被嵌入exe只是其图像数据被提取并写入exe的资源段。版本信息Version Info注入 这是让exe在右键→“属性”→“详细信息”里显示公司名、产品名、版权的关键。Ahk2Exe.exe的/version,/description,/company等参数就是为此而生。数字签名Code Signing实操 没有数字签名的exe在Win10/11上首次运行时SmartScreen会弹出“Windows已保护你的电脑Windows Defender Smartscreen 阻止了未识别的应用启动。此应用无法确认是否安全。”获取证书个人开发者DigiCert、Sectigo提供入门级OV证书约$70/年。申请时需提供营业执照个体户也可或身份证正反面。企业用户购买EV证书Extended Validation价格$300/年但能获得“立即运行”特权无需用户点击“更多信息”。签名命令:: 使用signtool需安装Windows SDK signtool sign ^ /f C:\certs\mycert.pfx ^ ; PFX证书文件路径 /p mypassword ^ ; PFX密码 /t http://timestamp.digicert.com ^ ; 时间戳服务器关键否则证书过期后exe失效 /fd SHA256 ^ ; 指定哈希算法 C:\dist\MyTool.exe注意/t时间戳参数是灵魂。它证明“此exe在证书有效期内已签名”即使证书过期已签名的exe依然有效。没有它证书一过期所有已分发的exe都会被系统拒绝执行。验证签名 签名后用以下命令验证signtool verify /pa C:\dist\MyTool.exe输出Successfully verified即为成功。右键exe→属性→“数字签名”标签页应能看到你的证书信息和时间戳。4. 常见问题与排查技巧实录那些让你抓狂的“打包后异常”4.1 “双击没反应”——最常见却最易忽视的启动失败现象双击exe鼠标转圈1秒然后无声无息任务管理器里看不到任何AutoHotkey.exe进程。排查链条检查位数匹配用 Dependency Walker 旧版或 Dependencies 新版打开exe看它依赖的AutoHotkey64.exe还是AutoHotkeyA32.exe。再看目标电脑是32位还是64位系统。不匹配则必然失败。检查解释器完整性将exe后缀改为.zip用7-Zip打开。你应该能看到一个AutoHotkey.exe或AutoHotkey64.exe文件。如果看不到说明Ahk2Exe打包失败可能是/bin路径错误或解释器文件损坏。检查UAC拦截以管理员身份运行cmd然后拖拽exe到cmd窗口回车。如果看到Error: Failed to initialize AutoHotkey大概率是UAC阻止了CreateProcess调用。此时需检查脚本是否有#Requires Admin且编译时UAC清单是否匹配。终极诊断Process Monitor下载 Sysinternals Process Monitor 设置过滤器Process Name is MyTool.exe然后双击运行。观察Result列如果大量出现NAME NOT FOUND或PATH NOT FOUND说明脚本在找某个不存在的文件如%A_ScriptDir%\config.ini如果出现ACCESS DENIED说明权限问题。实操心得我帮一家律所打包合同审查脚本时遇到“双击没反应”。用Process Monitor发现脚本在启动时试图读取C:\Program Files\LawFirm\config.json但该路径在Win10下被UAC重定向到VirtualStore而脚本没处理重定向逻辑。解决方案是脚本改用A_AppData \LawFirm\config.json并确保build.bat在编译前先创建该目录。4.2 “乱码”与“中文显示异常”——字符编码的隐形杀手现象exe里显示的中文是方块、问号或MsgBox弹窗标题是乱码。根源分析 AHK v1默认使用系统ANSI代码页如Win10简体中文是GBK而v2默认使用UTF-8。但Windows的GUI API如CreateWindow在接收字符串时期望的是UTF-16宽字符。如果脚本文件本身是UTF-8编码而AHK解释器以ANSI方式读取就会产生乱码。解决方案脚本文件编码用VS Code打开脚本右下角点击编码如“UTF-8”选择“Save with Encoding” → “UTF-8 with BOM”。BOMByte Order Mark是EF BB BF三个字节它像一个路标告诉AHK解释器“请用UTF-8读我”。显式声明编码在脚本第一行添加; v2.0 推荐 #NoEnv SetBatchLines, -1 ; 告诉解释器此脚本是UTF-8编码 ; autohotkey_encoding UTF-8GUI控件字体AHK的Gui, Add, Text默认使用系统默认字体该字体可能不支持中文。显式指定gui : Gui() gui.Font(s12 c000000, Microsoft YaHei) ; 设置微软雅黑字体 text : gui.Add(Text, w300, 你好世界)4.3 杀毒软件误报——如何让你的exe“清白”现象打包好的exe被360、腾讯电脑管家、Windows Defender报毒提示“木马行为”“可疑程序”。为什么会被报杀毒软件的启发式引擎会扫描exe的行为模式。AHK exe的典型特征创建AutoHotkey.exe进程像远控木马调用WriteProcessMemory像内存注入注册全局热键像键盘记录器读取剪贴板像信息窃取降低误报率的实战技巧数字签名是王道已签名的exe误报率直降90%。杀毒软件对知名CA签发的证书有白名单。避免敏感API不用DllCall(kernel32.dll, Ptr, WriteProcessMemory)改用AHK内置的Process命令不用DllCall(user32.dll, UInt, GetAsyncKeyState)监听按键改用Hotkey指令。增加“良性”行为在脚本启动时主动调用一次FileRead读取一个无害的文本文件如README.txt或RegRead读取一个公开的注册表项如HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion。这会让杀软认为“它只是个普通工具”。提交误报样本到 https://www.virustotal.com 上传exe查看哪些引擎报毒。然后分别向报毒的厂商如360、腾讯提交“误报申诉”提供脚本源码和打包过程说明。通常3-5个工作日解除。注意不要用“加壳”“混淆”等手段对抗杀软。这反而会坐实“恶意软件”的嫌疑且AHK脚本加壳后性能下降、调试困难得不偿失。4.4 “资源文件读取失败”——A_Resources的陷阱现象脚本中FileOpen(A_Resources \CONFIG, r)返回空对象A_Resources变量为空字符串。原因与修复资源名不匹配/res参数中的资源名CONFIG与脚本中A_Resources \CONFIG的名称必须完全一致包括大小写。Windows文件系统不区分大小写但AHK资源API区分。资源类型错误TEXT类型资源FileOpen必须用r文本模式IMAGE类型必须用rb二进制模式。用错模式会导致读取失败。AHK版本不支持A_Resources是v2.0特性。v1脚本无法使用。v1的资源注入需借助第三方工具如Resource Hacker。调试技巧 在脚本中加入诊断代码; 检查A_Resources是否可用 if !IsObject(A_Resources) { MsgBox A_Resources is not available. Are you using AHK v2.0? ExitApp } MsgBox A_Resources path: A_Resources ; 列出所有可用资源 for name, type in A_Resources { MsgBox Resource: name , Type: type }4.5 “打包后脚本功能异常”——编译器的隐式行为现象脚本在编辑器里运行完美打包成exe后Loop循环次数变少Sleep时间不准Hotkey响应延迟。罪魁祸首#NoEnv指令AHK v2默认启用#NoEnv它禁用所有环境变量%A_ScriptDir%,%A_WorkingDir%等。而很多老脚本尤其是v1迁移过来的严重依赖这些变量。解决方案显式关闭在脚本开头添加#NoEnv Off。重构代码用A_ScriptFullPath替代%A_ScriptDir%用A_WorkingDir替代%A_WorkingDir%并确保这些变量在#NoEnv Off下可用。终极方案彻底抛弃环境变量用A_Resources或A_AppData管理所有路径。我的血泪教训一个库存盘点脚本用Loop, % FileCount遍历文件夹FileCount变量在v1下是全局的但在v2打包后因#NoEnv影响作用域FileCount变成了空。花了两天才定位到#NoEnv这个幽灵开关。现在我的所有新脚本第一行必写#NoEnv Off第二行写#Requires v2.0第三行才是业务代码。5. 进阶场景Inno Setup打包安装包与企业级部署策略5.1 为什么单个exe不够——安装包的必要性当你的AHK工具需要创建桌面/开始菜单快捷方式写入注册表如开机启动、文件关联静默安装.NET Framework或VC运行库提供卸载程序清理所有残留文件显示专业的安装向导欢迎页、许可协议、安装路径选择这时“右键编译”就力不从心了。你需要一个真正的安装包制作工具。Inno Setup是Windows平台最成熟、最轻量、最免费的选择。Inno Setup核心优势脚本驱动所有安装逻辑用Pascal Script编写与AHK一样是文本脚本版本控制友好。零依赖生成的setup.exe是单文件无需预装.NET或Java。企业就绪支持静默安装setup.exe /VERYSILENT、管理员权限提升、数字签名、多语言。5.2 Inno Setup安装脚本实操以MyTool为例创建MyTool.iss文件; Script generated by the Inno Setup Script Wizard. ; SEE THE DOCUMENTATION FOR DETAILS ON CREATING INNO SETUP SCRIPT FILES! #define MyAppName MyTool #define MyAppVersion 1.2.3 #define MyAppPublisher My Company #define MyAppURL https://mycompany.com #define MyAppExeName MyTool.exe [Setup] ; General AppName{#MyAppName} AppVersion{#MyAppVersion} AppPublisher{#MyAppPublisher} AppPublisherURL{#MyAppURL} AppSupportURL{#MyAppURL} AppUpdatesURL{#MyAppURL} DefaultDirName{autopf}\{#MyAppName} DisableProgramGroupPageyes LicenseFilelicense.txt OutputBaseFilenameMyTool_Setup Compressionlzma Solid