不知有多少读者朋友有着早年网上银行和 12306 的使用经历？那个时候想要在电脑端登录网银，或上12306 买票，必须提前下载专属安全控件，并且仅支持 IE 浏览器，随之而来操作系统也只能选用 Windows。

不知有多少读者朋友有着早年网上银行和 12306 的使用经历？那个时候想要在电脑端登录网银，或上12306 买票，必须提前下载专属安全控件，并且仅支持 IE 浏览器，随之而来操作系统也只能选用 Windows。

后来 Chrome 浏览器日渐普及，成为许多人的首选。可每当需要办理网银业务时，大家又不得不切回 IE 浏览器。

时代浪潮滚滚向前，浏览器市场格局几经更迭，曾经是绝对霸主的微软 IE 浏览器最终败给了谷歌 Chrome 浏览器。IE 浏览器就此退出主流舞台，被尘封于历史。而微软推出 Edge 浏览器重回赛道，但这次放弃了自家的 Trident 内核，转而采用竞争对手谷歌的 Chromium/Blink 内核。

2022 年 6 月 15 日，微软正式终止 IE11 桌面端应用的技术支持，Windows 10 及后续版本禁用 IE 浏览器。至此，IE 走完了长达二十余年的生命周期，我们终于迎来了浏览器的选择自由。

可 IE 虽已退出历史舞台，它遗留下的历史包袱却并未就此消散。为保障一大批专为 IE 开发的业务网站能够正常访问，Edge 浏览器至今保留着 IE 兼容模式。Windows 系统也依旧内置基于 Trident 内核的 MSHTML 组件。不少内嵌 IE 浏览器内核的第三方应用，也能得以继续运行。

但在国产化替代的进程当中，IE 却成了一根难以拔除的刺。国内大量政务平台、老旧 OA 系统与行业审批业务平台，至今深度绑定这套诞生于二十多年前的老旧技术架构，迫使我们投入高昂的成本开展兼容适配工作。

想要读懂这颗 “陈年旧刺” 的来龙去脉，一切还要从上世纪 90 年代 B/S 架构全面兴起说起。

01 从 C/S 到 B/S

在互联网普及之前，企业和政务的信息化系统，主流采用的是 C/S 架构（客户端/服务器）。这类系统需要每一台电脑单独安装专属客户端，部署繁琐、升级困难、维护成本高。一旦系统迭代更新，全网数百上千台终端都需要逐一更新，对于政企单位来说，运维压力巨大。

90年代中后期，Internet 技术飞速成熟， B/S 架构（浏览器/服务器）彻底颠覆了传统信息化模式。所有系统部署、迭代、维护全部集中在服务器端，客户端无需安装任何专属软件，仅通过浏览器即可访问所有业务系统，零部署、易维护、跨终端的优势，让 B/S 架构迅速成为政企信息化的绝对主流。

我刚毕业的那会，非常流行使用 ASP（Active Server Pages） 做企业信息系统，而这套技术生态从根源上就深度依附于微软体系。

不过浏览器网页在设计之初，就被定义为运行于不可信环境，权限受到严格约束：既不能随意读取本地文件，也难以调用本机硬件设备。受此限制，复杂表单校验、电子签章、权限管控、外设读取等政企核心业务需求，很难单纯依靠网页实现。

B/S架构解决了部署难题，却缺失了企业级应用的交互能力和系统权限能力。为此，微软推出了自己的解决方案：ActiveX和 VBScript。

02 微软的时代布局：ActiveX与VBScript的诞生逻辑

90年代的互联网战场，是微软与网景的浏览器争霸赛。网景依托 Java Applet 抢占网页交互市场，而微软手握绝对垄断的 Windows 系统生态，需要一套属于自己的技术体系，打通 “Windows系统+浏览器+企业Web应用” 的闭环，彻底拿下政企 B/S 应用市场。

基于自身成熟的 COM 组件技术，微软在1996年正式推出 ActiveX 控件，同时配套轻量化脚本语言VBScript，专门弥补早期网页的能力短板。

对于当时的行业而言，这两套技术堪称“降维神器”：

