第一次安装，可以先按操作系统和处理器架构选择 Avalonia 桌面版；已经在 Windows 上稳定使用 WPF 版，则不必仅为界面变化而迁移。本文区分界面框架、代理内核与系统接管方式，给出两版的适用范围、依赖检查方法，以及保留原配置进行对照测试的具体顺序。
一、Avalonia 与 WPF 改变的是哪一层
Avalonia 是跨平台的 .NET 用户界面框架，WPF 的全称是 Windows Presentation Foundation，是面向 Windows 的桌面界面框架。放到 v2rayN 中，这两个名称首先描述窗口、列表、菜单与交互的实现方式，不是两种代理协议，也不是两种节点套餐。
v2rayN 负责管理服务器配置、订阅、路由和内核进程；真正处理协议连接的是所选内核。VMess、VLESS 等协议是否可用，需要看节点配置、所选内核及其版本是否匹配。不能看到“Avalonia”就认定节点更快，也不能看到“WPF”就推断它只能连接旧协议。
| 层次 | 负责的事情 | 检查位置或内容 |
|---|---|---|
| 界面框架 | 窗口、字体、菜单、列表操作 | 下载入口中的桌面版或经典 WPF 版 |
| 代理内核 | 协议握手、传输、路由规则执行 | 客户端内核选择、启动日志与内核版本 |
| 节点配置 | 服务器地址、端口、认证与传输参数 | 服务器编辑窗口和订阅导入结果 |
| 流量接管 | 把应用请求送入本地代理 | 系统代理、应用内代理或 TUN 设置 |
例如，浏览器能否通过本地 HTTP 代理访问网页，既取决于内核是否启动，也取决于浏览器是否使用了正确端口。窗口样式变化不会自动修复端口填写错误。排查时先确认属于哪一层，比反复更换界面版本更有效。
二、按平台与使用习惯选择版本
下载顺序建议固定为“操作系统 → 芯片架构 → 界面版本”。Windows 用户可以在两套界面之间选择；macOS、Linux 用户应选择对应平台的 Avalonia 桌面版，不能把 Windows 的 WPF 程序复制过去直接运行。
Avalonia 桌面版
推荐适合作为首次安装的起点。按 Windows、macOS 或 Linux 选择对应发行包，在不同桌面系统上使用相近的配置管理流程；实际可用架构以下载页提供的入口为准。
适合：首次安装、跨系统使用、需要统一操作习惯的用户。
经典 WPF 版
面向 Windows。已经熟悉现有节点列表、托盘菜单和设置位置，且当前安装运行正常时，可以继续沿用；它不是 macOS 或 Linux 的兼容方案。
适合：Windows 上已有稳定配置、希望保留原有操作习惯的用户。
芯片架构也要单独核对。Windows 可在「设置」→「系统」→「系统信息」中查看“系统类型”；macOS 可在苹果菜单的「关于本机」查看芯片；Linux 可用下面的命令查看机器架构。输出 x86_64 通常对应 x64，aarch64 通常对应 ARM64。选错架构时，先更换安装包，而不是调整订阅。
uname -m结论：先解决平台匹配，再比较界面
macOS、Linux 直接选择对应平台的 Avalonia 包；Windows 首次安装先选桌面版，已有稳定 WPF 环境则保留原版，用独立目录测试后再决定是否迁移。
三、界面差异与系统依赖怎样检查
两版的菜单组织、对话框布局、字体渲染以及托盘交互可能不同。熟悉某张教程截图，并不代表另一版缺少同一功能。查找设置时应以功能名称为线索，例如订阅分组、系统代理、本地监听端口和路由设置，不要只按按钮颜色或窗口位置寻找。
安装前检查：Windows 与跨平台环境
Windows：先看发行包的依赖说明
- 区分安装包与解压即用包，压缩包应完整解压，不能只复制主程序。
- 若提示缺少 .NET，记录提示中的运行时名称、主版本与架构。
- WPF 程序可能需要匹配的 .NET Desktop Runtime；普通运行时或开发工具不能一概替代。
- 若包已自带运行时，不要仅因另一版需要依赖，就重复安装一套不相关运行时。
macOS、Linux：再看系统集成条件
- 确认包与芯片架构一致，并按当前发行包说明启动。
- macOS 首次打开遇到系统拦截，先确认文件来源，再检查「系统设置」→「隐私与安全性」。
- Linux 要留意发行版的图形依赖、桌面环境和托盘支持，窗口启动与托盘显示是两件事。
- 系统代理与 TUN 的权限要求不同，不要把启动界面所需条件与网络接管权限混为一谈。
结论：缺什么依赖，应由当前包的说明与具体报错确定，不能仅凭“Avalonia”或“WPF”推断。
如果主窗口能打开，但启动内核立即报错，应先查看日志中的可执行文件路径、权限和端口占用信息。反过来，如果双击后窗口都没有出现，优先检查包是否解压完整、运行时是否匹配。两类故障的排查入口不同，重导订阅通常不能解决界面启动失败。
四、保留配置迁移的具体顺序
两版都能管理订阅，并不等于任意版本之间的配置目录都能直接覆盖。客户端配置中可能包含数据库结构、内核路径和平台相关设置；新版本写入后，旧版本未必能按原样读取。稳妥方法是先保留完整备份，再迁移通用信息，最后核对系统接管设置。
- 记录旧环境。保存客户端版本、内核名称与版本，记录当前服务器、路由模式、监听地址和端口。订阅地址属于敏感信息，备份时不要放进公开截图或共享文档。
- 先备份，再试用。退出旧客户端，确认托盘进程已经结束，再备份它实际使用的配置目录。新包放在另一目录，不要直接覆盖旧程序文件。
- 优先导入通用配置。在新版的「订阅分组」→「订阅分组设置」中核对分组与地址，再执行订阅更新；菜单文字可能随版本调整。手工节点可使用客户端提供的导出与导入功能，避免逐字重填认证参数。
- 核对端口与路由。到「设置」→「参数设置」检查本地监听相关项目，并重新核对路由、DNS 和内核选择。不要假设新安装会自动继承旧版所有开关。
- 只启动一个实例接管网络。先用应用内代理验证本地监听，再从托盘「系统代理」菜单选择「自动配置系统代理」。完成测试后，退出的一版应保持关闭，避免两个进程轮流改写系统设置。
切换完成后，用同一个目标地址验证代理链路。例如将测试请求发往 https://example.com，观察客户端日志是否出现对应请求，再检查路由选择是否符合预期。一个页面能打开只能证明这一条请求成功，不能证明所有应用都已被系统代理或 TUN 接管。
五、速度、内存与功能怎样公平比较
“Avalonia 和 WPF 哪个更快”至少包含两种问题：窗口操作是否流畅，以及代理连接是否稳定。前者与界面渲染、列表规模和桌面环境有关；后者主要受节点线路、内核配置、DNS、路由与网络状况影响。不能用一次网页加载结果给界面框架下结论。
- 固定网络条件：在同一台电脑、同一网络下，使用相同节点、传输配置、内核版本和路由规则，避免把线路变化误认为版本差异。
- 分开记录界面与网络：界面测试记录启动到可操作的时间、筛选节点时是否卡顿；网络测试记录同一目标是否连接成功及相关日志。
- 内存统计包含内核：在任务管理工具中同时观察界面进程与其启动的内核进程。只看主窗口进程，容易遗漏实际资源开销。
- 重复验证：每版可在相同条件下测试 3 次，记录范围而非只挑最好的一次。这里给的是测试次数建议，不是本站性能实测结果。
若只有 TUN 模式失败，而应用内 HTTP 代理正常，优先检查权限、路由与 DNS，不应直接归因于界面框架。系统代理主要影响遵循系统代理设置的应用，TUN 则涉及虚拟网络接口与路由接管，二者不是同一个开关的不同名称。
六、版本选择常见问题
Windows 上 WPF 用得正常，还需要换吗？
不必仅为界面名称迁移。先确认有没有实际需求，例如跨系统使用或某个工作流在桌面版更顺手。需要试用时，备份旧目录并关闭旧实例，再在独立目录启动新版，避免直接覆盖后难以回退。
换成 Avalonia 后，原来的订阅还能用吗？
订阅通常可以重新添加，但导入结果取决于订阅格式与当前版本支持情况。先核对「订阅分组」中的地址，再更新订阅；如果节点数量或字段不同，查看更新日志和节点编辑窗口，不要直接覆盖旧数据库来掩盖导入问题。
新版打开了，为什么浏览器还是无法连接？
先确认已选择活动服务器、内核成功启动，然后核对本地监听端口。若使用示例端口 10808，应用内代理与客户端监听必须一致。最后检查托盘「系统代理」是否为「自动配置系统代理」，并排除另一实例仍在修改系统代理。
看到 .NET 报错，随便装一个运行时可以吗？
应按错误提示匹配运行时种类、主版本与架构。WPF 所需的桌面运行时与普通运行时不能简单视为同一项；先阅读当前包的依赖说明，安装后重新启动客户端，再看原来的错误是否消失。
换界面版能解决 VLESS 节点连接失败吗？
不一定。先比较两边的内核版本、服务器端口、TLS、SNI 和传输参数；若节点使用 Reality，还要核对相应认证参数。只有确认配置相同且问题与具体客户端实现相关，才值得把版本差异作为排查方向。
最终选择可以很朴素：平台和架构匹配，依赖齐全，常用功能正常，原有配置能够安全保留。界面版本是操作入口的选择，连接质量仍要回到内核、节点和本机网络设置逐项确认。