Angular项目替代IE嵌入式DLL直接运行本地EXE的方案及WebAssembly可行性

针对你在企业内网环境下的迁移需求，下面是具体的方案分析和最优选择：

一、最优实现方案 #

现代浏览器出于安全限制，默认不允许直接调用本地EXE，但在企业内网权限可控的前提下，有两种成熟方案可选：

1. 自定义URI协议 #

这是当前场景下成本最低、兼容性最好的方案。你可以在客户端机器的注册表中注册一个自定义协议（比如corp-app://），将其关联到目标本地EXE。

• 在Angular页面中，通过跳转或者window.open()触发该协议，系统会自动调用关联的EXE程序。
  示例代码（Angular组件）：

  triggerLocalExe(): void {
    // 可以携带参数，EXE启动时解析该URL
    window.open('corp-app://action=start&param=demo');
  }
  

• 注册表配置（可通过企业域推送脚本批量部署）：

  Windows Registry Editor Version 5.00
  [HKEY_CLASSES_ROOT\corp-app]
  @="URL:Corp App Protocol"
  "URL Protocol"=""
  [HKEY_CLASSES_ROOT\corp-app\shell\open\command]
  @="\"C:\\YourAppPath\\target.exe\" \"%1\""
  

• 优势：无需额外开发依赖，所有现代浏览器都支持，部署简单，完全适配企业内网的权限环境。

2. 企业级浏览器扩展 #

如果需要和本地EXE进行复杂交互（比如传递大量数据、获取执行结果），可以开发专属的浏览器扩展，利用扩展的nativeMessaging API实现与本地程序的通信。

• 扩展需要通过企业域策略强制安装到员工浏览器中，同时配置nativeMessaging清单文件关联本地EXE。
• Angular页面通过与扩展通信，由扩展触发EXE执行并接收返回数据。
• 优势：交互能力更强，安全性更高（仅企业内部扩展可触发），适合复杂业务场景。

二、WebAssembly是否可行？ #

WebAssembly完全不适合这个需求：

• Wasm运行在浏览器的沙箱里，没有访问本地系统进程的权限，根本无法调用本地已有的EXE程序。
• 就算把EXE代码编译成Wasm，也只是在浏览器沙箱内运行，不是调用本地的原生EXE，和你的需求完全不符。

三、方案选择建议 #

• 只是简单触发EXE启动：优先选自定义URI协议，开发和部署成本极低。
• 需要和EXE做复杂数据交互：选浏览器扩展，能满足更灵活的业务需求。

内容的提问来源于stack exchange，提问作者Itay.B