企业官网建设流程全解析

CLI-Manager 是一款基于Tauri 2 + Rust + React 19构建的跨平台 AI CLI 工作台，运行在 Windows、macOS 和 Linux 上，统一管理本地终端、SSH 远程终端与手机协作会话。本文将带你快速读懂它的前后端分层、四个 Rust 二进制的分工、PTY 守护进程架构，以及如何从零跑起开发环境——一篇看懂这个跨平台终端应用是如何搭起来的。

为什么是 Tauri 2，而不是 Electron？

做桌面终端应用，技术选型的第一问往往是：为什么不用 Electron？CLI-Manager 的答案在 src-tauri/Cargo.toml 里看得很清楚：

对终端类应用来说，PTY（伪终端）生命周期管理必须贴近操作系统：Windows 上要走 ConPTY，Linux/macOS 上要管fork、ioctl、信号处理。CLI-Manager 用 Rust 完成这些重活，前端只负责把终端画出来，职责非常干净。

💡 平台支持现状：Windows（完整测试）、macOS（完整测试）、Linux（实验性支持）。

三层架构：React 19 管界面，Rust 管系统

整个仓库可以拆成三层，各自有独立的构建入口：

┌────────────────────────────────────────────┐ │ 前端层 React 19 + TypeScript 5.8 + Vite 7 │ src/ │ xterm.js 终端渲染 · Zustand · TanStack Query │ ├────────────────────────────────────────────┤ │ 桥接层 Tauri 2 IPC（命令 + 事件） │ @tauri-apps/api ├────────────────────────────────────────────┤ │ 后端层 Rust（src-tauri/） │ │ PTY 会话 · SQLite · Git · SSH · Hook 服务 │ └────────────────────────────────────────────┘

前端（React 19）：入口在 src/main.tsx，用Promise.all并行加载主应用、错误边界、主题与查询客户端；通过 src/vite.config.ts 里的manualChunks把react运行时和@xterm/*终端库拆成独立 vendor 分包，控制首屏体积。

后端（Rust）：应用装配入口在 src-tauri/src/lib.rs，tauri::Builder依次挂载剪贴板、单实例、日志、SQLite 迁移等插件，再于.setup()中完成数据目录迁移、供应商数据库初始化、守护进程拉起。前端可调用的原生能力则集中在 invoke_handler 命令注册表：pty_prepare_create、ssh_test_connection、extensions_mcp_list等上百个命令，就是前端的"系统权限面板"。

构建层（Vite 7）：src/vite.config.ts 固定开发端口 1420 并strictPort，clearScreen: false保证 Rust 编译报错不被 Vite 冲掉——这些细节都是为了让tauri dev的体验稳定。

一个仓库，四个 Rust 二进制：守护进程是关键设计

打开 src-tauri/Cargo.toml 会发现，这个项目不是"一个 app 进程"这么简单，而是显式定义了四个[[bin]]目标：

其中PTY daemon 架构（见 docs/pty-daemon-manual.md）是最值得借鉴的一点：终端会话不在 GUI 进程里跑，而是跑在独立守护进程中。启动时 lib.rs 的 setup 阶段会在后台线程connect_or_spawn拉起 daemon 并把客户端句柄写入共享状态。这带来两个实际收益：

• 任务持久化：关闭应用，Claude Code / Codex 的任务继续跑，重开应用直接恢复连接；
• 进程隔离：终端输出洪峰、崩溃都影响不到 GUI 主窗口。

跨平台差异如何用 Cargo 分层消化？

Rust 侧对三个平台的系统 API 差异，统一用目标平台依赖表达，参考 src-tauri/Cargo.toml 的 target 依赖块：

• cfg(target_os = "macos")：objc2系列 +git2走 vendored 编译（universal 交叉编译需要）+apple-native-keyring-store（Keychain）
• cfg(target_os = "windows")：windows-sys一大组 Win32 feature（管道、COM、网络）+windows-native-keyring-store
• cfg(unix)：nix处理进程/信号/term；Linux 额外用zbus-secret-service-keyring-store对接 Secret Service
• 三平台公共：keyring-core统一凭据存储抽象，SSH 密码、WebDAV 密码各回各家

这种"公共抽象 + 平台适配层"的写法，让 src-tauri/src/features/ 下的 20 个功能模块（terminal、git、ssh、hooks、history、stats……）基本不用关心自己跑在哪个系统上。

Web 端延伸：同一套 Rust 后端驱动第二个前端

Tauri 2 让"桌面 + Web"共用后端变得自然。crates/与apps/目录体现了这一点：

• crates/web-protocol/：前后端共享的通信协议定义
• apps/server/：独立的 Rust Web 服务（含 7 个 SQL 迁移文件），供浏览器访问
• apps/web/：响应式 Web 前端
• apps/web-tap/：移动端优化前端（TAP），支持手机查看会话、审批请求

对应的前端脚本都在 package.json 中：web:dev、tap:build、web:server:run。而桌面主窗口之外，tauri.conf.json 还声明了一个 190×210 的透明无边框 desktop-pet 窗口——用第二窗口做桌面宠物，同样是 Tauri 多窗口能力的直接应用。

开发环境：一键检查、一键构建

项目的开发流在 docs/开发环境与构建流程.md 有完整记录（推荐WSL 开发 + Windows 构建的双机工作流）。核心命令一览：

# 前端类型检查与架构守卫 npx tsc --noEmit node ./scripts/architecture.mjs # 前端逻辑测试（node --test 风格） node --test scripts/*.test.mjs # Rust 检查与测试 cargo check --manifest-path src-tauri/Cargo.toml cargo test --manifest-path src-tauri/Cargo.toml # 本地开发 / 打安装包 npm run tauri # tauri dev（热更新） npm run tauri build # 产物位于 src-tauri/target/release/bundle/

两个容易踩的坑（文档 FAQ 里也强调了）：

1. node_modules不能跨平台共用——esbuild、@swc/core 等平台二进制不同；
2. Windows 安装包只能在 Windows 上构建——需要 MSVC + Windows SDK。

发布侧，tauri.conf.json 配置了tauri-plugin-updater（双端点 + minisign 公钥签名）与 NSIS 安装钩子 src-tauri/installer/hooks.nsh；release profile 开启lto = "fat"、codegen-units = 1和符号剥离，把二进制压到极致。

关键路径速查清单 📌

总结：这套架构能学到什么？

1. 让 Rust 做系统层：PTY、Git、SSH、凭据库全部原生实现，前端只画 UI，安装包体积和性能都受益；
2. 多二进制分工：GUI、PTY daemon、代理、Web 服务各自独立进程，生命周期互不绑架；
3. 目标平台依赖分层：cfg(target_os)把平台差异收敛到 Cargo 声明层，功能代码保持平台无关；
4. 同一后端服务多前端：协议 crate + 独立 Web 服务，让桌面应用平滑长出浏览器和移动端形态。

如果你正在规划自己的跨平台 CLI/终端工具，CLI-Manager 的 src-tauri/ 目录值得一读——它把 Tauri 2 的插件体系、多窗口、资产协议、自动更新都用到了实处，是一份相当完整的参考实现。