Mojo 是 Chromium 专有 IPC 框架，非标准库、不可跨项目使用；仅限 Chromium 源码树内开发，依赖 GN 构建、base::TaskRunner 和 ServiceManager，不提供独立 SDK 或二进制分发。
Mojo 在 C++ 中不是标准库，也不能直接用于通用跨进程通信
Mojo 是 Chromium 项目内部的 IPC 框架，深度耦合于 Blink、Content 和 Browser 进程模型。它不提供独立的 SDK 或稳定 ABI，也没有面向第三方应用的公开文档或发行版支持。如果你在非 Chromium 源码树（比如自己的 Qt/CMake 项目）里试图 #include "mojo/public/cpp/bindings/..."，大概率会失败——头文件找不到、链接器报错、或运行时崩溃。
常见错误现象：fatal error: mojo/public/cpp/bindings/strong_binding.h: No such file or directory；或者编译通过但 mojo::core::Init() 崩溃，因为缺少内部初始化上下文。
- Mojo 的构建依赖于 Chromium 的 GN 构建系统，其头文件路径、宏定义（如
MOJO_CORE_IMPLEMENTATION）、甚至线程模型都和 Chromium 的base::TaskRunner绑定 - 没有跨平台二进制分发机制：你无法通过 vcpkg、conan 或 apt 安装 “Mojo 库”
- 即便硬拷贝 Chromium 的 public/ 目录头文件，也会因缺少
mojo/core/embedder等私有实现而无法链接
想用 Mojo，必须基于 Chromium 源码树开发
只有当你在 Chromium 代码仓库内写新组件（例如扩展一个新的 content::BrowserChildProcessHost 实现，或为某个 RenderFrameHost 添加新接口），Mojo 才是合理选择。此时所有绑定、消息序列化、句柄传递都由 mojo::core 和 content::MojoBindings 自动管理。
使用场景：为 Chrome 浏览器本身添加新能力，比如让 GPU 进程暴露一个新服务给 Renderer 进程调用。
立即学习“C++免费学习笔记（深入）”；
- 接口定义写在
.mojom文件中，用mojo_bindings_generator生成 C++ stub/skeleton - 服务端需注册到
content::ServiceManager或直接绑定到mojo::BinderRegistry - 客户端通过
content::RenderThread::Get()->BindHostReceiver()或类似方式获取远端接口 - 所有跨进程调用自动走
MojoHandle+ 内核管道，无需手动序列化或 socket 管理
替代方案：用更通用、可独立部署的 IPC 方案
如果你只是需要两个独立 C++ 进程之间传结构化数据，Mojo 是过度设计且不可行的。推荐以下实际可用的组合：
-
Unix domain socket + Protocol Buffers：轻量、跨平台（Linux/macOS）、性能好；用
libprotobuf序列化，AF_UNIX传输；避免手写解析逻辑 - Named pipe（Windows） + Cap'n Proto：Windows 上比 socket 更快，Cap’n Proto 零拷贝特性适合高频小消息
-
ZeroMQ + JSON：适合松耦合、多对多场景；
zmq::socket_t封装了连接管理，不用操心重连和队列 - 慎用
Boost.Interprocess：它只适用于共享内存，不能跨机器，且需严格同步生命周期；一旦一个进程崩溃，共享段可能残留脏状态
Mojo 的“跨进程”本质是 Chromium 进程沙箱内的受控通道
Mojo 不解决“任意两进程通信”问题，它解决的是“Chromium 如何安全、高效、类型安全地让 Browser 进程调用 Renderer 进程里的函数”。它的句柄传递、权限检查、沙箱穿透逻辑全部内置在 mojo::core::Channel 和 content::SandboxedProcessLauncherDelegate 中。
容易被忽略的一点：Mojo 接口的生命周期强依赖于 Chromium 的 ServiceManager 生命周期。你不能在一个普通 main() 函数里手动启动 Mojo Core 并期望它长期存活——它没有自己的事件循环，必须挂载到 base::MessagePump 上，而这又要求整个进程已初始化 base::AtExitManager 和 base::TaskScheduler。
