仅Windows平台C++编写的ActiveX控件适配现代浏览器低改造成本方案咨询

优先选择「浏览器扩展 + Native Messaging + 现有ActiveX封装宿主」的组合方案，整体改造成本远低于你提到的Wasm移植、V8嵌入两种方案，且完全不受浏览器沙箱限制，可以保留100%原有功能。

方案核心逻辑 #

不需要修改你现有C++/MFC/ActiveX的核心业务代码，只需要做两层轻量封装：

• 把原ActiveX控件封装成一个独立的Windows后台小程序（可以做成无UI的控制台程序/后台进程，只保留对外调用接口，原有功能逻辑完全复用）
• 开发一个轻量的跨浏览器扩展（Chrome、Firefox、Edge都支持标准的扩展规范），页面侧通过JS调用扩展提供的API，扩展再通过浏览器原生的Native Messaging接口和你封装的本地后台程序通信，完成功能调用后原路返回结果给页面
• Native Messaging的配置仅需要在目标Windows设备的注册表中新增一个指定路径的注册项，告知浏览器本地宿主程序的位置即可，不需要额外安装复杂的系统服务

方案优势 #

• 改造成本极低：核心业务代码0修改，只需要新增不超过1000行的封装层代码，包括本地宿主的接口封装、扩展的消息转发逻辑
• 没有沙箱限制：本地宿主程序运行在Windows系统层，原有文件访问、系统API调用等所有权限完全保留
• 兼容性强：支持所有主流现代浏览器（Chrome、Firefox、Edge、所有基于Chromium的第三方浏览器全部兼容）
• 后续迭代成本低：如果后续原有功能更新，只需要更新本地宿主程序，不需要调整前端和扩展逻辑

对你提到的两个方案的补充说明 #

• WebAssembly方案确实不适合你的场景：沙箱对本地资源的访问限制是硬伤，即便用File System Access API也只能实现用户主动触发的文件访问，无法满足原有ActiveX的无感知本地资源调用需求，且需要把大量Win32/MFC依赖移植到Wasm，改造成本极高
• V8引擎回调的方案实际落地复杂度很高：相当于你要自己实现一套浏览器和本地V8环境的通信机制，且无法适配Firefox等非Chromium内核的浏览器，适用范围窄，改造成本也远高于上述推荐方案

可选兜底过渡方案 #

如果仅限企业内部场景使用、暂时不需要对外公开，可以直接基于微软的「Edge IE模式站点策略」批量配置，不需要做任何代码修改，即可让用户在Edge里正常使用原有功能，是0改造成本的临时过渡方案。

内容的提问来源于stack exchange，提问作者No Name