Desktop 使用 Avalonia 构建跨平台界面，WPF 是 Windows 桌面界面方案。macOS、Linux 用户选择对应平台的 Desktop 包；Windows 用户按现有配置、操作习惯与所需功能决定。本文重点说明架构识别、界面与内核的边界、配置迁移和切换后的验证步骤，避免把界面框架差异误判成协议能力或网络速度差异。
Desktop 与 WPF 的边界
Avalonia 和 WPF 都是界面框架，不是代理协议，也不是处理网络连接的内核。v2rayN 的服务器列表、订阅分组、设置窗口属于客户端界面；连接能否建立，还取决于实际调用的内核、服务器参数、路由规则和网络环境。界面可以正常打开，不代表内核已经成功启动。
| 比较项 | Desktop（Avalonia） | WPF |
|---|---|---|
| 平台方向 | 面向 Windows、macOS、Linux，需下载对应系统包 | 面向 Windows，不能作为其他系统的原生应用运行 |
| 界面实现 | 跨平台控件与布局，系统集成按平台适配 | Windows 桌面控件与交互体系 |
| 协议能力 | 取决于所用内核及其配置支持 | 同样取决于所用内核及其配置支持 |
| 使用差异 | 需检查托盘、快捷键、窗口缩放及权限行为 | 适合沿用既有 Windows 操作习惯 |
| 配置迁移 | 确认目标发行包的配置格式与功能入口 | 同样不能假定任意版本之间可以直接覆盖配置 |
同样使用 Xray 内核时，不能仅凭窗口样式判断 VLESS、VMess 或 REALITY 的可用性。应查看实际内核版本与服务器所需字段。也不能由“跨平台”推导出更快，或由“Windows 专用”推导出更低延迟；比较速度需要固定服务器、内核、路由和测试条件。
结论：先确定系统，再验证功能
下载前先排除不适用的平台包；下载后用同一个服务器检查订阅更新、代理接管和内核日志。不要为解决服务器握手失败而直接更换界面框架。
Windows 用户怎么选
Windows 是两种界面方案都需要考虑的场景。首次安装可以先试 Desktop；已经在 WPF 上形成稳定工作流的用户，则没有仅为界面名称而迁移的必要。下面的推荐针对首次安装，不表示某一界面在所有设备上都更快或功能必然更多。
Desktop（Avalonia）
推荐首次安装时可作为起点，尤其适合还会在 macOS 或 Linux 上使用 v2rayN 的用户。操作概念便于对应，但托盘和系统代理仍须逐个平台验证。
适合：新装 Windows、需要在多个桌面系统间切换
WPF
现有配置工作正常时可继续使用。若依赖特定快捷键、列表操作或窗口布局，先记录需求，再检查 Desktop 对应发行版是否满足，不必先迁移再找替代入口。
适合：已有稳定配置、依赖既有 Windows 交互习惯
系统架构与运行环境
- 打开 Windows「设置」→「系统」→「系统信息」，查看「系统类型」。x64 与 ARM64 应选对应架构，不要把“64 位”直接等同于 x64。
- 在客户端下载页核对 Windows 包的界面类型、架构和运行环境要求。是否需要另装运行时，以该发行包说明为准。
- 启动后先检查主窗口、托盘图标与退出操作。窗口启动失败时，先排查运行时和架构；窗口能启动但代理不可用时，再查内核日志。
界面程序与内核程序是不同进程。错误包可能在打开窗口之前就失败；内核文件缺失、端口占用或配置字段不兼容，则可能在选择服务器后才暴露。把这两个阶段分开记录，排障会比反复覆盖安装更直接。
macOS 与 Linux 选包
这两个平台应选择对应系统的 Desktop 包。不要把 Windows 的 WPF 包复制过去，再把无法启动解释为订阅失效。系统、CPU 架构和打包方式是三个独立条件，必须分别核对。
平台方案：先识别架构，再检查系统集成
macOS
- 打开苹果菜单→「关于本机」，查看「芯片」或「处理器」。
- Apple Silicon 选择 ARM64 对应包；Intel 设备选择 x64 对应包。
- 启动后检查托盘菜单、系统代理与退出后的代理恢复。
- 涉及 TUN 时，按当前发行版提示处理权限，不把 TUN 当作普通系统代理开关。
Linux
- 在终端执行
uname -m查看机器架构。 x86_64对应 x64，aarch64通常对应 ARM64。- 按发行版选择适用的 deb、rpm 或其他已提供的包格式。
- 检查桌面环境的托盘支持、代理设置以及 TUN 所需权限。
同为 Desktop 不代表各平台系统集成完全相同；先验证日常应用能否使用代理，再按需要配置 TUN。
Linux 中的桌面系统代理通常依赖桌面环境和应用支持。浏览器可能读取该设置，终端程序却可能需要单独设置代理参数。TUN 则涉及虚拟网络接口和路由接管，权限与实现方式不同。没有接管终端流量，不等于 Desktop 的服务器连接功能缺失。
功能覆盖按任务核对
界面名称不能替代功能清单。订阅导入、分组管理、路由配置、内核选择、系统代理和 TUN 应分项验证；不同发行版的菜单布局与功能进度可能不同。下表中的菜单名称用于定位功能，具体位置以已安装版本为准。
| 任务 | 操作位置或字段 | 验收标准 |
|---|---|---|
| 订阅更新 | 「订阅分组」→「订阅分组设置」；执行更新订阅 | 原订阅源能更新，分组与过滤结果符合预期 |
| 本地监听 | 「设置」→「参数设置」，检查本地监听地址和端口 | 内核日志没有地址占用错误，应用连接到实际监听端口 |
| 系统代理 | 主界面或托盘中的「系统代理」菜单 | 系统代理指向客户端实际端口，清除后恢复预期状态 |
| 路由分流 | 「设置」→「路由设置」，核对规则顺序和出站标签 | 需要直连和需要代理的目标按预期匹配 |
| 内核兼容 | 内核选择项与启动日志 | 所需协议、传输和安全参数被实际内核接受 |
| TUN 接管 | TUN 开关、权限提示及相关日志 | 启用后路由正确，停用后网络能够恢复 |
例如，原配置让应用连接 127.0.0.1:10808，迁移后就应核对新实例是否仍监听该端口，以及该端口提供的协议类型。这里的 10808 是检查示例，不是所有发行版的固定默认值。HTTP 代理不能随意指向仅提供 SOCKS 的监听端口；是否支持混合监听，要看实际设置。
- 界面问题：按钮位置、列表列宽、快捷键和缩放表现异常，优先记录界面版本、系统和显示缩放比例。
- 内核问题：日志提示不识别字段或协议，检查所选内核及配置，不要只重置窗口布局。
- 接管问题：内核已运行但应用不走代理，检查系统代理、应用自身代理参数和 TUN，而不是先删除订阅。
迁移配置与回退步骤
迁移的目标是复用订阅与规则，不是把整个旧目录覆盖到新包里。不同版本可能调整数据库或配置结构；目标程序成功读取配置后，也不代表旧程序还能读取修改后的文件。保留独立备份比直接共用配置目录更稳妥。
- 记录当前状态。记下客户端版本、内核类型、本地监听端口、当前路由模式和订阅分组。订阅地址属于敏感信息，不放入公开截图。
- 退出旧实例并备份。先清除系统代理，关闭 TUN，再退出客户端。使用当前版本提供的备份或导出功能；需要复制配置目录时，在程序退出后操作。
- 独立安装目标界面。使用独立程序目录，并按发行版支持的方式保持配置隔离。不要仅凭程序放在不同目录就假定数据一定隔离。
- 分阶段恢复。优先导入订阅并验证一个已知可用服务器，再迁移自定义路由、DNS 和其他设置。不要一次导入全部改动后再猜故障来源。
- 检查端口与接管。确认旧内核已经退出，新实例没有占用冲突。先测试显式代理，再启用系统代理，最后才测试 TUN。
- 保留回退路径。若关键功能不满足，退出新实例并恢复独立备份。不要让旧程序直接读取已被新版本改写且未确认兼容的配置。
普通用户验证可用性时，先只改界面这一项。如果同时更换服务器、内核、DNS 和路由，测试结果就无法说明究竟是哪一处变化起作用。日志中有订阅地址、用户标识或服务器凭据时，分享前应先删去这些内容。
版本选择常见问题
Windows 上已经能用 WPF，还需要换 Desktop 吗？
不必仅为名称更换。先列出实际需求，例如跨桌面系统使用、显示缩放或特定操作入口，再用独立配置测试 Desktop。原有订阅更新、路由和系统代理都稳定时，可以继续沿用现有方案。
Desktop 能打开，为什么服务器还是连不上？
先看内核启动日志，确认是否有端口占用、文件缺失或配置解析错误。再核对服务器地址、端口、传输及安全参数。窗口能打开只证明界面进程启动成功，不能证明内核已建立连接。
换成 Avalonia 后，VLESS 或 VMess 会变快吗？
没有仅由界面框架带来的通用结论。使用同一服务器、同一内核和同一路由测试，并确认没有后台订阅更新或第二个代理进程干扰。若这些条件不同，就不能把结果归因于 Avalonia。
macOS 或 Linux 找不到与 Windows 相同的菜单怎么办？
先确认下载的是对应平台的 Desktop 包，再按“订阅、路由、系统代理、TUN”功能名称查找主窗口、设置窗口与托盘菜单。若当前发行版没有该入口，核对其说明，不要直接照搬其他系统的配置路径。
旧配置导入报错，可以直接覆盖整个目录吗？
先停止覆盖操作并保留备份。尝试只导入订阅，确认基本连接可用后逐项恢复规则。若仍需完整迁移，应先确认源版本与目标版本支持的格式；回退时使用迁移前的独立备份。