企业官网建设流程全解析

简介：面向MFC程序员的VC++源码示例，用于解决在WebBrowser控件中加载HTML网页时始终显示滚动条的问题。核心思路是监听documentcomplete事件，待HTML下载完成后再将滚动条隐藏，适合在对话框程序中嵌入浏览器、希望界面更简洁或需要自定义样式的开发者参考。压缩包共17个文件，约26KB，以C++头文件（.h）与源文件（.cpp）为主，除对话框主类MFCHtmlNoScrollDlg和WebBrowser封装类webbrowser2外，还包含.rc资源脚本、.ico图标、工程文件（.dsw/.dsp/.clw）以及ReadMe说明文档，结构简单清晰。已有183人学习/下载，代码可直接编译运行观察效果。通过阅读源码，可以掌握WebBrowser控件的加载控制、事件挂接方法、滚动条隐藏的实现技巧，同时还能了解MFC对COM接口的封装方式以及对话框资源与代码的配合流程，是一份小巧实用的学习范例。

1. 为什么要在 MFC 程序里塞一个 WebBrowser 控件

用 MFC 维护老系统的同学，迟早会遇到一个需求：把一段带样式的 HTML 塞进对话框里显示。报表要彩色表头，帮助要图文混排，设备状态面板想用 CSS+JS 画实时进度条，用 GDI 手绘能画到天亮。把 IE 内核以 ActiveX 控件形式嵌进 MFC 窗口，也就是挂一个 WebBrowser 控件，是 VC++ 工具箱里性价比最高的方案，不需要引入额外的 WebView2 运行时，Windows 从 XP 到 Win11 全系列自带。

标题里的"加载 HTML"实际是三条路：加载 URL、加载本地文件、加载内存字符串，对应 Navigate、file:// 协议和 IHTMLDocument2::write 三套做法。下面按宿主方式、加载路径、双向通信、收尾技巧的顺序展开，提供可以直接落地的 VC++ 代码和参数说明。这篇不摆大而全的原理框图，只讲自己会照着做的方案和踩过的坑。适合正在维护 MFC 工程的人，也适合刚把控件拖进对话框、一运行就白屏的新手。

2. WebBrowser 控件的宿主方式与 COM 接口选型

2.1 对话框拖入与动态创建：两条宿主路径

对话框已经建好的前提下，最快的宿主方式是打开 .rc 资源编辑器，在对话框空白处右键选择"插入 ActiveX 控件"，再选中 "Microsoft Web Browser"。VC6、VS2008、VS2010、VS2015 到 VS2022 的步骤都一样，ClassWizard 会自动生成 CWebBrowser2 包装类和控件成员变量，默认控件 ID 是 IDC_EXPLORER1。这个方案适合所有基于对话框的 MFC 工程，控件拖进去几分钟就能跑通第一版。

动态创建适用于非对话框窗口，典型场景是把浏览器放进 CSplitterWnd 的左右窗格里，或者自绘 Tab 页里。做法是拿一个 CWnd 派生类调 CreateControl，CLSID 用 WebBrowser 控件的标准值：

