Avalonia 实现跨平台开发，核心在于不依赖原生控件，而是用自研渲染引擎统一绘制 UI。它把界面逻辑（XAML + C#）和平台交互层解耦：上层用一套共享代码定义布局、绑定和行为；底层通过抽象的“渲染器”和“平台适配器”，把绘图指令转成各系统能理解的调用——比如在 Windows 走 DirectX，在 macOS 用 Metal，在 Linux 借助 Skia 或 X11/Wayland。这样既避免了各平台控件样式/行为差异，又保证了视觉与交互的一致性。
支持的平台清单（截至2025年12月）
✅ 已正式支持并稳定可用：
Windows（.NET 6+，含 Win10/11 桌面应用） macOS（Intel & Apple Silicon，支持原生菜单栏、拖放等） Linux（主流发行版，支持 X11 和 Wayland 显示协议）✅ 已发布、进入生产就绪阶段：
iOS（通过 .NET MAUI 兼容层或 Avalonia 的原生 iOS 后端） Android（AOT 编译支持，可打包为 APK/AAB） WebAssembly（WASM）：可在浏览器中直接运行桌面级 UI，适合轻量工具或内部管理后台⚠️ 实验性或社区推动中：
嵌入式 Linux（如 Raspberry Pi、ARM64 工控设备，需手动配置 Skia 渲染后端） tvOS / watchOS（暂无官方模板，但底层架构允许扩展）为什么能“一套代码多端跑”？关键设计点
不是简单地“条件编译”，而是从架构上保障一致性：
XAML 是唯一 UI 描述语言：所有平台共用同一份 XAML 文件，不写 #if WINDOWS 这类平台分支 数据绑定完全平台无关：INotifyPropertyChanged、ObservableCollection、CompiledBindings 在所有目标平台表现一致 样式与主题集中管理：通过资源字典定义全局样式，换肤/暗色模式自动同步到所有平台 平台差异由框架内部消化：比如文件对话框、通知、剪贴板等 API，Avalonia 提供统一接口，背后自动调用对应系统的实现实际项目结构怎么组织？
典型 Avalonia 项目采用“共享核心 + 平台启动器”模式：
一个 Class Library 项目：放 Model、ViewModel、业务逻辑、共用服务 多个 Avalonia Application 项目：分别对应 Windows、macOS、Linux 等，只含极少启动代码和平台配置 UI 层（XAML + Code-behind 或 MVVM）全部放在共享库中，被各平台项目引用基本上就这些。不复杂，但容易忽略渲染后端选择和平台特定初始化细节。
