摆脱 IE 模式依赖系统的实践指引

本文一句话总结

「在正式运维下安全地使用 IE 模式，同时一点点减少依赖，最终把 IE 模式降到零」——这才是现实可行的策略。丢掉之前，先把它管好。

背景：IE 模式能用到「什么时候」

这里需要注意的是，并不是说能用到 2029 年就可以放心搁置不管。这段时间终究只是「为了有计划地退出而留出的缓冲期」，如果不想等到 2029 年临近才手忙脚乱，从现在起就只能开始着手准备。

为什么摆脱不了对 IE 模式的依赖

IE 模式是在基于 Chromium 的 Edge 里面，只用 Trident（MSHTML）引擎 渲染旧站点的一套机制。这个 Trident 引擎承接了下面这些内容。

• 老旧的文档模式（Document Mode）
• ActiveX 控件 / BHO（Browser Helper Object）
• 旧式的安全区域设置
• Enterprise Mode 的兼容性设置

只要还依赖这些东西，仅仅把浏览器升级到最新版本，问题并不会解决。看清依赖的真实面目，是第一步。

现场常见的问题

1. 文档模式配置错误 → 页面错乱、脚本报错
2. 中立站点配置遗漏 → SSO（单点登录）出现重新认证循环或重定向循环
3. Enterprise Mode Site List 的格式不符 → IE 模式集成不支持 schema v.1，需要迁移到 schema v.2
4. Edge 只会处理一份站点列表 → Edge 端的策略优先于 IE 端的策略

依赖的分类：先弄清楚「到底依赖的是什么」

步骤一：延续使用对策──先做到安全运维

1. 把站点列表管理到位（最重要）

把「重新加载」交给用户自行判断是很危险的。要通过策略正式管理起来。

该做的事：迁移到 Cloud Site List Management，统一管理谁、在哪些站点、用到什么时候的 IE 模式。

2. 把认证相关配置做扎实

一旦涉及 SSO，在 IE 模式与 Edge 模式之间切换时，认证经常会出问题。

• 正确配置中立站点（Neutral Site） → 明确指定 SSO 服务器
• 必要时配置 Cookie 共享
• 在还无法确定认证服务器之前，可以临时使用「在 IE 模式下保留页内导航」的策略（但一旦定下来就要停用）

3. 用好诊断工具

不要凭感觉，要根据观测数据来判断。

4. 实在无法修复的部分就「隔离」

步骤二：退出对策──如何减少依赖

方案对比表

★ 是实践中的首选方案。

各方案的适用场景

分阶段重构是最现实的方案。

• 不需要一次性全部推倒重来
• 只需按画面或功能逐个现代化改造即可
• 新旧并存期间的「入口设计」（哪个画面由哪个引擎运行）非常关键

WebView2 封装是用来「重新划清边界」的手段。

• 不是为了原样保留 ActiveX 或 COM 依赖
• 把「文件操作」「设备联动」「Windows 认证」等属于操作系统的职责移到原生端，让 Web UI 端实现现代化
• 但要注意 WebView2 Runtime 的分发责任会落到自己身上

微前端只有在「团队边界」与「部署边界」一致时才有效，不应该只因为流行就采用。

全面重写是最后的手段，仅限于对 ActiveX 或 BHO 的依赖过深、实在无法拆解的情况。

步骤三：具体推进方式（路线图）

评估 → 排定优先级 → PoC → 测试 → 上线 → 运维

1. 评估──依赖盘点

• 用 Enterprise Site Discovery 列出目标 URL
• 用 edge://net-export 把网络跳转过程可视化
• 把依赖分类为「文档模式」「ActiveX/BHO」「认证」「客户端证书」「文件/打印」「设备/COM」

2. 排定优先级──从哪里下手

按照下面这些维度重新排序。

• 重要程度（一旦中断影响有多大）
• 使用人数
• 安全暴露程度
• 对其他系统的波及程度
• 是否容易拆分（边界是否清晰）

尤其要把「切开边界就能推进的功能」和「必须连同边界一起替换的功能」区分开来，后续规划会更容易展开。

3. PoC（概念验证）──先小范围试点

第一个目标先从「业务价值高、依赖程度中等」的一个工作流入手。

成功的判定标准有以下 4 点。

1. 不再需要 IE 模式
2. SSO 保持正常
3. 响应性能达到可比较的水平
4. 可以回滚（能够还原到原状）

4. 测试──应对新旧并存

• 现代化路径 → 用 Playwright 对 Edge 做自动化测试
• IE 模式路径 → 诊断页面 + 人工确认
• 新旧并存期间要明确标注「哪条路径由哪个引擎运行」（不标注清楚，故障就很难复现）

5. 上线──逐步扩大范围

• Canary 发布（先向部分用户小范围推行）
• 用 Extended Stable（8 周周期）留出验证窗口
• 把站点列表的更新间隔与浏览器重启要求纳入运维流程
• 使用云端站点列表时，别忘了前提是要先登录 Edge

6. 运维──持续压缩

• 借助 Cloud Site List Management 的反馈功能，回收用户自行添加的站点或错误配置
• 建立每月缩减 IE 模式目标列表的运维周期
• 「延续使用对策」一定要配合「持续压缩」的运维方式一起执行

整体流程（流程图）