class CBrowserWnd : public CWnd { public: BOOL CreateBrowser(CWnd* pParent, const CRect& rc) { // WebBrowser 控件的标准 CLSID，业界统一用这个字符串在代码里创建 return CreateControl( _T("{8856F961-340A-11D0-A96B-00C04FD705A2}"), NULL, WS_VISIBLE | WS_CHILD, rc, pParent, AFX_IDW_PANE_FIRST); } };

CreateControl 的六个参数依次是控件 CLSID、窗口名、窗口样式、位置矩形、父窗口、控件 ID。最容易出错的是 pParent：父窗口必须已经创建好，而且父窗口内部要完成 ActiveX 容器初始化，否则创建时直接抛 COleException，没有任何可见窗口。所以动态创建一般放在父窗口的 OnCreate 末尾，先 Create 父窗口再创建浏览器窗格。CLSID 里的花括号和短横线一个都不能少，排错时最容易忽略的就是这里看漏一位。

2.2 核心接口 IWebBrowser2 与 CWebBrowser2 包装类的关系

不管是拖入还是动态创建，程序最终操作的都是 COM 接口 IWebBrowser2。ClassWizard 生成的 CWebBrowser2 本质是一个 IDispatch 包装类，内部从 CWnd::GetControlUnknown() 拿到控件的 IUnknown，再 QueryInterface 出 IWebBrowser2，把方法封装成成员函数。有一处容易混：包装类生成的事件处理函数带 "Explorer" 后缀（OnDocumentCompleteExplorer），普通方法名不带后缀。

IWebBrowser2 常用方法不算多，维护老代码时对照这张表足够：

如果工程里没生成包装类，可以裸调接口。注意 VARIANT 参数必须先用 VariantInit 初始化，不能图省事传 NULL，IE 对 NULL 参数的处理各版本不一致，轻则不生效，重则崩溃：

VARIANT vEmpty; VariantInit(&vEmpty); // VARIANT 参数统一先初始化，这是老手也会踩的坑 IWebBrowser2* pBrowser = NULL; m_web.GetControlUnknown()->QueryInterface(IID_IWebBrowser2, (void**)&pBrowser); if (pBrowser) { pBrowser->Navigate(CComBSTR(_T("about:blank")), &vEmpty, &vEmpty, &vEmpty, &vEmpty); pBrowser->Release(); }

这段代码的五个参数依次是 URL、Flags、目标框架名、POST 数据和附加请求头。about:blank 是后面反复出现的"空文档跳板"，它的作用是让控件先生成一个干净的 document 对象，之后才能往里写内容。QueryInterface 出来的接口用完要 Release，包装类内部会自己管理，裸调用就得手动释放，漏了就是内存泄漏。

2.3 三个前置工作：OLE 初始化、浏览器模式注册表、DPI

宿主建好、接口拿到还不够，三个前置工作缺一个，控件表现都会很诡异，而且查半天查不到根因。

第一个是 OLE 初始化。App::InitInstance 里必须有 AfxOleInit()，它内部调用 OleInitialize 完成 COM 库初始化。少了这一行，ActiveX 控件创建时报"未指定的错误"，或者控件区域一片空白。新建 MFC 工程时向导默认带上，但往老工程里塞控件的很容易漏。发布到没装开发环境的机器上时，动态链接的工程要带上 mfc140u.dll 一类运行时库，或者让用户装 VC++ 运行库合集，这也是 MFC 控件应用最常见的交付问题。

第二个是浏览器内核版本。IE8 之后出于兼容考虑，WebBrowser 控件默认按 IE7 文档模式渲染，后果是 flex 布局、border-radius、ES5 数组方法全不认。解法是启动时写注册表，告诉 IE 这个 EXE 用哪个文档模式。注册表路径是：

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION

键名是 EXE 文件名（例如 MyApp.exe），值是 DWORD。32 位程序在 64 位系统上运行，写 HKCU 时系统自动重定向到 Wow6432Node，代码不用分两套路径：

BOOL SetBrowserEmulationLevel() { TCHAR szPath[MAX_PATH] = {0}; GetModuleFileName(NULL, szPath, MAX_PATH); CString strExe = szPath; strExe = strExe.Mid(strExe.ReverseFind(_T('\\')) + 1); // 只取文件名 CRegKey key; if (key.Create(HKEY_CURRENT_USER, _T("Software\\Microsoft\\Internet Explorer\\Main\\FeatureControl\\FEATURE_BROWSER_EMULATION"), REG_NONE, REG_OPTION_NON_VOLATILE, KEY_SET_VALUE) == ERROR_SUCCESS) { // 11001 = IE11 Edge 文档模式；XP 老机器只能用 8000 return key.SetDWORDValue(strExe, 11001) == ERROR_SUCCESS; } return FALSE; }

GetModuleFileName 取当前进程的 EXE 名，注册表键名必须和 EXE 名严格一致，拼写不同就不生效。SetDWORDValue 的第二个参数是文档模式值，常见取值如下：

第三个是 DPI。高分辨率屏幕上控件会被系统拉伸变模糊，工程声明 PerMonitorV2 DPI 感知后，页面按 100% 缩放渲染，配合 CSS 的 px 单位不会糊。manifest 里声明 dpiAwareness 即可，网页端 CSS 不用额外改。

3. 三种加载 HTML 的路径：URL、本地文件与内存字符串

3.1 Navigate 加载 URL：五个参数与本地文件写法

Navigate 在包装类里的典型调用长这样：

CComVariant vFlags(0L); // 导航标志，默认 0 CComVariant vTargetFrame; // 目标框架名，空表示当前框架 CComVariant vPostData; // POST 数据，GET 请求传空 CComVariant vHeaders(L"Content-Type: application/x-www-form-urlencoded\r\n"); m_web.Navigate(strUrl, &vFlags, &vTargetFrame, &vPostData, &vHeaders);

vFlags 是导航选项的位组合，业务里常用这几个值：

vPostData 在 POST 请求时填入表单体，配合 vHeaders 里的 Content-Type 用；GET 请求保持空。vTargetFrame 填 iframe 的 name 可以让导航只发生在那个子框架里，填 NULL 或者空 VARIANT 就是当前整个文档。

本地文件的 URL 形式是三个斜杠加盘符，反斜杠不行：

m_web.Navigate(_T("file:///D:/app/html/report.html"), &vFlags, &vTargetFrame, &vPostData, &vHeaders);

路径里的中文必须做 URL 编码，IE 遇到未编码的中文路径直接拒绝，表现为页面空白。编码可以用 wininet 的 InternetCanonicalizeUrl，或者自己按 UTF-8 做百分号编码。UNC 网络路径写 file://server/share/page.html，前提是 IE 所在进程能访问该共享，且服务器名能被解析。

3.2 内存字符串写 HTML：about:blank 跳板与 IHTMLDocument2::write

大量业务是 C++ 端动态拼 HTML，比如把数据库查询结果、扫码内容拼成报表表格，用 HTML+CSS+JS 做出来的表单和图表在控件里都能直接渲染。这时候不该写临时文件再 Navigate，而是直接往文档对象里写字符串。标准套路分两步：先 Navigate 到 about:blank，等文档就绪，再拿 IHTMLDocument2 调 write()。

BOOL LoadHtmlString(CWebBrowser2& web, const CString& strHtml) { // 第一步：先导航到空文档，让控件内部创建 document 对象 CComVariant vEmpty; web.Navigate(_T("about:blank"), &vEmpty, &vEmpty, &vEmpty, &vEmpty); // 第二步：取 document。工程里请在 OnDocumentCompleteExplorer // 事件里设置就绪标志后再调用本函数，避免时序竞争 IDispatch* pDispDoc = NULL; CComPtr<IHTMLDocument2> spDoc; web.get_Document(&pDispDoc); if (pDispDoc) { pDispDoc->QueryInterface(IID_IHTMLDocument2, (void**)&spDoc); pDispDoc->Release(); } if (!spDoc) return FALSE; // 第三步：write 需要 SAFEARRAY，元素是 VT_VARIANT CComBSTR bstrHtml(strHtml); SAFEARRAY* psa = SafeArrayCreateVector(VT_VARIANT, 0, 1); if (!psa) return FALSE; LONG idx = 0; CComVariant vValue(bstrHtml); SafeArrayPutElement(psa, &idx, &vValue); spDoc->write(psa); // 写入整段 HTML，包括 <html><head> 等标签 spDoc->close(); // 必须 close，否则页面停在加载中状态 SafeArrayDestroy(psa); return TRUE; }

为什么要先跳 about:blank：WebBrowser 控件的 document 对象不能凭空生成，必须先有一次成功导航让内部创建宿主文档，之后 write 才是有效的 DOM 写入。跳过第一步直接 write 会返回 E_UNEXPECTED，页面上什么都不出现。write 之后必须 close()，不然脚本不执行、图片不加载，页面一直转圈。

字符集的坑集中在页面声明上。从文件加载时，文件的物理编码必须与一致；从内存字符串 write 时，字符已经以 UTF-16 存在于内存中，meta 主要影响页面后续通过 src、href 加载的子资源。实际踩坑最多的场景是：代码里用 GBK 把文件写进磁盘，HTML 却声明 utf-8，中文全变成问号。反过来声明 gb2312 就没问题。多字节工程里 CString 默认 GBK，内存字符串建议页面声明 gb2312，原样传入最省事。

3.3 从 EXE 资源加载 HTML：IPersistStreamInit 与相对路径

把帮助文档、协议说明书直接编译进 EXE，发布只带一个 exe，适合不变更的内容。做法是先定位资源，用 CreateStreamOnHGlobal 生成 IStream，再把流交给 IPersistStreamInit：

BOOL LoadResourceHtml(CWebBrowser2& web, UINT nResId) { // 前提：document 已就绪，同 3.2 的先导 about:blank 流程 IDispatch* pDispDoc = NULL; CComPtr<IPersistStreamInit> spPersist; web.get_Document(&pDispDoc); if (!pDispDoc) return FALSE; pDispDoc->QueryInterface(IID_IPersistStreamInit, (void**)&spPersist); pDispDoc->Release(); if (!spPersist) return FALSE; // 资源类型自定义为 "HTML"，.rc 里写：IDR_PAGE1 HTML "page1.html" HRSRC hRes = FindResource(AfxGetResourceHandle(), MAKEINTRESOURCE(nResId), _T("HTML")); if (!hRes) return FALSE; HGLOBAL hGlob = LoadResource(AfxGetResourceHandle(), hRes); DWORD dwSize = SizeofResource(AfxGetResourceHandle(), hRes); LPVOID pData = LockResource(hGlob); // 资源 HGLOBAL 可能是只读的，先复制一份再挂到 stream 上 HGLOBAL hMem = GlobalAlloc(GMEM_MOVEABLE, dwSize); memcpy(GlobalLock(hMem), pData, dwSize); GlobalUnlock(hMem); CComPtr<IStream> spStream; if (FAILED(CreateStreamOnHGlobal(hMem, TRUE, &spStream))) { GlobalFree(hMem); return FALSE; } HRESULT hr = spPersist->Load(spStream); // 流内容直接成为文档 GlobalFree(hMem); return SUCCEEDED(hr); }

资源方式的坑在 base 路径。页面从资源流加载后，document.URL 还是 about:blank，页面里相对路径的全部找不到。常见解法是在 HTML 的 head 里写指定绝对基准，或者在拼 HTML 时就把相对路径替换成绝对路径。

三种加载方式怎么选，可以按这张表对号入座：

4. C++ 与页面双向通信：事件接收、JavaScript 互调与常见坑

4.1 用 DWebBrowserEvents2 接住加载事件，注意 iframe 干扰

WebBrowser 控件把页面加载过程通过连接点抛出来，MFC 的 ActiveX 容器用事件接收映射接住。ClassWizard 生成的事件函数长这样：

void CMyDialog::OnNavigateComplete2Explorer(LPDISPATCH pDisp, VARIANT* URL) void CMyDialog::OnDocumentCompleteExplorer(LPDISPATCH pDisp, VARIANT* URL)

事件映射表里对的是 DISPID，常用这几个：

映射代码形式如下，注意事件函数的参数签名要和 VTS 声明严格对应：

BEGIN_EVENTSINK_MAP(CMyDialog, CDialogEx) ON_EVENT(CMyDialog, IDC_EXPLORER1, DISPID_NAVIGATECOMPLETE2, CMyDialog::OnNavigateComplete2Explorer, VTS_DISPATCH VTS_PVARIANT) ON_EVENT(CMyDialog, IDC_EXPLORER1, DISPID_DOCUMENTCOMPLETE, CMyDialog::OnDocumentCompleteExplorer, VTS_DISPATCH VTS_PVARIANT) END_EVENTSINK_MAP()

最常见的错误是在 OnDocumentComplete 里直接操作 DOM 却发现子框架还没好。页面里有 iframe 时，每个子框架完成也会触发一次 DocumentComplete，必须用 pDisp 判断是不是最外层文档：

void CMyDialog::OnDocumentCompleteExplorer(LPDISPATCH pDisp, VARIANT* URL) { if (!m_web.GetSafeHwnd()) return; IDispatch* pApp = NULL; m_web.GetControlUnknown()->QueryInterface(IID_IDispatch, (void**)&pApp); if (pDisp == pApp) // 关键判等：只有最外层文档完成才进来 { m_bHtmlReady = TRUE; LoadHtmlString(m_web, m_strPendingHtml); // 之前 3.2 的时序问题在这解决 } if (pApp) pApp->Release(); }

pDisp 与控件自己的 IDispatch 指针比较，是过滤 iframe 事件的业界标准做法。很多新手直接忽略 pDisp，结果回调跑好几遍，加载标志位被反复横跳。

4.2 C++ 侧调用 JS 函数：get_Script 与 Invoke 的参数顺序

C++ 需要主动通知页面时，比如用户点了工具栏"刷新数据"，可以调用页面里的 JS 函数。入口是 IHTMLDocument2::get_Script：

BOOL CallJsFunction(CWebBrowser2& web, LPCTSTR szFunc, LPCTSTR szArg) { CComPtr<IDispatch> spDocDisp; CComPtr<IHTMLDocument2> spDoc; web.get_Document(&spDocDisp); if (!spDocDisp) return FALSE; spDocDisp->QueryInterface(IID_IHTMLDocument2, (void**)&spDoc); if (!spDoc) return FALSE; CComPtr<IDispatch> spScript; spDoc->get_Script(&spScript); // 页面的 script 对象，全局函数挂在上面 if (!spScript) return FALSE; CComBSTR bstrName(szFunc); DISPID dispid = 0; if (FAILED(spScript->GetIDsOfNames(IID_NULL, &bstrName, 1, LOCALE_USER_DEFAULT, &dispid))) return FALSE; // 函数不存在会在这一步失败 CComVariant vArg(szArg); DISPPARAMS dp = {0}; dp.rgvarg = &vArg; // rgvarg 是倒序，最后一个元素对应 JS 第一个参数 dp.cArgs = 1; CComVariant vResult; return SUCCEEDED(spScript->Invoke(dispid, IID_NULL, LOCALE_USER_DEFAULT, DISPATCH_METHOD, &dp, &vResult, NULL, NULL)); }

调用示例是CallJsFunction(m_web, _T("refreshData"), _T("2024"))。DISPPARAMS 的参数顺序是反的，JS 函数有多个参数时，rgvarg[0] 放最后一个参数，rgvarg[1] 放倒数第二个，依次类推。这一步搞反了，页面会收到脏数据而不是报错，特别难排查。另外 JS 函数必须已经定义，脚本放在 head 里且没有语法错误，否则 GetIDsOfNames 返回 DISP_E_UNKNOWNNAME。

4.3 页面调 C++：window.external 与 IDocHostUIHandler 接管

页面里写 window.external.SaveData("hello") 是 WebBrowser 宿主编程的标准手法。默认宿主不会提供 external 对象，必须自己实现 IDocHostUIHandler::GetExternal，把 C++ 对象以 IDispatch 暴露给页面。MFC 下的常见做法是劫持控件宿主站点，拦截 IID_IDocHostUIHandler：

class CMyOleControlSite : public COleControlSite { public: CMyOleControlSite(COleControlContainer* pContainer, CWnd* pWnd) : COleControlSite(pContainer, pWnd) {} STDMETHOD(QueryInterface)(REFIID iid, LPVOID* ppvObj) { if (iid == IID_IDocHostUIHandler) // 拦截浏览器宿主接口 { *ppvObj = &m_uiHandler; return S_OK; } return COleControlSite::QueryInterface(iid, ppvObj); } private: CMyUiHandler m_uiHandler; // IDocHostUIHandler 实现，见第 5 章 };

然后重写 COccManager::CreateSite，让控件容器用这个站点类。VC6 下没有 override 关键字，去掉即可，签名以你所用 VS 版本的头文件为准：

class CMyOccManager : public COccManager { public: virtual COleControlSite* CreateSite(CWnd* pWnd, UINT nID, const COleControlContainer::CONTROLDOCKING* pDock) { return new CMyOleControlSite(pWnd->GetContainer(), pWnd); } }; // InitInstance 里挂到 MFC 全局容器管理器上 static CMyOccManager g_occManager; extern COccManager* afxOccManager; // afxwin.h 里已有声明 afxOccManager = &g_occManager;

external 对象本身需要实现 IDispatch。手动写一个精简版，GetTypeInfoCount 和 GetTypeInfo 返回 E_NOTIMPL，只实现 GetIDsOfNames 和 Invoke：

// JS 里调用 window.external.SaveData("hello") 时进入这里 STDMETHODIMP CExternalObj::Invoke(DISPID dispidMember, REFIID, LCID, WORD, DISPPARAMS* pDispParams, VARIANT*, EXCEPINFO*, UINT*) { if (dispidMember != 1) return DISP_E_MEMBERNOTFOUND; if (pDispParams == NULL || pDispParams->cArgs < 1) return E_INVALIDARG; // 参数倒序：rgvarg[0] 对应 JS 调用里的最后一个参数 CString strData = pDispParams->rgvarg[0].bstrVal; SaveToFile(strData); // C++ 侧真正执行的动作 return S_OK; } STDMETHODIMP CExternalObj::GetIDsOfNames(REFIID, OLECHAR** rgszNames, UINT cNames, LCID, DISPID* rgDispId) { if (cNames > 0 && wcscmp(rgszNames[0], L"SaveData") == 0) { rgDispId[0] = 1; // 自己维护方法编号，Invoke 里对照 return S_OK; } return DISP_E_UNKNOWNNAME; }

IDispatch 另外三个成员 QueryInterface、AddRef、Release 按标准 IUnknown 实现，套路固定。这个方法让页面把数据传回 C++，绕过 URL 传参的长度限制，也不需要在页面里拼一堆隐藏 iframe。

4.4 三个高频坑：写入时序、字符集与安全提示

写入时序排在第一位。3.2 的 LoadHtmlString 如果放在按钮事件里直接调，about:blank 还没加载完就 get_Document，拿到的 document 是过期的，或者 write 报错。稳妥的顺序是先导航 about:blank，在 OnDocumentCompleteExplorer 的 pDisp 判等分支里设置标志位，再执行写入。凡是看到"页面偶尔正常、偶尔空白"，基本就是这里时序竞争。

字符集坑在加载本地文件时最典型。文件用 GBK 保存，HTML 第一行写，页面打开全乱码。让文件物理编码和 meta 声明一致是第一原则；动态拼字符串时把声明和转换逻辑放同一个函数，避免两个地方各写一套。安全提示坑多出现在 file:// 协议加载外部拷贝来的文件，文件带 MOTW（Mark of the Web）标记时 IE 顶部会亮安全条阻止脚本。C++ 里可以尝试删除文件的数据流标记来解决，更干净的做法是从自己的模板目录生成 HTML，而不是直接打开用户下载的副本。

5. 最后一公里：屏蔽脚本错误、页面自适应与加载验证

5.1 屏蔽右键菜单和脚本错误，只留干净页面

WebBrowser 默认行为会把 IE 的右键菜单、脚本错误弹窗、页面缩放菜单都带进你的程序，观感很割裂。有了 4.3 的 IDocHostUIHandler 接管，只需要实现三个方法就能把这些全压掉：

STDMETHODIMP CMyUiHandler::ShowContextMenu(DWORD, POINT*, IUnknown*, IDispatch*) { return S_OK; // 吞掉右键菜单，页面自己的 contextmenu 事件仍可用 } STDMETHODIMP CMyUiHandler::DisplayScriptError() { return S_OK; // 脚本报错不弹窗，页面继续执行其他逻辑 } STDMETHODIMP CMyUiHandler::GetExternal(IDispatch** ppDispatch) { *ppDispatch = &m_extObj; // 4.3 的 CExternalObj m_extObj.AddRef(); return S_OK; }

注意 DisplayScriptError 返回 S_OK 表示事件已被消费，之后页面报错只会在内部记录，用户完全看不到。如果调试阶段想看到错误，临时把这个函数改成返回 E_NOTIMPL 即可。IDocHostUIHandler 还有十几个方法，其余统一返回 E_NOTIMPL 就行。

5.2 控件随对话框自适应，页面不漏滚动条

对话框拉伸时控件不会自动铺满，需要响应 WM_SIZE。这里的 m_web 是对话框的成员控件，GetSafeHwnd 判空防止窗口还没创建就调用：

void CMyDialog::OnSize(UINT nType, int cx, int cy) { CDialogEx::OnSize(nType, cx, cy); if (m_web.GetSafeHwnd()) { // 铺满客户区，不留边；上下有工具栏时自己计算偏移 m_web.MoveWindow(0, 0, cx, cy); } }

页面要配合把滚动条藏掉，在 HTML 的 head 加一段 CSS，同时把 body 边距清零，这样页面和控件窗口严丝合缝：

<style> html, body { overflow: hidden; margin: 0; padding: 0; } </style>

页面按桌面常见宽度设计，比如固定 1024px 布局，控件窗口小于该宽度时内容裁切而不是横向滚动，这是与滚动条隐藏配套的取舍。高 DPI 下如果页面被放大，检查 manifest 的 PerMonitorV2 声明，和 2.3 的注册表配合使用。

5.3 验证文档模式与加载结果的三个手段

页面不渲染时，先用 execScript 做冒烟测试，确认 DOM 和脚本引擎是活的。execScript 可以执行任意 JS 表达式，把结果返回给 C++：

CComPtr<IHTMLWindow2> spWin; CComPtr<IHTMLDocument2> spDoc; // 来自 get_Document if (SUCCEEDED(spDoc->get_parentWindow(&spWin))) { CComBSTR bstrOut; spWin->execScript(CComBSTR(_T("document.title")), CComBSTR(_T("javascript")), &bstrOut); // bstrOut 里是当前页面 title，能取到就说明 DOM 就绪 }

调试 JS 逻辑时，把系统 IE 的"禁用脚本调试"取消勾选，然后在 VS 里用"附加到进程"挂上你的 exe，页面脚本抛异常时能直接断在源码行。网络请求层面的问题优先用 Fiddler 抓包，WebBrowser 走 WinINET，Fiddler 无需任何配置就能看到控件发出的请求、响应码和缓存命中情况。最后回头检查 2.3 写的注册表键名是不是和 EXE 名完全一致，这一项错了页面表现就是新版 CSS 全部失效，而抓包看起来一切正常。验证顺序建议先 execScript 确认 DOM，再附加调试器查脚本，最后抓包看请求链路，把这三样凑齐，这个控件才算是真正接稳了。

本文还有配套的精品资源，点击获取