企业官网建设流程全解析

• 桌面应用
• 开发工具

本篇围绕 MooTool 开源项目（Handy tool set for developers）中独立的 Tauri 桌面产品线 MooTool Next Tauri 的 0.1.0 首个开发预览版展开：它如何与 MooTool Java、MooTool Next Electron 并行共存而不互相干扰，如何用 Rust Core 承载设置、SQLite 数据、网络与进程服务、JSON Vault、备份恢复和签名更新。读完本文，你将掌握该产品线的 25 个正式工具清单、工具 WebView 停靠/分离/状态保持的生命周期设计、JSON Vault 的受限 Git 操作与可恢复删除机制、完整备份 v2 的恢复回滚策略，以及基于next-tauri-v*标签的独立 CI 发布与更新签名流程，并可直接按仓库源码路径深入验证每一项能力。

产品定位：一条独立安装、独立存储、独立更新的桌面产品线

0.1.0 发布说明开篇就明确了产品边界：MooTool Next Tauri 是独立桌面产品线，与 MooTool Java、MooTool Next Electron 独立安装、独立存储、独立演进、独立更新，不替代其他实现。这一设计在仓库中有完整的落地证据：

• 应用标识与产品名独立：next-tauri/src-tauri/tauri.conf.json中identifier为com.rememberber.mootool.next.tauri，productName为MooTool Next Tauri；各产品使用互不相同的 Bundle ID 与应用数据目录，可同时安装。
• 版本号独立演进：0.1.0 版本号同时写入next-tauri/package.json、next-tauri/src-tauri/Cargo.toml与next-tauri/src-tauri/tauri.conf.json，不跟随 Java 的v*标签或 Electron 的版本节奏。
• 更新通道独立：根更新清单update-manifest.json中以products.next-tauri单独登记，updaterManifestUrl指向next-tauri-updater/latest.json；Tauri 客户端只读取自己的节点，不读取 Electron 更新节点（详见下文“更新链路”一节）。
• 发布标签独立：Git 标签使用next-tauri-v{version}，并以 Draft + Pre-release 形式发布，不竞争仓库全局Latest，详见 独立发布手册。

这也意味着：即使电脑上已经装有 MooTool Java 或 MooTool Next Electron，再安装本产品也不会覆盖、干扰它们的数据与窗口设置，从“设置→关于与更新”读到的更新结果也只针对本产品线。

25 个正式工具与 Rust Core 服务层

正式工具清单

发布说明称本版“冻结并交付 25 个正式工具，包括 Host、HTTP、本机代码运行、翻译、图片和 PDF”。在 工具 WebView 管理模块 中，可以找到与发布说明完全一致的PRODUCT_TOOLS数组，25 个工具分别是：

每个工具都作为独立工具 WebView 交付（对应index.html?surface=<tool-id>），在 lib.rs 的 invoke_handler 中可以看到全套 IPC 命令注册，覆盖数据读写、备份、诊断、更新、Vault、WebView 生命周期等能力。

Rust Core 服务矩阵

发布说明强调“Rust Core 提供设置、SQLite 本地数据、网络请求、进程控制、结构化日志、系统诊断、完整备份与恢复”，对应 commands 目录 下按职责拆分的模块：

• 设置：settings.rs+contracts/settings.rs，版本化 Schema（当前SETTINGS_SCHEMA_VERSION = 9）、原子保存、损坏文件保留恢复、单实例设置窗口，并支持主题、强调色、密度、三语言与编辑器默认值的跨 WebView 实时同步。
• SQLite 本地数据：repositories/local_data.rs使用 rusqlite 维护单一mootool-tauri.sqlite3数据库，承载 Quick Note、留言板、Host 档案、翻译单词本/历史、HTTP 收藏/历史、工具收藏、图片资产索引与操作历史。
• 网络请求与进程控制：http.rs、code_runtime.rs、network_tools.rs，HTTP 请求由 Rust 侧发起（支持参数、Header/Cookie、正文类型、1–120 秒超时、重定向、流式进度、响应上限与取消）；代码运行器检测并调用本机 Java、Groovy、Python、Node.js，在禁用 shell 的受控子进程中流式输出并限制时长。
• 结构化日志与诊断：diagnostics.rs按日写入mootool-next-tauri.ndjson前缀的 JSON 日志并保留 14 天，日志文件单文件上限 20 MiB、诊断包上限 100 MiB；导出诊断包时对主机名、Vault 根目录做脱敏，且只复制本产品的日志文件。
• 备份与恢复：backup.rs实现完整备份 v2（详见后文）。