flowchart TD
    A[盘点目标资产] --> B[依赖分类]
    B --> C{依赖的种类是？}
    C -->|以文档模式・SSO为主| D[正式运维 IE 模式]
    C -->|以操作系统联动・COM为主| E[封装化]
    C -->|可按画面拆分| F[分阶段重构]
    C -->|多团队并行开发| G[微前端]
    C -->|依赖过深| H[全面重写]

    D --> I[调整中立站点与 Cookie]
    E --> J[WebView2/原生边界]
    F --> K[新旧共存与分阶段替换]
    G --> K
    H --> L[重新设计新架构]

    I --> M[PoC]
    J --> M
    K --> M
    L --> M

    M --> N[自动化测试与运维测试]
    N --> O[分阶段上线]
    O --> P[收集使用情况与反馈]
    P --> Q[缩减 IE 模式目标]
    Q --> R[判定下线]

步骤四：治理──管理框架

把 IE 模式明文规定为「例外运维」

• 新增的 IE 模式目标 URL，必须设置以下项目。
  • 业务负责人（谁是责任人）
  • 技术负责人（谁负责技术层面的管理）
  • 失效日期（何时之前必须退出）
  • 替代方案（如何退出）
• 如果现有的 XML 站点列表是 schema v.1，要迁移到 IE 模式集成可用的 schema v.2
• 变更历史要用 Cloud Site List Management 或配置管理工具追踪

安全方面的注意事项

• 固定使用旧版本 Edge 是有风险的 → 应使用最新的 Stable/Beta 系列
• 需要验证周期时，使用 Extended Stable（8 周周期）
• GPO 的质量检查可以用 Security Compliance Toolkit 或 Policy Analyzer
• 比起「IE 模式本身的漏洞」，「周边浏览器运维不到位」更容易导致事故

从时间轴反向推算

• IE 模式支持结束：2029 年
• Win10 22H2 的 Edge/WebView2 更新结束：2028 年 10 月

这些都只是「退出期限的外框」。应该先做出一张在支持结束前把依赖降到零的反推时间表。

按规模划分的建议策略

常见误区与对策

总结

标准策略 = 正式运维 IE 模式（防止事故）
           + 让依赖可视化（盘点）
           + 分阶段压缩（一个一个退出）

• 小规模就采用分阶段重构
• 大规模就用站点列表统一管控 + 项目组合管理
• 预算紧张就用虚拟化把现状封锁住，同时停止新增依赖
• 全面重写是最后的王牌
• 容器通常不在候选范围内，VDI 是避难所，IE 模式 是跑道（是为了起飞而存在的）

参考链接

• IE 与 Edge 的生命周期常见问题 ─ IE 模式的 2029 年方针
• IE 模式概述 ─ 支持范围的基础资料
• IE 模式的策略配置 ─ 集成配置的三个阶段
• Enterprise site configuration strategy ─ 中立站点、Cookie 共享、schema v.2
• IE mode troubleshooting and FAQ ─ 诊断页面、net-export 的用法
• Cloud Site List Management ─ 在管理中心集中管理
• Enterprise Site Discovery ─ 盘点的起点
• WebView2 文档 ─ 用于评估封装化方案
• Azure Virtual Desktop / RemoteApp ─ 作为隔离方案
• Windows Containers 迁移指南 ─ 不适合作为 GUI 延续使用方案
• App Assure ─ IE 模式配置协助的范围
• Playwright ─ Edge 自动化测试
• single-spa ─ 微前端的基础
• webpack Module Federation ─ 独立构建集成

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

Edge 的 IE 模式能用到什么时候？

按照现行方针，Edge 的 IE 模式至少会支持到 2029 年，并且会在停用前一年发出通知。另外，Windows 10 22H2 上 Edge / WebView2 Runtime 的更新，也至少会持续到 2028 年 10 月。不过这段时间只是给企业留出的有计划退出的缓冲期，不应把 2029 年当作「开始准备」的年份，而要把它当作「必须完成退出」的截止日期，反向推算进度。IE11 桌面应用程序本身早就已经退役。

为什么摆脱不了对 IE 模式的依赖？

因为 IE 模式是在基于 Chromium 的 Edge 里面，只用 Trident（MSHTML）引擎渲染旧站点的一套机制，而这个 Trident 引擎承接了老旧的文档模式、ActiveX 控件与 BHO、旧式安全区域设置，以及 Enterprise Mode 的兼容性设置。只要还依赖这些东西，仅仅把浏览器升级到最新版本并不能解决问题。第一步是先把依赖分类为文档模式、ActiveX/BHO、认证与 SSO、客户端联动、旧有运维前提，弄清楚依赖的真实面目。

退出 IE 模式有哪些方式？

主要选项有六种：继续使用 IE 模式、WebView2 封装、分阶段重构、微前端、全面重写，以及 VDI / RemoteApp 隔离。实践中的首选是分阶段重构，可以按画面或功能逐个现代化改造。WebView2 封装并不是为了保留 ActiveX，而是把文件操作、设备联动等属于操作系统层面的职责移到原生端，重新划清边界。全面重写则是在依赖过深、无法拆解时才用的最后手段。

如果暂时还要继续用 IE 模式，应该做什么？

首先，站点列表不能交给用户自行「重新加载」，而要通过策略正式纳入管理。切换到 Cloud Site List Management 之后，就能实现多份列表发布、变更历史记录、按组分配。涉及 SSO 时，要正确配置中立站点，必要时再配置 Cookie 共享。同时，新增的 IE 模式目标 URL 必须设置业务负责人、技术负责人、失效日期与替代方案，并配合每月缩减目标列表的运维周期。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。