第一，极致的系统权限能力。 ActiveX 可以直接调用 Windows 本地组件、读取本地文件、调用打印机、读卡器、电子签章、UKey、扫描仪等政企办公必备硬件，完美适配政务审批、公文流转、电子签章、身份核验等复杂业务场景，这是早期纯网页技术无法实现的。

第二，极低的开发门槛。VBScript基于 Visual Basic 简化而来，语法简单、上手极易，配合 ActiveX 控件可以快速实现网页动态交互、业务逻辑编写。那个时候，国内有着众多的 VB 程序员，无需重新学习全新技术，就能快速搭建完整的 Web 办公系统。

第三，独家生态垄断优势。在 Windows 一统政企办公终端的时代，IE浏览器是系统默认自带浏览器，无需额外安装，天然适配 ActiveX 和 VBScript。微软凭借这套组合拳，彻底垄断了国内政企 B/S 办公系统的技术底层。

站在当时的视角，微软的布局无比成功。用成熟的桌面技术赋能网页，让简陋的静态网页变成了可落地、可商用、可适配政企复杂场景的企业级应用，也为后续国产 OA 系统的普及埋下了技术伏笔。

03 国产 OA 的历史枷锁：为什么全员绑定 IE 内核？

很多人疑惑：如今前端技术百花齐放，为何早年国产OA、政务系统、审批平台，几乎清一色依赖 IE 内核、ActiveX和VBScript？

答案很简单：不是开发者不想用新技术，而是当年只有这套技术能落地政企核心业务。

国内政企信息化建设的黄金期，恰好卡在 2000 年 — 2015年，这正是 IE 浏览器、ActiveX 技术的鼎盛时代。彼时的国产软件厂商，普遍存在技术积累薄弱、研发成本有限的问题，而 ActiveX + VBScript + IE内核的技术组合，是最快、最低成本实现政企复杂办公需求的唯一方案。

电子公文需要网页调用本地签章控件、政务审批需要读取 UKey 身份证书、档案系统需要批量读写本地文件、财务系统需要调用专用打印控件...所有这些核心场景，在当年，只能依靠IE加载 ActiveX 控件、通过VBScript/JScript 脚本调度实现。

久而久之，国内数千家政企单位的OA、政务平台、业务系统，全部深度耦合 IE 内核生态。系统底层逻辑、业务代码、硬件适配、权限体系，全部基于 ActiveX 和 VBScript 构建，形成了牵一发而动全身的技术绑定。

更关键的是，政企系统迭代极其保守，稳定性、安全性、兼容性优先级远高于技术先进性。一套系统上线后，往往十年甚至更久不做大版本迭代，只是小修小补。这就导致大量基于 IE 内核的老旧系统，被完整保留下来，成为了如今国产化改造的历史遗留包袱。

04 微软彻底弃坑：IE与ActiveX消亡的底层原因

就在国内政企深度绑定 IE 生态的同时，微软早已悄然放弃了这套自研技术体系。2016年，微软宣布停止 IE 功能更新；2022年6月，IE 浏览器正式全面退役；ActiveX、VBScript 彻底被标记为废弃技术，不再提供任何官方维护和安全补丁。

微软果断淘汰这套曾经的核心技术，核心原因有三点，每一点都直击其致命缺陷：

首先是无法弥补的安全漏洞。ActiveX 基于COM组件设计，拥有极高的系统权限，一旦加载恶意控件，可直接篡改系统文件、窃取本地数据、植入病毒，权限几乎不受限制。在互联网早期安全意识薄弱的时代尚可容忍，但在网络攻击频发的时代，这种“无沙箱、无隔离、高权限”的设计，成为了巨大的安全黑洞，完全不符合现代浏览器的安全规范。

其次是技术生态的全面落后。随着 HTML5、CSS3、JavaScript 生态爆发，现代网页已经可以独立实现复杂交互、硬件调用、图形渲染、文件处理等所有业务能力，彻底摆脱了对本地控件的依赖。跨平台、标准化、轻量化的现代 Web 技术，完胜封闭、笨重、仅限 Windows 的 ActiveX 和 VBScript 。同时VBScript仅适配Windows+IE，无法跨浏览器、跨系统，完全不符合互联网开放兼容的发展趋势。