Cargo.toml（next-tauri/src-tauri/Cargo.toml）是 Rust Core 技术栈的缩影：rusqlite（bundled + backup）、reqwest（rustls 通道）、sysinfo（系统快照）、tracing系列（结构化日志）、tauri-plugin-updater（签名更新）、keyring（凭据存储）、xcap（屏幕捕获取色）、vtracer（图片矢量化）等。

Tauri-owned 原生工具 WebView：停靠、分离与状态保持

发布说明指出本版使用“Tauri-owned 原生子 WebView，支持停靠、分离和工具状态保持”。这里的关键是“Tauri-owned”：工具界面由 Rust 侧创建并管理的原生 WebView 承载，而不是普通的前端路由页面。实现集中在 tool_webview.rs。

生命周期命令与安全约束

通过lib.rs注册的 WebView 生命周期命令包括：

• open_tool_webview：在主窗口上以子 WebView 方式创建工具（main.add_child(...)），并禁用自动缩放以便精确控制停靠边界；
• update_tool_webview_bounds/set_tool_webview_visible：停靠态下调整边界、显隐；
• detach_tool_webview：创建tool-detached-<tool>独立窗口，将 WebViewreparent到新窗口并铺满（fill_window），然后显示聚焦；
• dock_tool_webview：将 WebViewreparent回主窗口，销毁分离窗口，恢复停靠边界；
• stress_tool_webview_reparent：对停靠/分离进行 1–500 轮循环压力测试（RC2 说明中提到的“100 轮分离/停靠压力测试”即源于此）；
• close_tool_webview：关闭 WebView 并销毁分离窗口；
• report_tool_webview_session：工具页在会话内上报session_id、state_digest（上限 100 KB）与state_summary（上限 512 字符），用于跨操作状态保持与校验。

安全上，这些命令仅允许主 shell WebView 调用（require_shell校验caller.label() == "main"），工具 WebView 自身无权操控生命周期；停靠边界需通过bounds.validate()校验后才生效。

状态保持与压力验证

RC2 发布说明明确写道：修复已通过 macOS x64/arm64、Windows x64、Linux x64 四平台 CI，每个平台均通过25 工具验收及 100 轮分离/停靠压力测试。该数字与stress_tool_webview_reparent的实现一致：循环内反复执行reparent(detached) → fill_window → reparent(main) → apply_docked_bounds，每轮记录两次 reparent 操作数，并在结束后校验page_loads、session_id与state_digest是否保持稳定——这正是“跨操作状态保持”的可验证依据。

全局操作历史：按设置上限自动裁剪

发布说明称“新增全局操作历史，按用户设置的条数上限自动裁剪”。对应实现：

• IPC 命令集中在 history.rs：record_operation_history、list_operation_history、delete_operation_history、clear_operation_history，写入后通过mootool://operation-history-changed事件通知前端刷新。
• 裁剪逻辑在 local_data.rs 的 record_operation：插入一条操作后，立即执行DELETE FROM operation_history WHERE id NOT IN (SELECT id ... ORDER BY created_at DESC LIMIT ?1)，?1即设置中的history_limit。
• 合法范围在 contracts/settings.rs 中校验为10–5000 条，默认值为 500；备份与恢复等系统级操作同样会以system-data工具 ID 记入历史。

JSON 工作台：独立 Vault、冲突保护、外部变更监控、可恢复删除与受限 Git

这是 0.1.0 中数据安全设计最密集的一块，全部由 Rust 侧实现，核心在 vault.rs 与repositories/vault.rs。

冲突保护与外部变更监控

• 保存采用指纹校验：用户显式选择根目录后，写入settings.vault.root_directory；读写路径全部为相对路径，Rust 会拒绝绝对路径、..路径穿越和符号链接逃逸。
• 保存save_vault_document、移动move_vault_entry、删除delete_vault_document都要求调用方携带expected_fingerprint，若与磁盘当前内容不符则拒绝操作并提示“文件已在 MooTool 之外发生变化，请刷新后再执行”——这就是冲突保护与外部变更监控（配合notify的目录监听去抖通知）。

