Brownfield Pattern Tauri 如何“最大化兼容现有 Web 项目”

一、Brownfield Pattern 是什么

在软件工程语境里，Brownfield 通常指“在既有系统/既有约束上增量开发”，而不是从零开始推倒重来。对 Tauri 来说，这里的“既有系统”不是传统遗留系统，而是当今浏览器生态的支持与行为：你已经写好的 Web 应用就是“既有资产”。

因此 Brownfield 的核心理念可以用一句话概括：

1. 尽量兼容现有浏览器内的前端项目
2. 尽量不新增前端必须承担的额外要求
3. 把 Tauri 视作一个承载 Web 前端的应用容器，尽量让前端继续像“在浏览器里”那样工作

二、为什么这是默认模式

Brownfield 是最简单、最直观、最符合大多数团队迁移路径的方式：

1. 迁移成本最低
   你可以直接把 React/Vue/Svelte/Vite/Next（静态导出）等前端工程接进来，先把业务跑通，再按需逐步引入 Tauri 特性。
2. 心智负担最小
   大部分前端同学不用立刻学习一整套新范式；只要理解“WebView + IPC + Rust 后端能力”即可。
3. 适合逐步演进
   先 Brownfield 跑起来，再逐步把敏感逻辑下沉到 Core、引入 capability 约束、加强 CSP 与权限治理。

三、它的边界：哪些“浏览器能跑”的不一定开箱即用

Brownfield 追求兼容，但底层依然是系统 WebView，因此你需要对这些差异保持敏感：

1. 平台 WebView 差异
   Windows、macOS、Linux 使用的 WebView 组件不同，某些 API/行为可能与 Chromium 完全一致的浏览器环境有差别。
2. 权限与安全模型不同
   在浏览器里你可能依赖一些默认开放的能力，但在 Tauri 里会被 CSP、capabilities（ACL）、命令允许列表等机制约束。
3. 资源加载与协议差异
   本地资源、路由 fallback、构建产物目录、相对路径等在“静态宿主”模型里更容易暴露问题（尤其是打包后白屏/404）。

工程建议是：把 Brownfield 当作“迁移起点”，不是最终形态。跑通只是第一步，后面要逐步把核心能力治理起来。

四、如何配置（其实不配也行）

因为 Brownfield 就是默认模式，所以不需要额外配置。
如果你希望显式声明（例如团队规范、文档明确、避免未来配置漂移），可以在 tauri.conf.json 里这样写：

{
  "app": {
    "security": {
      "pattern": {
        "use": "brownfield"
      }
    }
  }
}

它没有额外的子配置项：选了 brownfield，就以“尽量兼容现有 Web 行为”为主。

五、什么时候你应该显式写出来

虽然默认就是它，但我建议这两种情况显式写：

1. 团队多人协作，需要在配置层面“锁定默认选择”
2. 你在写技术文档/规范，想让读者明确当前项目运行模式