Tauri 依赖操作系统自带的 WebView，在不同平台上底层浏览器的差异是无法回避的现实。理解这些差异，能帮你避免“开发时正常、打包后出问题”的尴尬。
各平台 WebView 内核一览
| 平台 | WebView 组件 | 底层引擎 |
|------|-------------|---------|
| Windows | WebView2（需安装或随应用分发） | Chromium（Edge 同源） |
| macOS | WKWebView（系统内置） | WebKit（Safari 同源） |
| Linux | WebKitGTK（需手动安装或预装） | WebKitGTK（WebKit 的 GTK 移植版） |
主要差异
1. CSS 渲染差异
尽管三者的现代 CSS 支持度都很高，但细微差别依然存在：
- 滚动条样式：Windows 的 WebView2 支持
::-webkit-scrollbar等伪元素，而 macOS 的 WKWebView 在某些版本中忽略或部分支持； - 表单控件：日期选择器、下拉框的默认样式三平台完全不同，且无法纯粹用 CSS 完全统一；
- 字体渲染：Windows 使用 DirectWrite，macOS 使用 Core Text，Linux 使用 FreeType，同一字体显示效果可能有细微区别。
2. JavaScript API 差异
window.open行为：各 WebView 对弹窗拦截、新窗口创建的默认策略不同；- 剪贴板读取：异步剪贴板 API（
navigator.clipboard）在 WebView2 和 WKWebView 中支持较好，但在旧版 WebKitGTK 上可能需要 fallback 到document.execCommand； - 通知权限：
NotificationAPI 在某些 Linux 桌面环境中可能不稳定； - WebRTC / 摄像头访问：Windows 和 macOS 基本没问题，Linux 上依赖 GStreamer，可能需要额外安装编解码器。
3. 自定义协议与安全策略
Tauri 使用自定义协议（如 tauri://）加载前端资源，各 WebView 对 CSP（内容安全策略）和 iframe 沙箱的处理方式不完全一致。例如，内联脚本的权限设置在不同 WebView 中可能需要不同的 CSP 标识。
Tauri 如何缓解这些差异
Tauri 不会把底层差异直接暴露给开发者，它做了不少封装和边界处理：
- 提供统一的 Tauri API（如对话框、文件系统、消息），消除直接调用 WebView 特有 API 的需求；
- 内置的平台检测工具：
tauri::platform::current()和前端@tauri-apps/plugin-os可帮助精确判断平台； - 在多数情况下，你只需遵循标准 Web 开发最佳实践（使用 CSS 前缀、特性检测），不必刻意适配底层引擎。
避坑建议
- 不要依赖仅 Chromium 支持的特性：例如 Chrome 独有 CSS 属性（如
-webkit-app-region: drag，虽然 WebView2 支持，但 WKWebView 不支持）应避免直接使用，而是查找等价方案或使用 Tauri 插件。 - 利用
@supports或 JS 特性检测：比如在 Linux 上使用通知功能前先检查Notification.permission的实际响应。 - 优先使用 Tauri 提供的原生能力：如拖拽、全局快捷键、菜单等，这些完全由 Rust 处理，不受 WebView 差异影响。
- 测试多平台：即使 CI 能交叉编译，也应该至少手动在三个平台上验证实际效果。很多问题只出现在实际 WebView 运行时。
这些差异听起来可能吓人，但实际开发中绝大多数 UI 都是用标准 Web 技术构建的，很少会触碰到引擎特有的边界。只要保持前端代码的兼容性，并在使用平台敏感功能时稍加留意，Tauri 应用的多平台一致性可以维持得很高。