可恢复删除

删除不会物理移除：delete_vault_document/delete_vault_entry将文件移动到app_data_dir/vault-trash/下，属于可恢复删除（回收式存储），而不是直接销毁。

受限 Git 操作

发布说明强调“受限 Git 操作”。源码确认如下约束（均有单元测试覆盖，见 vault.rs 测试段）：

• 仅暴露init、pull（--ff-only）、commit、push四个固定操作，commit 内部先add --all再commit；
• 不使用 shell，直接以Command::new("git")+ 固定参数执行，并设置GIT_TERMINAL_PROMPT=0、kill_on_drop=true，杜绝参数注入；
• 单次操作超时 120 秒（GIT_TIMEOUT），输出上限 1 MiB，支持按request_id取消；
• 编辑器存在未保存修改时，pull/commit 会被拒绝；仓库存在未提交变更时禁止 pull；
• commit message 仅允许 1–160 字符且不能含换行；remote URL 仅接受https://、http://、ssh://、git://、git@、file://前缀。
• get_vault_git_details提供diff/diff --cached/ 最近 50 条 commit 日志的只读展示，配合--no-ext-diff --no-color避免外部 diff 工具介入。

完整备份 v2：覆盖数据库、设置、图片库与 JSON Vault

发布说明称“完整备份 v2 覆盖独立数据库、设置、图片库和 JSON Vault；恢复前自动创建回滚副本，Vault 导入不会覆盖原外部目录”。实现细节：

• 格式版本：BACKUP_FORMAT_VERSION = 2、BACKUP_PRODUCT_ID = "com.rememberber.mootool.next.tauri"、DATABASE_SCHEMA_VERSION = 11（见 contracts/backup.rs）。备份目录结构为database/、config/、images/、vault/+manifest.json。
• 导出（backup.rs）：数据库用 rusqlite 在线备份接口复制；设置以 JSON 落盘；图片资产从app_data/images按清单复制（单文件上限 20 MiB）；Vault 按相对路径逐文件导出（仅.json、禁符号链接、嵌套不超过 32 层、总文件数不超过 10000）。备份目标不能位于应用数据目录或已配置的 Vault 根目录之内。
• 导入与回滚：导入前先校验 manifest 的 product id、format 版本、settings/database schema 版本，并对备份数据库执行PRAGMA quick_check完整性检查；随后在app_data下建立 staging 目录逐项校验图片字节数与 Vault 条目数；恢复前把当前数据库与设置快照写入restore-rollbacks/restore-{timestamp}/，恢复过程中任一环节失败都会自动回滚数据库、设置、图片目录与 Vault 配置。
• Vault 导入不覆盖原目录：Vault 一律恢复到 Tauri 自有app_data/imported-vaults/restore-{timestamp}/并作为新 Vault 根目录，即使备份来自用户的外部目录也不会写回原位置。导出与恢复都会在操作历史中留下记录。

设置页的 Tauri 专属更新检查：进度、取消、签名验证、安装与重启

发布说明强调“设置页提供 Tauri 专属更新检查、下载进度、取消、签名验证、安装与重启；不会读取 Electron 更新节点”。对应实现见 update.rs。

更新清单解析链路

1. 客户端先拉取仓库根清单update-manifest.json（下载限制 1 MiB），按schemaVersion == 1解析，只读取products.next-tauri；
2. 校验该节点的displayName必须为MooTool Next Tauri、status必须为active（planned视为未激活）；
3. 校验updaterManifestUrl必须等于受信任的next-tauri-updater/latest.json地址，否则报update_manifest_untrusted拒绝；随后用 tauri-plugin-updater 的updater_builder().endpoints([...]).timeout(30s)执行签名校验的版本检查；
4. 结果通过ProductUpdateCheck返回status（available/up_to_date/inactive）、latestVersion、release_notes（单文件 64 KiB，超出按 Unicode 边界截断）、publishedAt（统一序列化为 RFC 3339）与releaseUrl（仅接受next-tauri-v开头的 Release 标签）。

下载、取消、安装与重启

