IE停止支持后，CHtmlView与CHtmlEditCtrl的长期替代方案问询

核心替代方案及落地经验 #

1. 迁移至WebView2控件 #

这是微软主推的原生替代方案，基于Edge Chromium内核，支持现代Web标准且后续会持续维护。

• 集成方式：在MFC项目中引入WebView2的C++ SDK，将原CHtmlView的视图窗口替换为WebView2控件，通过CreateCoreWebView2Controller初始化控件并嵌入到MFC视图或对话框容器中。
• 适配CHtmlView逻辑：原有的导航、HTML内容设置等接口，可对应WebView2的Navigate、NavigateToString或ExecuteScript方法实现；页面事件回调通过注册ICoreWebView2NavigationCompletedEventHandler等接口处理。
• CHtmlEditCtrl适配：WebView2支持通过启用contenteditable属性实现富文本编辑，原有的编辑接口（如插入文本、格式化）需通过WebView2的ExecuteScript调用前端JS完成，实践中可封装一层C++接口对齐原有逻辑。

2. 采用Chromium Embedded Framework（CEF） #

开源跨平台的浏览器嵌入框架，自定义性极强，适合对浏览器功能有深度定制需求的场景。

• 集成方式：将CEF的窗口封装为MFC控件或视图类，通过CEF的C++ API初始化浏览器实例，注意处理MFC消息循环与CEF消息循环的兼容。
• 功能替换：完全覆盖CHtmlView的浏览能力；对于CHtmlEditCtrl，同样通过contenteditable属性启用编辑模式，还可通过CEF扩展API自定义编辑菜单、拦截编辑事件等。
• 实践注意：CEF学习曲线略高于WebView2，但不受微软版本约束，适合需要脱离Edge依赖的场景，需注意编译配置和资源占用优化。

3. 原生MFC控件组合（仅适配简单场景） #

如果原控件仅用于显示简单富文本、静态HTML内容，无复杂JS交互，可考虑用原生MFC控件替代：

• 替换CHtmlView：用CRichEditCtrl加载RTF格式内容（若原HTML可转换为RTF），或使用轻量HTML渲染库渲染简单HTML，避免引入重型浏览器控件。
• 替换CHtmlEditCtrl：用带格式支持的CRichEditCtrl配合自定义工具栏，实现基础的文本格式化功能，适合编辑需求简单的场景。

4. 模块拆分：独立Web应用+进程通信 #

若原应用中HTML相关模块逻辑复杂，可将这部分拆分为独立的Web应用（基于Edge/Chrome运行），MFC主程序通过进程间通信（IPC）与Web应用交互：

• 实现方式：通过Windows管道、共享内存或自定义消息传递数据，MFC主程序负责原生功能，Web应用处理HTML展示与编辑逻辑。
• 实践优势：彻底分离桌面与Web逻辑，后续Web部分可独立迭代，但需处理IPC的稳定性问题，比如状态同步、数据序列化。

迁移实践注意事项 #

• 逐步迭代：优先在功能独立的小模块试点迁移，验证兼容性后再推广到全应用，避免一次性重构风险。
• 兼容性适配：旧IE特有的JS API（如document.all）在新控件中可能不支持，需修改前端代码；原MFC与HTML的交互逻辑（如JS调用C++接口）需适配新控件的通信方式（WebView2的AddScriptToExecuteOnDocumentCreated、CEF的ExecuteJavaScript等）。
• 资源优化：WebView2/CEF的内存占用高于旧IE控件，需注意控件的销毁时机，避免内存泄漏；对于频繁创建销毁的场景，可考虑复用控件实例。

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