24.5 平台专属功能的设计原则

在开发跨平台桌面应用时，一个常见的困扰是：如何既保持代码复用，又不牺牲各个平台的独特体验？
强行把所有功能做成“跨平台统一”，往往会导致应用在 Windows 上像 macOS，在 macOS 上像 Linux —— 用户会觉得“不对劲”。Tauri 的设计鼓励你优先考虑统一逻辑，但也为平台专属定制预留了清晰的空间。以下是几条实用的设计原则。

原则 1：核心逻辑跨平台，交互层可适配

把业务逻辑、数据处理、网络请求等放在 Rust 内核中，它们天然跨平台。而窗口样式、菜单结构、快捷键、通知文案等交互细节，可以为不同平台单独配置。Tauri 的 tauri.conf.json 支持 platforms 字段，可以为 Windows、macOS、Linux 分别设置窗口装饰、最小尺寸、启动行为等。

// 示例：为 macOS 设置透明标题栏，Windows 设置传统样式
{
  "tauri": {
    "windows": [
      {
        "title": "My App",
        "transparent": true,
        "decorations": false,
        "width": 800,
        "height": 600,
        "platforms": {
          "macos": {
            "transparent": true,
            "titleBarStyle": "Overlay"
          },
          "windows": {
            "transparent": false,
            "decorations": true,
            "titleBarStyle": "Visible"
          }
        }
      }
    ]
  }
}

原则 2：使用条件编译，避免运行时判断

Rust 提供了 #[cfg(target_os = "...")] 条件编译，可以在编译阶段就把平台相关的代码路径确定下来。这比在运行时用 if 判断平台更安全、更高效，且不会把不需要的代码打包进二进制。

// 示例：获取数据目录
#[tauri::command]
fn get_data_dir(app_handle: tauri::AppHandle) -> PathBuf {
    #[cfg(target_os = "windows")]
    {
        // Windows 通常使用 %APPDATA%
        app_handle.path_resolver().app_data_dir().unwrap()
    }
    #[cfg(target_os = "macos")]
    {
        // macOS 使用 ~/Library/Application Support
        app_handle.path_resolver().app_dir().unwrap()
    }
    #[cfg(target_os = "linux")]
    {
        // Linux 遵循 XDG 规范
        app_handle.path_resolver().app_data_dir().unwrap()
    }
}

原则 3：前端用 CSS 和 User Agent 检测，但不要滥用

对于小幅 UI 调整（如字体渲染、间距、阴影），可以在前端使用 CSS 媒体查询或检查 navigator.userAgent。但应避免强依赖 UA 字符串做逻辑分支——更好的做法是让 Tauri 通过 IPC 向前端传递平台信息（例如通过 window.PLATFORM），这比前端自己去嗅探更加可控。

// 更可靠的做法：从 Rust 获取平台标识
import { invoke } from '@tauri-apps/api/tauri';

const platform = await invoke('get_platform'); // 返回 "windows" | "macos" | "linux"
document.body.classList.add(`platform-${platform}`);

原则 4：封装平台 API，提供统一接口

如果你需要使用系统独有的功能（如 Windows 的任务栏快捷方式、macOS 的 Dock 菜单、Linux 的系统托盘指示器），最好在 Rust 端封装成一个平台无关的 trait，然后为不同平台提供实现。这样前端调用时只关心业务逻辑，不关心底层差异。

// 定义一个平台无关的接口
trait SystemIndicator {
    fn show(&self);
    fn hide(&self);
    fn set_tooltip(&self, text: &str);
}

// 在 Windows 上用 Windows API 实现
#[cfg(target_os = "windows")]
struct WindowsIndicator { /* ... */ }

// 在 macOS 上用 NSStatusBar 实现
#[cfg(target_os = "macos")]
struct MacOSIndicator { /* ... */ }

Tauri 的插件系统也遵循这个模式：许多官方插件（如 window-shadows、fs-extra）内部封装了平台差异，对外暴露统一的 API。

原则 5：当平台差异无法调和时，提供“平台独有功能”模块

有些能力确实只能在特定平台实现，比如 Windows 的跳转列表（Jump List）、macOS 的 Touch Bar、Linux 的桌面小组件。这种情况下，不要强行放到主流程里。可以在应用设置中声明“本功能仅限 Windows/macOS”，并在代码中通过条件编译将入口点完全移除非目标平台的构建。用户能理解“某些功能是平台特有”，但无法接受“应用因为平台兼容代码而崩溃”。

总结
平台专属功能不是“无法统一的妥协”，而是提升用户体验的机会。遵循“核心统一、边缘定制”的原则，用条件编译、配置分化和接口封装来管理差异，你就能在保持代码简洁的同时，让应用在每个平台上都“像原生应用一样”。