QWebEngineUrlRequestInterceptor是唯一能稳定捕获网页内所有请求的原生机制，因Chromium网络栈绕过Qt的QNetworkAccessManager；拦截器须在QWebEngineProfile创建后、页面加载前注册，仅支持轻量级请求头修改或重定向，无法获取响应体。
Qt 5.6+ 的 QWebEngineView 无法用传统网络层（如 QNetworkAccessManager）拦截网页内部发起的请求，必须使用 QWebEngineUrlRequestInterceptor —— 这是唯一能稳定捕获 Ajax、fetch、iframe、图片、字体等所有资源请求的原生机制。
为什么 QNetworkAccessManager 拦截不了网页里的请求？
因为 QWebEngineView 内部使用的是 Chromium 网络栈，完全绕开了 Qt 的 QNetworkAccessManager。你重写 createRequest() 或设置全局 QWebEngineProfile::setHttpUserAgent() 都不影响页面内 JS 发起的 fetch() 或 XMLHttpRequest。
- 常见错误现象：
QNetworkAccessManager子类里能捕获到你自己写的get()请求，但对网页中fetch("/api/data")完全无响应 - 根本原因：Chromium 在 IO 线程直接构造
URLRequest，不经过 Qt 网络模块 - 正确路径：必须通过
QWebEngineProfile::setUrlRequestInterceptor()注入拦截器
如何正确注册并实现 QWebEngineUrlRequestInterceptor？
拦截器必须在 QWebEngineProfile 创建后、QWebEngineView 加载任何页面前完成注册，否则首次导航请求会漏掉。
- 先创建独立 profile（避免影响默认 profile）：
auto profile = new QWebEngineProfile(this); - 再实例化拦截器并注册：
profile->setUrlRequestInterceptor(new MyRequestInterceptor(this)); - 拦截器类必须继承
QWebEngineUrlRequestInterceptor并重写interceptRequest() - 关键：不要在
interceptRequest()里做耗时操作（如文件 I/O、网络请求），它运行在 Chromium 的 IO 线程，阻塞会导致页面卡死
示例核心逻辑：
立即学习“C++免费学习笔记（深入）”；
void MyRequestInterceptor::interceptRequest(QWebEngineUrlRequestInfo &info) {
if (info.requestUrl().host() == "api.example.com" &&
info.resourceType() == QWebEngineUrlRequestInfo::ResourceTypeXhr) {
// 打印或修改头
info.setHttpHeader("X-From-Qt", "true");
// 可选：重定向到本地 mock
// info.redirect(QUrl("qrc:/mock.json"));
}
}
interceptRequest() 中能做什么、不能做什么？
这个函数只允许做轻量级判断和元数据修改，不是用来发新请求或解析响应体的地方。
- ✅ 允许：
info.requestUrl()、info.requestMethod()、info.resourceType()判断；info.setHttpHeader()添加/覆盖请求头；info.redirect()重定向到本地资源（qrc://或file://） - ❌ 禁止：
info.block()已废弃且无效；不能调用QWebEnginePage::runJavaScript()；不能访问QWebEngineView的 UI 对象（跨线程）；不能读取响应内容（此时响应还没产生） - ⚠️ 注意：
info.resourceType()返回的是整数枚举值，需对照文档查含义，比如7是ResourceTypeObject（插件），不是所有类型都常用
想抓响应体（比如 Ajax 返回的 JSON）怎么办？
QWebEngineUrlRequestInterceptor 只管请求发出前，不管响应。要拿到响应数据，必须换方案：
- 方案一（推荐）：用
QWebChannel让网页 JS 主动上报 —— 在页面里 hookfetch和XMLHttpRequest.prototype.send，把响应体通过webChannel.send()推给 C++ - 方案二（高阶）：改用 CEF3，它提供
OnResourceResponse()和OnResourceLoadComplete()回调，可直接读取原始响应流 - 方案三（折中）：在拦截器里
redirect()到一个本地 HTTP 服务（如 Qt 自带的QTcpServer），由该服务转发请求并捕获响应，但增加架构复杂度
真正容易被忽略的是：很多人以为拦截器能像浏览器 DevTools Network 面板一样看到完整请求-响应闭环，实际上它只是请求出口的“安检门”，响应数据必须另寻通路。别在 interceptRequest() 里浪费时间试图读取 response body —— 那里根本没有。