最后是微软的战略转型。微软彻底拥抱开源标准化 Web 生态，放弃封闭私有技术体系，全力主推 Edge 浏览器、适配 HTML5 标准，剥离老旧历史包袱，聚焦跨平台、云原生、现代化的技术布局。ActiveX、VBScript、IE内核这套老旧技术，彻底失去了战略价值。

05 国产化最大的无奈：明知过时，仍必须兼容

最尴尬的局面就此形成：技术原厂早已淘汰废弃，国内政企的核心业务系统，却依然依赖这套技术生存。这也是它成为国产化进程中一根顽固硬刺的核心原因。

如今信创国产化替代的核心目标，是实现软硬件全国产化、摆脱国外技术依赖，操作系统、CPU、服务器、办公软件全部完成自主替代。但所有国产化改造，都会遇到同一个拦路虎：新的国产操作系统、国产浏览器，不支持 IE 内核、不兼容 ActiveX 控件、不识别 VBScript 脚本。

于是就出现了尴尬的行业现状：

为了完成国产化替代，我们不得不专门开发IE内核兼容插件、模拟IE运行环境、适配废弃 ActiveX 控件。大量的研发人力、适配成本、测试资源，消耗在兼容一套微软已经放弃的老旧技术上。

这种现状短期内无法改变，因为绝大多数老旧政企系统代码庞大、逻辑复杂、无人敢重构。一旦彻底剥离 IE 和 ActiveX，整套系统的签章、审批、硬件调用、权限校验功能会全面瘫痪，直接影响政务办公、企业业务正常运转。对于政企单位而言，稳定优先、业务不停摆是底线，因此只能选择持续兼容、被动兜底。

这根“旧刺”，本质是早期信息化技术垄断+政企系统迭代惰性+技术标准断层共同造就的时代遗留问题。

06 AI 时代，国产化迎来新机遇

为解决老旧业务系统迁移难题、在国产操作系统上兼容 IE 内核与 ActiveX 控件，行业内大量信创适配项目普遍选择基于 WINE 兼容层来开展改造工作。通过 WINE 模拟 Windows 运行环境，我们得以加载 MSHTML 浏览器组件，实现 VBScript、JScript 脚本的解析执行，以此支撑一大批历史遗留政务、OA、行业业务平台正常运行。

但兼容改造之路依旧充满挑战。WINE 对于 IE 相关接口的实现并不完整，大量 COM 接口、回调函数、控件事件、浏览器扩展能力仍处于缺失或者半完成状态。部分已实现的接口逻辑与原版 Windows 行为存在差异，极易出现页面脚本报错、控件加载失败、签章外设无法调用、业务流程中断等各类隐性兼容性问题。想要补齐这些缺失接口、修正行为差异，传统开发模式下需要工程师逐一对接口逆向分析、阅读微软官方文档、编写测试用例、反复调试比对，整个过程工作量巨大、周期漫长，人力成本居高不下，一直是拖累信创项目落地的一大痛点。

随着 AI 技术的快速发展，为这一困局带来了全新的破局思路。依托大模型强大的代码生成、接口逆向、文档解读、问题定位能力，开发者可以借助 AI 快速补全缺失的 Win32 与 COM 接口实现代码，自动生成接口测试用例，对比原版 IE 的运行行为修复逻辑偏差，大幅降低逆向开发、接口适配与脚本调试的人力投入。

AI 正在成为国产化兼容改造的强力加速器，有效缩短老旧 IE 业务系统的适配周期，削减项目改造成本，让我们得以从繁重、重复的底层接口适配工作中解放出来，将更多精力投入到国产原生生态的建设当中，为信创数字化转型打开新的发展机遇。

未来的国产化改造，必然要经历一个逐步去IE化、逐步淘汰ActiveX、逐步标准化重构的过程。短期的兼容适配是无奈的妥协，长期的系统重构、技术迭代、标准统一，才是彻底拔除这根硬刺、实现真正自主可控的唯一出路。

旧技术终会落幕，但国产化的迭代升级，永远不会止步。