install_product_update通过Channel<ProductUpdateEvent>推送事件流：started → progress → finished → installed，其中 progress 事件字段为chunkLength、downloadedBytes、contentLength（contracts/update.rs中有序列化断言测试）——这正是 RC2 中“修复更新进度事件字段命名，使前端正确接收已下载字节数和总大小”的落点。下载中可随时cancel_product_update（经Notify中止）；下载进行时不允许并发检查或再次下载（update_busy错误）；安装成功后在重启前先落盘窗口状态（flush_window_state），再由relaunch_after_product_update触发应用重启。

独立 CI、四平台安装包与签名发布流水线

发布说明称“独立 CI 生成四平台安装包、更新签名、静态更新清单和发布后提升元数据，并对安装包执行首次启动冒烟”。独立发布手册 给出了完整流程：

• 本地门禁：在next-tauri/目录执行npm ci、npm run check、npm audit --audit-level=high；npm run check覆盖产品边界检查、本地化边界检查、发布边界检查、TypeScript、前端与 Rust 全部测试、生产 Web 构建、Rustfmt 与 Clippy。版本号必须在package.json、Cargo.toml、tauri.conf.json、release-notes/{version}.md四处一致。
• 签名密钥：更新产物必须用产品专属 Tauri updater 私钥签名，私钥以 Secret 方式注入 CI（TAURI_SIGNING_PRIVATE_KEY、TAURI_SIGNING_PRIVATE_KEY_PASSWORD）；仓库中的tauri.conf.json只保存 updater 公钥（pubkey 节点）。更换公钥必须走评审过的密钥轮换方案。
• 发布矩阵与冒烟：对next-tauri-v*标签构建 macOS x64/arm64（DMG）、Windows x64（NSIS）、Linux x64（AppImage/deb），每个平台在上传前做包完整性与首次启动冒烟，Windows 另做静默安装与卸载验证；四平台完成后统一命名安装包，生成latest.json与next-tauri-release.json，再创建/更新独立的 Draft Pre-release。
• 稳定通道提升：Draft 被人工发布为 Pre-release 后，专用提升工作流才验证公开资产、更新latest.json，最后只提交根清单的products.next-tauri节点；发布全程不把 Release 设为仓库级Latest。

0.x 预览版的签名说明与信任警告

发布说明对 0.1.0 预览版的签名状态做了如实声明，这也是评估该版本时的必要前提：

• 所有更新产物都必须通过 Tauri updater 签名；0.x 预览包可能仅使用 macOSad-hoc 签名，或缺少Windows Authenticode签名，因此操作系统可能显示信任警告；
• 正式受信任分发需要配置平台证书与 macOS 公证（Developer ID + notarization），相关 Apple/Windows Secrets 已在发布手册中列明；
• 使用next-tauri-v*标签且不竞争仓库全局Latest；从候选版本演进路径看，0.1.0-rc.1 → 0.1.0-rc.2 → 0.1.0 均在 release-notes 目录中留有完整的中/英/日三语说明，RC2 还包含更新进度字段、RFC 3339 日期、time/serde_with安全升级与 GLib 字符串 Variant 迭代器安全补丁回移等修复。

本地开发与验证入口

如需在本地查看或运行这条产品线，仓库next-tauri/README.md给出如下方式（前置条件：Node.js、Rust stable、Tauri 对应平台的系统依赖）：

npm install npm run dev # 启动 Tauri 开发模式 npm run typecheck # TypeScript 类型检查 npm test # Vitest 前端测试 npm run check # 全量门禁（边界检查 + 测试 + 构建 + Rustfmt + Clippy） npm run build:desktop

更深入的架构依据可继续阅读：产品功能基线、独立产品实现计划、原生桌面体验 ADR、随手记数据模型 ADR、更新清单 ADR、代码签名 ADR、兼容性实测记录 与根目录的 update-manifest.json。

小结

MooTool Next Tauri 0.1.0 的实质不是“又一套 MooTool 皮肤”，而是一次完整的产品线级重构：用 Rust 接管了从设置、SQLite、网络、进程到备份、Vault、诊断、更新的全部核心职责；用 Tauri-owned 原生工具 WebView 统一了 25 个工具的停靠/分离/状态保持体验；用独立的应用 ID、更新清单、Git 标签与签名密钥保证与 Java、Electron 版本互不干扰。无论是评估迁移、对照源码学习 Tauri 2 + Rust 桌面架构，还是在其之上继续开发独立功能，都可以从本文提到的源码路径与发布文档直接切入。

• 桌面应用
• 开发工具