你还记得自己最后一次打开 IE 浏览器是什么时候吗？很多开发者在日常工作中其实都经历过一种“分裂状态”：一边用着基于 Chromium 内核的新版 Edge 调试现代化前端代码，一边又要为了客户内网那套只支持 ActiveX 控件的老 OA 系统，到处寻找打开 IE 的方法。IE 明明已经退出历史舞台，又像影子一样留在企业软件里，最后微软用 Edge 里的“IE 模式”给这段历史留了一个出口。
这篇文章会把微软浏览器这几十年走过的路完整梳理一遍：从 1995 年诞生的 IE1，到 2015 年第一次登场的 Edge Legacy，再到 2020 年重获新生的 Chromium 版 Edge。更重要的是，我会把开发者和 IT 运维人员最常遇到的 IE 兼容类问题一并整理出来，包括老控件不能装载、Edge 里如何开启 IE 模式、IE 模式默认 30 天过期怎么通过组策略调整，以及 Zotero 文献抓取失败这类高频故障。无论你是刚接触前端的新手，还是在维护老系统的资深工程师，都能从里面找到可以直接用的排错思路。
1. 为什么这段浏览器进化史值得技术人重看一遍
1.1 技术人的日常分裂：IE 与 Edge 并存
先讲一个非常典型的场景。某个政府单位或企业内部的档案管理系统，登录时要求“请使用 IE 浏览器”，上面的文件上传窗口依赖一个叫 NTKO 的大文件上传控件，没有这个控件就无法传数据。可是现在电脑出厂预装的基本都是 Edge，IE11 桌面应用也已经停止了支持。
于是我们看到一个奇怪的现象：IE 已经退休，但老系统没有退休。为了让业务能继续跑，很多组织不得不转向 Edge 的 IE 模式，用新浏览器去承载旧的网页渲染引擎。这就意味着每个维护老系统的人，都必须理解 IE、Edge、IE 模式这三者之间的微妙关系。
另一个分裂体现在前端开发上。新项目要求“不要兼容 IE”，但随着浏览器版本更迭，你在 Edge 里调试时依然会碰到各种怪异行为：弹不出登录窗口、ActiveX 控件加载失败、本地开发启动后窗口异常置顶、甚至 Linux 下打开 Edge 还会弹密钥环认证框。这些问题如果不理解浏览器内核和系统组件的关系，排查起来会非常痛苦。
1.2 这篇长文能帮你理清什么
本文不是一篇单纯讲产品史的文章，而是一条“演进脉络 + 工程排错”的双线笔记。我会用大量篇幅介绍 IE 是如何从“赠送组件”变成垄断级产品，又为什么会衰落，以及 Edge 为什么经历了两次换内核对决。只有理解了这些问题，才能解释为什么今天还有网站要“兼容 IE”，为什么 Edge 要内置 IE 模式，为什么企业网管要辛辛苦苦维护一份 IE 模式站点列表。
读完这篇文章之后，你会掌握三个层面的知识：
- 历史层：IE1 到 IE11、Edge Legacy、Chromium 版 Edge 的技术路线差异。
- 原理层：Trident 引擎、ActiveX 控件、条件注释、IE 模式的本质。
- 实战层：老网站兼容不了时怎么开 IE 模式、30 天限制怎么处理、常见浏览器故障如何排查。
2. IE 的出生与黄金时代：从“Windows 95 附赠品”到全球垄断
2.1 1995 年：IE1 还只是操作系统里的一个小组件
上世纪 90 年代初期，Netscape Navigator 几乎是“互联网浏览器”的代名词。微软意识到互联网浪潮不可阻挡，决定快速入场。1995 年 8 月，微软发布了 Internet Explorer 1.0，它并不是独立零售产品，而是随 Windows 95 Plus! Pack 一起分发的小组件。
值得注意的是，IE1 并不是完全“从零”写出来的，它基于 Spyglass 公司的 Mosaic 浏览器源代码授权开发。最初的 IE1 功能非常有限，别说网页标准，连很多今天看来最基本的 HTML 能力都不完整。真正让微软看到希望的是浏览器预装策略：Windows 系统量大、覆盖广，只要 IE 能随系统出现在用户桌面上，市场份额就能快速提升。
2.2 第一次浏览器大战：免费 + 系统捆绑的降维打击
1996 年到 1998 年是最激烈的第一次浏览器大战。微软看到 Netscape 的崛起后，迅速调整策略，把 IE 免费集成到 Windows 操作系统中。对用户来说，不需要额外购买和下载，“打开电脑就能上网”；对企业来说，IT 运维成本也更低。这套组合拳让 IE 的份额在短短几年内节节攀升。
这一阶段的 IE3 和 IE4 在功能上也有明显追赶。IE3 开始支持 CSS 1、VBScript 和 ActiveX；IE4 则与 Windows 98 深度集成，把浏览器组件嵌入到文件资源管理器里。虽然这种深度捆绑让微软面临持续的反垄断压力，但从商业角度看，它成功让 IE 在市场上站稳了脚跟，也让 Web 开发从“页面展示”快速走向“应用化”。
2.3 技术关键词：CSS、ActiveX 与 DOM 的早期普及
在 IE3 时代，Web 开发还处于非常原始的阶段，很多页面依靠表格布局和 JavaScript 弹窗。IE4 开始支持比较完整的文档对象模型（DOM），让开发者可以动态修改网页内容。与此同时，ActiveX 的出现让浏览器拥有了调用本地系统能力的手段，这为后来企业级 Web 系统的繁荣埋下伏笔。
到了 IE5 和 IE5.5，微软已经在功能上追赶甚至超过了当时的 Netscape。但也是在这个阶段，IE 对 CSS 的解析开始出现自己的“理解偏差”，最典型的就是盒模型宽高包含 padding 和 border 的处理方式与 W3C 标准不一致。这个偏差后来成了前端开发者噩梦的开端，也是“CSS Hack”文化的源头之一。
2.4 IE6 的巅峰与停滞：占了市场先机，输掉了未来
2001 年，IE6 随 Windows XP 发布。当时的统计机构普遍认为，IE6 的市场份额一度超过 90%，几乎成了“浏览器”这个词的同义词。庞大的用户基数让很多网站不再考虑“跨浏览器兼容”，而是直接以 IE6 为唯一目标。
但问题也随之而来。IE 的市场垄断让微软觉得没有必要快速迭代，IE6 在很长一段时间里没有大的内核升级。与此同时，IE 与 Windows 深度集成带来的 ActiveX 攻击面越来越大，网页木马、恶意插件、弹窗广告层出不穷。2004 年 Firefox 1.0 发布后，很多对 IE6 安全和性能不满的用户开始出走，IE 的统治地位第一次出现松动。
2.5 IE7 到 IE11：一路追赶，却再也没能回到巅峰
IE7 在 2006 年才姗姗来迟，带来标签页浏览和初步的 CSS 改进。IE8 在 2009 年发布，对 CSS 2.1 的支持有了明显提升，也引入了兼容性视图，试图帮助用户打开那些“只针对旧版本 IE 开发”的网站。2011 年的 IE9 是一个转折点，它不再支持 Windows XP，并且加入了硬件加速和较好的 HTML5 支持，被不少开发者认为是 IE 家族中“最像现代浏览器”的一员。
2013 年发布的 IE11 是 IE 的最后一代。它的 JS 引擎性能已经基本够用，也支持 WebGL 等新特性，但前十年流失的开发者信任很难挽回。更关键的是，移动互联网时代到来，浏览器战场从桌面转向手机，微软在移动端的迟缓让 IE 彻底失去了翻盘机会。最终 IE11 成为绝唱，微软在 2022 年 6 月停止了对 Windows 10 上 IE11 桌面应用的支持。
3. IE 留给开发者的技术遗产：ActiveX、条件注释与 CSS Hack
3.1 Trident 引擎：IE 兼容问题的核心
IE 从版本 4 开始使用 Trident 排版引擎，也被称为 MSHTML。Trident 是 IE 渲染网页、执行脚本、处理 DOM 的底层组件。它和 Chrome 的 Blink、Firefox 的 Gecko 一样，负责把 HTML/CSS 变成用户看到的画面。
Trident 最让开发者头疼的地方在于历史包袱太重。IE6 时代的页面布局方式、脚本写法、CSS 解析行为都被后续版本尽量保留，目的是让老网站继续可用。微软选择“向后兼容”而不是“拥抱标准”，导致 Trident 在很长一段时间内成为前端兼容性问题的代名词。即便后来 Edge 换掉了 Trident，微软也没有彻底放弃它，而是把它保留在 Edge 的 IE 模式中，专门用来渲染那些依赖老内核的企业内部系统。
3.2 ActiveX：为什么很多老系统必须用 IE
ActiveX 是微软提出的一种组件复用技术，可以理解为网页中的“本地应用程序接口”。网站通过 JavaScript 或 VBScript 创建 ActiveXObject，就能在浏览器中调用本地的 Office、上传控件、摄像头、USB Key 等资源。NTKO 上传控件就是这类组件的典型代表，经常被用在电子政务、档案管理、OA 审批等场景中。
ActiveX 在 IE 深度整合的年代确实解决了大量问题，但它有两个致命弱点：第一，安全风险高，一个恶意 ActiveX 控件能直接读写本地文件；第二，其他浏览器都不支持。Chrome、Firefox、Safari 为了保证跨平台和安全性，并没有实现 ActiveX。这就导致很多依赖 ActiveX 的业务系统，只能在 IE/Trident 内核下运行。即使在今天，只要你还维护着这类老系统，IE 模式就是你绕不开的选项。
下面是一段早期内部系统里常见的判断逻辑，用来在 IE 下创建 ActiveX 上传控件，非 IE 浏览器则提示使用 IE 模式：
// 老系统内部页面逻辑示例，非现代推荐写法 if ("ActiveXObject" in window) { try { var uploader = new ActiveXObject("NTKO.Uploader"); // 控件装载成功，继续执行上传流程 console.log("控件初始化完成"); } catch (e) { alert("ActiveX 控件未安装或已被禁用，请调整安全设置后重试。"); } } else { alert("当前浏览器不支持 ActiveX，请在 Edge 中开启 IE 模式后访问本系统。"); }这段代码在今天看来并不优雅，但它非常真实地代表了 2005 到 2015 年间企业内部系统的常见写法。如果你在维护这类系统，请记住：直接让用户“换 Chrome”是没用的，真正要做的是引导用户进入 IE 模式或者将系统迁移到现代方案。
3.3 条件注释与 X-UA-Compatible：老前端的心酸记忆
在 IE9 之前的时代，条件注释是最实用的 IE 版本判断方法。它允许你在 HTML 中写一段只有指定 IE 版本才会解析的内容：
<!--[if IE]> <p>当前浏览器是 IE，请使用现代浏览器访问以获得更好体验。</p> <![endif]--> <!--[if lt IE 9]> <script src="html5shiv.min.js"></script> <![endif]-->第一段代码在任意 IE 版本下都会显示提示，第二段代码会在 IE9 以下版本加载 html5shiv，让老旧的 IE 认识 HTML5 新标签。后来微软还提供了 X-UA-Compatible 这个 HTTP 头或 meta 标签，让 IE 优先使用指定的文档模式渲染：
<meta http-equiv="X-UA-Compatible" content="IE=edge">“IE=edge”的意思是让 IE 使用当前版本支持的最高文档模式，避免它自动降级到兼容视图。Edge 出现前，很多网站开发时都会加上这一行，防止 IE 在“兼容性视图”里把现代页面渲染得面目全非。今天的 Edge IE 模式里，很多老系统也依然依赖类似机制来判断页面所用的文档模式。
3.4 为什么“兼容 IE”被写成了软件需求
很多新入行的前端不理解，为什么有些招标文档会白纸黑字写着“兼容 IE”。原因其实很简单：采购方单位的员工电脑上装着一套或几套 ActiveX 控件，这些控件和财务系统、签章系统、影像系统绑定。如果要全面替换，意味着整个后端接口和客户端控件全部重写，成本极高。
所以在很长时间里，“兼容 IE”不是技术选择，而是业务选择。理解这一点，你就能明白为什么微软已经停止支持 IE，企业级市场里依然有那么多人讨论 IE 模式、兼容性问题、NTKO 控件。它不是“要不要”的问题，而是“什么时候能替换完”的问题。
4. IE 为什么会退出历史舞台：安全、标准与时代的错位
4.1 安全与标准双双落后
IE6 时代，ActiveX 和浏览器漏洞让恶意网页可以轻易在用户电脑上执行代码。很多用户遭遇过浏览器主页被锁定、疯狂弹窗、自动安装流氓软件，这些体验都深入人心。安全形象的崩塌是 IE 失去普通用户信任的主要原因。
标准层面的落后同样致命。Chrome 和 Firefox 的更新节奏越来越快，对 HTML5、CSS3、ES6 的支持越来越完善；而 IE 却因为必须兼容大量老系统，更新内核时必须小心翼翼。当一个页面在 Chrome 里表现完美，在 IE 里却布局错乱、动画卡顿，开发者自然会劝用户换浏览器。
4.2 现代浏览器的冲击
Firefox 在 2004 年重新定义了什么叫做“用户可选择的开源浏览器”，Chrome 则在 2008 年凭借极快的 JavaScript 引擎和多进程架构让用户感受到了明显速度差异。Chrome 还附带了一个巨大的扩展生态，开发者愿意为它开发插件，用户也因此形成了依赖。
对比之下，IE 的加载速度、扩展能力、开发者工具都落后一截。对开发者而言，Chrome 的 DevTools 效率比 IE 的 F12 工具高太多。对普通用户而言，Chrome 的简洁界面和同步体验也更友好。短短几年，IE 从“默认浏览器”变成了“下载 Chrome 的工具”。
4.3 系统版本绑定的死结
IE 的另一个问题是它和 Windows 系统版本强绑定。早期版本还能单独安装，但到了 IE9 以后，新版本只支持较新的 Windows。大量仍在使用 Windows XP 的用户被绑定在 IE6 或 IE8 上，升级 IE 就必须升级操作系统。对于企业来说，升级操作系统意味着硬件成本和业务兼容风险，于是很多老 IE 在企业里“顽强地活着”。
当连微软自己都放弃 XP 和旧版 EdgeHTML 时，Web 世界已经彻底站到了现代标准一边。IE 没有跟上时代，不是因为它没有能力，而是因为它身上的历史包袱太重，改不动了。
5. Edge Legacy：微软的第一次转身
5.1 一个必须摆脱 IE 品牌的新浏览器
随着 Windows 10 在 2015 年发布，微软推出了全新浏览器 Microsoft Edge，开发代号 Project Spartan。微软当时很清楚地知道：IE 这个名字在普通用户心中的“老旧、卡顿、不安全”印象实在太深，必须用一个新品牌来承接未来。
初代 Edge，也就是后来社区常称的 Edge Legacy/EdgeHTML 版，采用了微软自研的 EdgeHTML 渲染引擎和 Chakra JavaScript 引擎。它在 UI 设计上更简洁，集成了 PDF 阅读、阅读视图、Cortana 语音助手等功能。微软对其寄予厚望，希望它能帮助 Windows 10 用户告别 IE8/IE9 时代。
5.2 Edge Legacy 为什么没有做大
初代 Edge 在 Windows 10 上作为默认浏览器，理论上用户基数很大，但实际份额却远低于预期。最大问题是扩展生态太弱。Chrome 之所以受欢迎，丰富扩展是重要因素；而 Edge Legacy 在很长一段时间里只能使用微软官方商店里屈指可数的几个插件，很多用户一搜发现自己需要的扩展没有，就直接转投 Chrome 了。
另一个问题是更新节奏。Edge Legacy 跟随 Windows 10 的功能更新节奏发布新特性，更新周期远远慢于 Chrome 的数周一次。开发者没有理由为一个更新慢、扩展少、调试工具不成熟的浏览器做额外优化。所以初代 Edge 的市场数据始终惨淡，企业用户也并没有因为系统预装就直接放弃 Chrome。
6. Chromium 版 Edge：第二次转身，反而走对了
6.1 2018 年：微软宣布放弃自研内核
2018 年 12 月，微软宣布 New Edge 将基于 Chromium 开源项目开发。这个决定在开发者社区引起了巨大震动。有人觉得微软终于务实，也有人担忧 Chromium 内核会加剧一家独大。但无论如何，对普通用户和企业用户来说，这个决定解决了最核心的问题：兼容性。
Chromium 版 Edge 使用 Blink 排版引擎和 V8 JavaScript 引擎，可以安装 Chrome 商店的扩展，同时保留了微软自己的账号同步、PDF 阅读、大声朗读、垂直标签页、睡眠标签等功能。2020 年 1 月，Chromium 版 Edge 正式发布，并逐步通过 Windows Update 推送给所有 Windows 10 用户。到这时，Edge 才算真正拥有了和 Chrome 正面竞争的底子。
6.2 Edge 与 Chrome 最大的差异：IE 模式
Chromium 版 Edge 和 Chrome 都非常“现代”，但两者有一个关键差异：Chrome 完全没有 IE 兼容能力，而 Edge 内置了 IE 模式。IE 模式本质上是让 Edge 在需要时调用 Trident/MSHTML 引擎来渲染特定网页，从而支持 ActiveX 控件、旧版文档模式和企业级站点列表。
对开发者而言，IE 模式最大的价值是“兜底”。当你维护的老系统没法在短时间内迁移时，不需要强制用户再去下载一个已经停止支持、满是安全风险的 IE 浏览器，而是可以在新版 Edge 里直接打开兼容模式。对 IT 运维来说，可以统一分发站点列表，让用户进入 OA、ERP、银行系统时自动切换渲染引擎。
6.3 为什么企业开始接受 Edge
越来越多的企业选择 Edge，并不是因为 Edge 的界面比 Chrome 更漂亮，而是因为它的可管理性。企业 IT 可以通过组策略集中配置 Edge 的更新策略、主页、扩展、IE 模式站点列表和受信任站点。Windows 域环境下，用组策略管理 Edge 比管理 Chrome 更顺手。
另外，Edge 以 Chromium 为内核之后，以前为 Chrome 开发的网页、插件和调试工具基本都能通用。用户从 Chrome 迁移到 Edge 的成本很低，企业 IT 也少了很多“用户自己下载 Chrome”带来的安全隐患。从这个角度来说，Edge 不是第二个 IE，而是微软用 Chromium 生态补课之后的新一代企业级浏览器。
7. IE Mode：老系统和现代浏览器之间的桥
7.1 IE 模式到底做了什么
很多不理解内核原理的人会以为，Edge 的 IE 模式只是换了浏览器的“皮肤”或者伪装了 User-Agent。实际上，IE 模式是真实地调用了 IE 的渲染引擎。Edge 浏览器遇到配置为 IE 模式的站点时，页面会交给 Trident/MSHTML 进程渲染，运行在 IE11 的环境里，包括 ActiveX、旧版 DOM 和旧版 CSS 解析规则都会被模拟出来。
这带来两个结果。第一，以前必须使用 IE11 才能打开的老系统，现在理论上可以在 Edge 里继续使用。第二，IE 模式并不是完整的 IE 替代品。它更偏向于企业内部场景，很多面向个人用户的旧版 IE 功能并不会被继续维护，所以不要把所有 IE 兼容问题都寄托在 IE 模式上，尽早迁移才是长久之计。
7.2 什么时候必须用 IE 模式
最典型的判断标准是：页面里是否存在 ActiveX 控件、旧版文档模式要求、或依赖 IE 专属 API 的组件。如果你打开页面时出现“不能装载 NTKO 大文件上传控件，请确保使用 IE 浏览器，并检查浏览器的安全设置”这类提示，说明当前页面需要 IE 内核环境。
另一个场景是登录弹窗被拦截。有些老系统点击“登录”后弹出的其实是一个新的浏览器窗口，如果浏览器启用了弹窗拦截，你可能什么提示都看不到。这种问题常常被误认为“页面没有反应”，实际上只要把站点加入受信任区域并允许弹出窗口，问题就解决了。我遇到过不少这种情况。
7.3 手动开启 IE 模式与默认 30 天限制
对于个人用户或测试环境，最快的方法是手动开启 IE 模式。以常见版本的 Edge 为例，操作步骤如下：
- 在地址栏输入
edge://settings/defaultBrowser，进入“默认浏览器”设置页。 - 在“Internet Explorer 兼容性”里，把“允许在 Internet Explorer 模式下重新加载网站”设置为“允许”。
- 重启浏览器使配置生效。
- 打开需要使用 IE 内核的网页，点击浏览器右上角的“...”菜单，选择“更多工具”，再点击“在 Internet Explorer 模式下重新加载”。
- 网页重新加载后，地址栏左侧会出现 IE 模式的图标，说明当前页面已切换到 IE 模式。
这个过程中有一个常被诟病的产品逻辑：手动打开的 IE 模式默认只会保留 30 天。30 天后，浏览器会重新用现代模式打开页面，用户如果仍然需要 IE 模式，就得再次手动切换。这在企业场景中非常麻烦，尤其是使用频率不高的业务系统，用户往往忘记怎么切换。
想要彻底解决 30 天限制，推荐通过企业策略管理，而不是反复让用户手动操作。管理员可以把常用站点配置为企业模式站点列表
