JS 能调用window.desktop.openFile()——
并不是 Web 突然变强了，而是浏览器内核在背后完成了一整套跨进程绑定体系。

一、核心问题：JS 是怎么“看到” C++ 的？

我们从最终现象开始：

window.desktop.openFile("C:\\test.txt", callback)

这行 JS 的背后，是这样一条链：

JS ↓ V8 Native Function ↓ Renderer C++ (DesktopApiHelper) ↓ IPC ↓ Browser C++ (DesktopCmdHandler) ↓ Win32 Shell API

而WebHostView正是这个链路的“宿主容器入口”。

二、第一层：WebHostView 的真实职责

WebHostView 并不直接参与 JS 调用，它负责三件底层大事：

① 持有独立 WebContents

它不是 Tab，不是 WebUI，而是：

class WebHostView : public views::View { std::unique_ptr<content::WebContents> web_contents_; }

这意味着：

它拥有一个完整渲染环境，但不属于浏览器标签体系。

这为 JS API 注入提供了“私有运行时”。

② 控制 RenderFrame 生命周期

JS 绑定只能发生在：

RenderFrame 创建 → ScriptContext 建立

而 WebHostView 正是这个 RenderFrame 的创建触发者。

③ 它定义了“信任域”

浏览器不会把系统能力暴露给所有页面。
WebHostView 作为宿主，天然就是：

Trusted Web Runtime

只有这个运行时里的页面，才允许注入 desktop API。

三、真正的 JS 绑定发生在哪里？

很多人误以为 JS 绑定在 Browser 进程，实际上：

JS 能力注入发生在 Renderer 进程，通过 V8 Extension 完成。

关键类：

class DesktopApiExtension : public extensions_v8::Extension

这里定义了注入给页面的 JS：

const char kDesktopApiSource[] = R"( native function SendDesktopCmd(); native function SetCallback(); if (!window.desktop) window.desktop = {}; window.desktop.openFile = function(path, cb) { var id = SetCallback(cb); SendDesktopCmd(id, "openFile", path, "", "", ""); }; )";

注意：

这段 JS不是网页写的，而是浏览器内核塞进去的。

四、V8 是如何把 JS 调用转到 C++ 的？

JS 中的：

native function SendDesktopCmd();

会被绑定到：

void DesktopApiExtension::GetNativeFunction(...)

此时：

JS 调用 → V8 → C++ 回调函数

这一步是：

JavaScript 世界 → Renderer C++ 世界

五、Renderer 如何把请求送去 Browser？

Renderer 并没有权限操作系统，所以：

void DesktopApiHelper::DesktopApiCmd(...) { Send(new ExtensionHostMsg_DesktopApiCmd(...)); }

通过 IPC 发送到 Browser 进程。

这是安全模型的核心：

六、Browser 进程如何执行桌面操作？

Browser 收到 IPC 后进入：

DesktopCmdHandler::OnDesktopApiCmd(...)

然后调用：

这里浏览器本质上：

成为了 Web 的“系统代理进程”

七、结果如何回到 JS？

Browser：

ExtensionMsg_DesktopApiCmdResponse

Renderer：

DesktopApiHelper::OnDesktopApiCmdResponse(...) → DesktopApiExtension::HandleResponse(...) → JS callback

完整闭环形成。

八、WebHostView 在这套链路中的真实定位

很多人问：

“既然绑定在 Renderer，WebHostView 作用是什么？”

答案是：

WebHostView 是容器，不是桥，但没有它桥就无处可架。

九、为什么必须设计成这样？

❌ 不能让 JS 直接访问系统

这会打破浏览器沙箱安全模型。

❌ 不能在 Renderer 执行系统 API

Renderer 被沙箱限制。

✅ 必须走 Browser 代理

这就是：

浏览器 = 安全的桌面能力网关

十、这一机制的工程意义

WebHostView 不是 UI 组件，而是：

✔ 浏览器向“桌面运行时”演进的关键节点

✔ Web App 本地化的基础设施

✔ 多进程安全模型下的能力注入范式

这也是：

Chrome Apps、Electron、WebView2 背后的底层哲学

十一、用一句话总结

WebHostView 并不直接绑定 JS，它提供的是一个“可信 Web 运行时容器”，在该容器创建的 RenderFrame 中，浏览器通过 V8 Extension 动态注入 JS API，再经 Renderer → Browser IPC 桥接，最终让 JavaScript 能够安全地调用操作系统能力。

结尾

当你再看到：

window.desktop.openFile()

请记住：

这不是一个 JS API，
而是一整套浏览器内核级跨进程架构在工作。