项目是 WinUI 3 + Native AOT 发布，在调试时一切正常，但是发布并启动后几秒内一切正常，过几秒后UI 线程随机无响应，处于“模糊状态”——不是崩溃退出，是卡死没反应。

问题的诡异之处在于：

• Debug 模式下运行正常
• 非 AOT 发布正常
• 去掉 里面的json解析调用后不挂起
• 减少for循环次数，只取前 100 条数据，也不挂起

2. 问题假设​

假设一：JsonElement 在 AOT 下元数据被裁剪​

最初怀疑 System.Text.Json 的 JsonElement 动态访问在 Native AOT 下缺少元数据。但很快被推翻：

同一个 item 上，GetStringProperty 被连续调用了 8 次，每次都涉及 TryGetProperty + GetString + 字符串构造。如果 JsonElement 有元数据问题，第一个 GetStringProperty 就应该崩。

假设二：double 值类型返回引用​

TryGetDouble(out var value) 中的 value 是 double，纯值类型，直接拷贝，不引用 JsonDocument 的内部缓冲区。排除。

假设三：对象初始化器语法​

把 new QuoteData { ... } 拆成先 new 再逐行赋值，仍然会出现挂起现象，因此排除赋值时序。

假设四：ObservableObject 的 PropertyChanged​

QuoteData 继承 ObservableObject，但改成普通自动属性后问题依然存在。排除事件机制。

3. 关键信息​

“随机若干秒后才出现”这个观察是关键。如果崩溃是数据层面的，应该在访问那个对象的瞬间触发。几秒的延迟意味着：

• GC 在几秒后运行
• 回收了某块内存或遍历了某个列表
• 撞上了运行时内部的不一致状态

根据进程卡死的堆栈结构，在 dotnet/runtime 的官方 Issue 中找到了类似的问题记录。

dotnet/runtime #104582：

“正在被遍历的集合进入了坏状态——已释放的条目仍然留在列表中。这是移除操作缺少锁的结果，当终结器运行时，它会与向列表中添加条目的操作产生竞争。”

microsoft-ui-xaml #9928：

“应用能启动，看起来挺流畅，直到 UI 线程完全卡死。死锁发生得非常随机，有时能用几分钟，有时只有几秒，但总是在 GC 等待收集完成时发生。”

问题的完整链条：

1. 你的代码创建 ProductInfo / QuoteData 对象

2. WinUI 3 环境下，这些对象被 CsWinRT 投影为原生对象包装器

3. 包装器注册到运行时的全局追踪器列表

4. UI 线程向列表添加条目，GC 终结器线程从列表移除条目

5. 移除操作缺少锁保护，两个线程同时操作导致列表内部指针损坏

6. 几秒后 GC 再次遍历列表，读到坏指针 → 挂起或访问冲突

   

为什么“去掉某个调用”就“修好”了​

实际上，这不是修复，是降低触发概率。去掉 GetDoubleProperty 或 GetDateTimeProperty 调用，减少了单次遍历期间创建的包装器数量。添加操作的频率降低，与终结器“移除操作”撞上的概率窗口缩小。

同理，只取前 100 条数据、分批处理、本质都是同一个逻辑：降低单次遍历期间的包装器创建密度，避开锁竞争窗口。

4. 解决方法​

如果遇到类似问题，在等待运行时更新期间，可以采用分批处理降低触发概率：将大数组拆成小批次，每批处理完后让 UI 线程让出一次，给 GC 完成遍历的机会。

当然这种只是降低竞争概率。单次耗时在毫秒级，具体取决于消息队列繁忙程度，最好的方法当然还是升级到.NET版本；

这个问题已经修复并合入最新 .NET，遇到类似问题的朋友升级项目.NET版本即可 ：

• 修复提交记录：dotnet/runtime@d7948dc — “Fixes hang in WinUI apps published to AOT (#104583)”
• 目前合入到 .NET 9 分支，.NET 8 用户升级到最新补丁版本后问题应消失

5. 小结​

• 综上来看，这个问题不在你的代码，在 .NET 运行时 AOT 路径下的 ComWrappers 锁竞争
• 同时也与 JSON 解析无关，与“大量创建对象”这个行为有关
• 如果分批处理能规避，也只是降低概率
• 根治需要升级到包含修复的 .NET 运行时版本

参考链接

• dotnet/runtime #104582
• microsoft/microsoft-ui-xaml #9928
• dotnet/runtime 修复提交 d7948dc

本文以拦截 www.abc.com 的 DNS A 查询为例，完整说明如何通过 WFP（Windows Filtering Platform）在传输层拦截 DNS 请求，并返回指定 IP（如 192.168.1.100）。重点讲配置流程和关键决策点，辅以必要的代码片段说明。

整体流程​

整个方案分五步走：

1. 注册 Provider 和 SubLayer，建立自己的"地盘"
2. 注册 Callout，绑定回调函数
3. 添加过滤条件，只抓 UDP 53 端口的包
4. 在回调里解析 DNS 请求，匹配域名后构造响应并注入
5. 卸载时反序清理所有资源

第一步：创建 Provider 和 SubLayer​

Provider 相当于"谁注册的规则"，SubLayer 则是给同一 Provider 下的过滤器排优先级。两者都是后续注册 Filter 和 Callout 的前置依赖。

创建 SubLayer 时，weight 值直接决定了我们的过滤器在同一个层里的优先级。设置为 0x7FFF 这样一个较高的值，可以确保我们的过滤规则在系统默认规则之前被评估，避免被 Windows 防火墙或其他第三方软件抢先处理。

这一步调用两个 API：FwpmProviderAdd 和 FwpmSubLayerAdd。

第二步：注册 Callout​

Callout 是 WFP 留给开发者注入自定义逻辑的"钩子"。

这里需要做两件事：

1. 内核注册（FwpsCalloutRegister）：把 classifyFn、notifyFn、flowDeleteFn 三个回调函数绑定到 Callout 上。classifyFn 是核心，每个匹配的包都会进来；notifyFn 处理 Callout 的生命周期事件；flowDeleteFn 用于清理流上下文。
2. 管理层注册（FwpmCalloutAdd）：在过滤引擎的管理层注册这个 Callout，并指定它挂载的层。这里选择 FWPM_LAYER_OUTBOUND_TRANSPORT_V4。

为什么选传输层而不选网络层？因为网络层（IPPACKET）虽然也能解析到 UDP 端口，但呈现的是完整的 IP 包，可能包含分片，需要自己处理分片重组。而传输层拿到的已经是分片重组后的完整 UDP 数据报，且能关联到进程信息，过滤条件更丰富，实现起来更省事。

第三步：添加过滤条件​

Callout 注册完还不会自动生效，必须添加一个 Filter 把它"激活"。

Filter 的核心是一组条件（Conditions）加上一个动作（Action）。我们需要两个条件：

• 协议必须是 UDP（FWPM_CONDITION_IP_PROTOCOL == IPPROTO_UDP）
• 目的端口必须是 53（FWPM_CONDITION_IP_REMOTE_PORT == 53）

动作设置为 FWP_ACTION_CALLOUT_TERMINATING，意思是：一旦匹配这两个条件，立即终止后续过滤器的处理，把包交给我们的 Callout。这样既保证了性能，也避免了和其他过滤器的冲突。

这一步调用 FwpmFilterAdd。

第四步：准备注入资源​

伪造的 DNS 响应需要重新注入回网络栈，这需要两个基础设施：

1. NET_BUFFER_LIST 池（NdisAllocateNetBufferListPool）：用于分配存放伪造数据包的内存结构。池化分配比每次都从零分配效率更高，对性能敏感的网络处理场景很重要。
2. 注入句柄（FwpsInjectionHandleCreate）：创建一个传输层的注入句柄。这里选择 FWPS_INJECTION_TYPE_TRANSPORT，因为我们的伪造包是构造好的 UDP 数据，需要从传输层注入。之后调用 FwpsInjectTransportReceiveAsync 异步注入时就用这个句柄。

这两个资源在初始化阶段一次性准备好，避免每次注入时重复创建开销。

第五步：回调函数里做什么​

当 DNS 请求命中过滤条件后，classifyFn 回调被调用。这个回调的函数原型是：

typedef void (NTAPI *FWPS_CALLOUT_CLASSIFY_FN2)(
    _In_ const FWPS_INCOMING_VALUES0* nFixedValues,
    _In_ const FWPS_INCOMING_METADATA_VALUES0* inMetaValues,
    _Inout_opt_ void* layerData,
    _In_opt_ const void* classifyContext,
    _In_ const FWPS_FILTER2* filter,
    _In_ UINT64 flowContext,
    _Inout_ FWPS_CLASSIFY_OUT0* classifyOut);

整个处理流程如下：

5.1 提取包信息​

从 inFixedValues 中取出远程地址、本地地址、端口、网卡索引等字段。对于 OUTBOUND_TRANSPORT_V4 层，可用的字段包括：

• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_IP_REMOTE_ADDRESS：目的 IP
• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_IP_LOCAL_ADDRESS：源 IP
• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_IP_REMOTE_PORT：目的端口
• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_IP_LOCAL_PORT：源端口
• FWPS_FIELD_OUTBOUND_TRANSPORT_V4_INTERFACE_INDEX：网卡索引

这些信息在后续构造响应包时需要用到，特别是网卡索引关系到包从哪个网卡注入回去。

5.2 提取并解析 DNS 请求​

在 classifyFn 回调中，layerData 指向的是 NET_BUFFER_LIST 结构。通过 NdisGetDataBuffer 可以提取出完整的 UDP 数据报：

• UDP 头固定占 8 字节（源端口 2 字节 + 目的端口 2 字节 + 长度 2 字节 + 校验和 2 字节）
• UDP 头后面紧跟着 DNS 消息

DNS 请求（QR=0）的格式如下：

DNS Query (www.abc.com, A record)

                                     1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                     |   事务ID（与响应匹配）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD| RCODE   |   QR=0 表示查询
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |   查询区段数量（=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |   回答区段数量（=0）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |   授权区段数量（=0）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |   附加区段数量（=0）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /   域名（www.abc.com）
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QTYPE                      |   查询类型（A=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QCLASS                     |   查询类（IN=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

QNAME 部分的编码方式是：每个标签以长度字节开头，后跟标签内容，最后以 0x00 结束。例如 www.abc.com 编码为：

先检查 DNS 头的 QR 位（第 3 字节的最高位）——如果是 1 表示这是 DNS 响应，直接跳过；只有 QR=0 的查询才需要处理。

然后解析 DNS 的 Question 区，提取出查询的域名。对于 www.abc.com 这样的域名，通过 RuleManagerMatch 判断是否匹配规则列表。

5.3 检查查询类型并构造响应​

从 Question 区末尾取出 QTYPE（查询类型），判断是 A 记录（IPv4，QTYPE=1）还是 AAAA 记录（IPv6，QTYPE=28）。

收到 A 记录查询后，构造一个包含 192.168.1.100 的响应。需要在原请求基础上做以下修改：

修改 DNS 头：

DNS 响应（QR=1）的格式如下：

DNS Response (www.abc.com -> 192.168.1.100)

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      ID                     |   与请求的事务ID一致
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD| RCODE   |   QR=1, AA=1
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |   查询区段数量（=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |   回答区段数量（=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |   授权区段数量（=0）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |   附加区段数量（=0）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /   原样回显查询的域名
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QTYPE                      |   原样回显（A=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QCLASS                     |   原样回显（IN=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     NAME                      /   响应区：原样回显域名
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    TYPE                       |   类型（A=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    CLASS                      |   类（IN=1）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    TTL                        |   生存时间（如 300 秒）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    RDLENGTH                   |   数据长度（IPv4=4）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    RDATA                      |   192.168.1.100（4字节）
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

RDATA 区存放 IP 地址，192.168.1.100 按网络序（大端）写为 C0 A8 01 64。

构造时需要在原请求的 DNS 头上做修改：翻转 QR 位，设置响应标志，填充 Answer 区。同时还要在数据前面封装 8 字节的 UDP 头，因为注入时要从传输层出发。

5.4 封装 IP 头并注入​

构造好的 DNS 响应还需要在前面加上 UDP 头才能从传输层注入：

UDP Header（8 字节）

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |           源端口（DNS服务器=53）              |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |           目的端口（客户端端口）              |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |              UDP长度                          |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |             UDP校验和                         |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                 DNS响应（上面整段）            |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

然后用 FwpsConstructIpHeaderForTransportPacket0 在 NBL 前面封装 IP 头：

    status = FwpsConstructIpHeaderForTransportPacket0(
        pInjectNbl,          // 包含 UDP+DNS 数据的 NBL
        0,                   // headerIncludeHeaderLength
        AF_INET,             // IPv4
        (UCHAR*)&srcIp,      // 源 IP（DNS 服务器地址）
        (UCHAR*)&dstIp,      // 目的 IP（客户端地址）
        IPPROTO_UDP,         // 协议类型
        0,                   // endpointHandle
        NULL,                // controlData
        0,                   // controlDataLength
        0,                   // flags
        NULL,                // reserved
        interfaceIndex,      // 网卡索引
        subInterfaceIndex    // 子网卡索引
);

封装完成后调用 FwpsInjectTransportReceiveAsync 异步注入。注入完成后的回调里负责释放 NBL 和之前分配的 DNS 响应数据内存。

5.5 阻止原始包​

最后一步很重要：必须把 classifyOut->actionType 设置为 FWP_ACTION_BLOCK，同时设置 FWPS_CLASSIFY_OUT_FLAG_ABSORB 标志。

如果不阻止原始包，真实的 DNS 响应回来后会和伪造包冲突，导致应用程序拿到错误的 IP。设置这个标志后，WFP 会丢弃原始请求，只有伪造的响应包到达应用层。

第六步：清理动作​

卸载驱动时，资源的释放顺序必须和初始化顺序严格相反：

1. 删除 Filter（FwpmFilterDeleteById）
2. 删除用户态 Callout（FwpmCalloutDeleteByKey）
3. 注销内核 Callout（FwpsCalloutUnregisterByKey）
4. 删除 SubLayer（FwpmSubLayerDeleteByKey）
5. 删除 Provider（FwpmProviderDeleteByKey）
6. 释放 NBL 池（NdisFreeNetBufferListPool）
7. 销毁注入句柄（FwpsInjectionHandleDestroy）

任何一个步骤失败都可能导致资源泄漏，所以需要用状态标志记录是否有失败，但不建议因为某个步骤失败就停止后续清理，否则泄漏更严重。

关键决策点总结​

注意事项​

1. 异步注入：注入用异步接口，需要正确实现完成回调，在回调里释放 NBL 和响应数据，否则内存泄漏。
2. MDL 生命周期：IoAllocateMdl 分配的 MDL 在注入完成后要释放，时机在完成回调里。
3. NBL 所有权：FwpsInjectTransportReceiveAsync 调用后，NBL 的所有权转移给 WFP，不能手动释放。但 DNS 响应数据（completionContext）需要自己在完成回调里释放。
4. 内存分配：构造 DNS 响应数据时用 NonPagedPoolNx 而非 NonPagedPool。一方面，classifyFn 回调可能在 DISPATCH_LEVEL 下执行，在该级别只能访问非分页内存；另一方面，NonPagedPoolNx 额外标记了不可执行（NX），这是微软推荐的安全做法，能防止缓冲区溢出后执行恶意代码。
5. 只拦截 UDP：TCP 的 DNS 请求（DoH、DoT）不经过这个过滤逻辑，需要额外的层来处理。

• 如果您有 Windows 网络过滤、流量拦截、IP重定向等相关功能需求，欢迎随时咨询合作。

这篇文章不讲复杂的 API 细节，只希望用最通俗的方式，把“WFP 是什么、能干什么、内部怎么回事”讲明白。

WFP 到底是干嘛的？​

一句话概括：WFP 是 Windows 内核网络协议栈里的一个“万能插线板”。

它把网络数据流经的各个关键节点都预留了“插孔”（也就是过滤层），你可以把自己的处理逻辑（“插头”）插上去，实现对网络流量的拦截、检查、修改和放行/丢弃控制。

Windows 自带的防火墙，就是微软自己在这些“插孔”上插的“插头”。杀毒软件、家长控制、流量监控软件用的也是这套东西。

为什么要用 WFP？​

在 WFP 出现之前，做网络过滤有几种老办法，比如 TDI 过滤、NDIS 中间层驱动、Winsock LSP 等等。这些技术各有各的问题：

• 有的只能管到某一段，没法全程控制；
• 有的不兼容 IPv6 等新协议；
• 有的和系统更新经常打架。

WFP 最大的价值，就是把 Windows 网络过滤这件事统一、标准化了。从 Vista/Server 2008 开始，它成了新一代防火墙和网络处理程序的基石。

WFP 的“四大件”​

WFP 的体系结构大致可以理解为四个角色在分工协作：

1. 垫片（Shims）：贴身的“情报员”

这是嵌入在系统 TCP/IP 协议栈各层的内核模块，它们负责把经过的数据拦截下来，包装成 WFP 能理解的格式，然后交给过滤引擎做判断。

不同的垫片负责不同层次的流量，比如负责应用程序连接的 ALE 垫片、负责传输层数据的垫片、负责网络层的垫片等。你不用管垫片具体怎么写，它们是 WFP 框架自带的。

2. 过滤引擎（Filter Engine）：核心的“裁判”

这是真正干活的核心。它横跨内核态和用户态，里面分了大概50个内核层和10个用户层，数据在不同阶段会流经不同的层。

每个层内部又有子层（Sub-layer）和过滤器（Filter）。每个过滤器其实就是一条规则，比如“如果数据包的目标端口是 80，就放行”。当数据进来，过滤引擎会按优先级一条条比对规则，给出“允许”或“阻止”的判决。

3. 基本筛选引擎（BFE）：背后的“总调度”

BFE 是一个运行在用户态的系统服务（Base Filtering Engine），是整个 WFP 的管理和控制中心。

它主要干几件事：接收上层应用（比如防火墙管理界面）添加/删除规则的命令；对不同来源的策略做仲裁；把 IPsec 等策略配置分发出去。总之，BFE 负责“下命令”，过滤引擎负责“执行”。

4. 标注（Callouts）：留给开发者的“自定义钩子”

这就是 WFP 最灵活的地方。内置的“允许/阻止”规则不够用？你可以自己写一个标注驱动（Callout Driver），注册一个或多个回调函数（Callout）。

你可以把这个标注挂在任何一个内核层上。当一个数据包匹配了使用该标注的过滤器时，你的 classifyFn 函数就会被调用。在里面你可以做：

• 深度包检测：检查数据内容里有没有病毒特征。
• 数据包修改：比如做 NAT，改写 IP 地址和端口。
• 流修改：比如家长控制，替换或移除数据流里的敏感词。
• 日志记录：记录所有被拦截的流量。

有了 Callout，WFP 就不再只是一个“开关”，而是变成了一个可以深度编程的网络处理平台。

WFP 是怎么分层的？​

WFP 的分层是和 TCP/IP 协议栈对应的，从应用层数据一直到网卡出去的裸包，都有对应的过滤点。下面用发送一个 TCP 数据包的例子简单串一下：

1. 应用层（ALE 层）：应用程序调用 send()，数据刚进内核。ALE_AUTH_CONNECT 层会被触发，这里是“连接授权”阶段，可以拿到进程 PID、程序路径、目的 IP/端口等信息。这是做“应用程序防火墙”最关键的层。
2. 传输层（TRANSPORT 层）：TCP 包已经生成，但还没分片。在 OUTBOUND_TRANSPORT_V4 层可以拿到完整的 TCP 头和负载数据。
3. 网络层（IPPACKET 层）：IP 包已经封装好，可能已经被分片了。在 OUTBOUND_IPPACKET_V4 层可以拿到 IP 头。这一层已经没有进程信息了，适合做 IP 级的过滤和 VPN 隧道封装。

如果数据是从网卡收上来的，顺序正好反过来，从 INBOUND_IPPACKET_V4 → INBOUND_TRANSPORT_V4 → ALE_AUTH_RECV_ACCEPT，一路向上。

使用时怎么选层？​

不同的开发目标，选不同的层，以下整理了常用的分层处理类别：

小结​

WFP 是 Windows 下做网络过滤的“正路”。它把网络协议栈的关键节点都开放出来，让你能用标准化的方式去拦截和处理流量。

虽然写标注驱动还是要啃 WDK 文档，但理解 WFP 这个“插线板”模型，基本概念就清晰了：数据在协议栈里跑，经过一个个“插孔”（层），你的“插头”（Callout）就在那里干活，告诉系统这个包是放行、丢弃、还是修改。

今天咱们聊一个反常识的骚操作。在你以往的认知里，是不是觉得：两台电脑拿网线直连，想互通？那必须得设成同一个网段啊！（比如192.168.1.x 和 192.168.1.y）

没错，这是“政治正确”的做法。但生活嘛，总有那么些“逆反”时刻：

• 比如你手头这台PC是固定IP（10.10.10.5），另一台是自动获取的（192.168.1.3），你就是不想改来改去。
• 比如你就是单纯想测试一下三层转发，不想搭复杂的路由器。
• 再比如，你就想气气那些说“必须同网段”的老学究。

今天，我就带你打破这个魔咒。两台PC直连，即使IP不在一个网段，照样能ping通！ 而且不需要额外的路由器，全靠Windows自带的“软路由”功能。

第一步：硬件连线（这步要是不会，建议直接退网）

找一根交叉线？大错特错！ 那是上古时期（2000年）的规矩了。

现在随便找根普通的直通网线，一头捅进PC-A的网口，另一头捅进PC-B的网口。插上之后，你会看到网口的小灯“bling bling”闪起来，说明物理链路已经准备好了。

第二步：配置双方的“身份证”（IP地址）

咱们得定两个“派别”：

• PC-A（甲方）： IP设为 192.168.1.3，子网掩码 255.255.255.0

• PC-B（乙方）： IP设为 10.10.10.5，子网掩码 255.255.255.0

注意看！ 一个192.168.1.x网段，一个10.10.10.x网段。如果按常规操作，这时候你在A电脑上ping 10.10.10.5，系统会告诉你：“目标不可达”，因为系统觉得这俩货根本不熟。

重点来了，怎么让他们“破冰”认识？

第三步：给电脑开启“上帝视角”（添加静态路由）

既然A和B不认识，那我们就在它们的大脑里强行画一张地图——告诉它们：去找对方的时候，走“直连”这条路，别去问网关！

在 PC-A（192.168.1.10）上操作：

打开命令提示符（CMD），输入以下“咒语”：

route add 10.10.10.0 mask 255.255.255.0 192.168.1.3

翻译成人话： “A同学，以后只要是想找10.10.10.x的人，不用问别人，你自己就是带路的，直接从你这张网卡发出去就行！”

在 PC-B（10.10.10.5）上操作：

同样打开CMD，输入对应的“回礼”：

route add 192.168.1.0 mask 255.255.255.0 10.10.10.5

翻译成人话： “B同学，以后找192.168.1.x的人，你也别怂，直接从你网卡扔出去！”

第四步：见证奇迹（并且永久保存）

现在，你再在A上ping一下B：

ping 10.10.10.5

Duang！ 你会看到 来自 10.10.10.5的回复：字节=32 时间<1ms TTL=128。

通了！完全通了！这时候你可以共享文件夹、传大文件、甚至联机打红警，一点毛病没有。

⚠️ 温馨提示（防坑指南）

1. 重启会失效： 上面加的 route add 只是临时的，电脑一重启就没了。如果想永久生效，请把命令改成 route -p add（Windows）。
2. 关闭防火墙！关闭防火墙！关闭防火墙！ 重要的事情说三遍。Windows自带的防火墙默认允许同网段的ICMP（ping包），拒绝来自不同子网的ICMP（ping包），如果不关，你上面折腾半天，它照样给你回“请求超时”。建议直接关掉域防火墙和专用防火墙测试。
3. 子网掩码写大一点： 如果你想把整个网段都指过去，掩码用 255.255.255.0；如果你只想让这一台机器通，可以把掩码写成 255.255.255.255（主机路由），精确制导。

写在最后

怎么样？是不是感觉打开了新世界的大门？

这招在服务器割接临时过渡、没有交换机的小组内网、或者纯粹想秀一把技术的时候，简直不要太好用。

记住： 技术是死的，人是活的。谁说直连就必须同网段？只要路由指得对，天涯海角都给你ping通！

好了，不说了，我去拿这个忽悠隔壁工位的产品经理了。兄弟们，快去试试吧，回来报个到！

如果没通，请检查第三步的IP有没有抄错，或者防火墙是不是又偷偷更新开了。 拜了个拜！👋

以下配置基于两台 Windows 设备，节点 A 拥有公网 IP（或已配置端口映射），作为“中心节点”等待连接；节点 B 处于内网，主动连接节点 A，实现两者互通。配置的核心逻辑是：A 负责“等待连接”，B 负责“找到 A”，这里的“等待连接”并非真正建立连接，而是B通过主动发送数据包并建立保活机制来维持二者之间的数据通道，当B主动发送数据包给A时，B也会在路由器公网端留下自己的外部端口，这样A也可以反向给B回应数据。

1. 前期准备：安装与生成密钥​

1-1. 两台 Windows 设备：节点 A（有公网 IP）、节点 B（在内网，能上网就行）。

1-2. 安装 WireGuard 客户端：目前官网被屏蔽，从国内一些软件网站上可以找到，但是要注意保证只在国内使用，比如从家里到公司这种，否则涉及跨境转发同样会被屏蔽。

1-3. 确认 A 的端口可达：A 上要放行一个 UDP 端口（比如6000），需要在 Windows 防火墙中添加入站规则。如果 A 前面还有路由器，需要在路由器上做端口映射，把公网 IP 的6000 映射到 A 的内网 IP。

1-4. 准备记录公钥：配置过程中需要互相复制对方的公钥，建议提前打开记事本备用。

2. 配置节点 A（公网节点）​

节点 A 的核心作用是监听一个公网可达的 UDP 端口，等待 B 来连接。同时给自己分配一个虚拟 IP，用于后续在虚拟网络中标识自己。

编辑配置文件：在A WireGuard 主界面选择节点隧道，点击“编辑”，添加内容如下，

其中Public Key和Privacy Key是自动生成的密钥对，我们只需配置监听端口和自身虚拟地址即可；

Address 指定了节点 A 在虚拟网络内的 IP；ListenPort 是 A 监听的端口，需要确保此端口在 Windows 防火墙及路由器（如有）中放行。

保存完成后的形式如下，这里配置尚未结束，待会还要添加节点B的公钥。

3. 配置节点 B（客户端节点）​

节点 B 作为主动发起连接的设备，需要知道自己要连接谁以及自己的虚拟 IP。

编辑配置文件：同样在 WireGuard 主界面选择节点 B 的隧道，点击“编辑”，添加内容如下：

其中，PrivateKye和PublicKey是自动生成的，Address是自己设置的；

4. 添加对方到自己的Peer中​

前面A 和 B都有了自己的密钥对，接下来需要把他们添加到对方的Public Key到自己的Peer列表中，添加后的形式如下：

节点A：

节点B：

节点B作为连接主动发起端，下面添加了两项额外配置，Endpoint和PersistentKeepalive；

Endpoint 填写节点 A 的公网 IP 和监听端口；

AllowedIPs = 10.10.10.1/24 用于控制Wireguard驱动的出站/入站方向的报文匹配规则；

PersistentKeepalive = 25 确保 B 每隔 25 秒发送保活包，以维持 NAT 映射，让 A 能主动向 B 发送数据。

5. 启动并验证连接​

启动顺序：先连接节点 A（公网节点），再连接节点 B。

验证方法：在节点A和节点B上分别ping对方的虚拟ip，可以正常通；

什么是HTTP共享？​

HTTP共享是小烨远控提供的一键式文件分享功能。当您启动服务后，可以在映射列表中添加文件，其他人就能通过您生成的HTTP链接，轻松访问您所共享的文件。

适用场景广泛：无论是在家庭、办公室的局域网，还是通过小烨远控构建的虚拟子网，甚至是在更广泛的网络环境下，您都可以快速实现文件分享。

如何使用HTTP共享？​

整个流程设计得非常直观，几步即可完成：

1. 运行小烨远控App​

启动小烨远控App，进入HTTP共享功能首页。默认情况下，服务处于停止状态，界面清晰简洁。

2. 启动服务​

点击上方的 “启动” 按钮，服务启动完成后，您将看到服务正在运行的指示状态，表示已经准备好接收文件映射。

3. 添加文件进行分享​

您可以通过两种方式添加要分享的文件或目录：

• 直接拖拽：将文件或文件夹直接拖拽到Uri映射表区域
• 手动添加：点击 “添加文件” 或 “添加目录” 按钮，在文件管理器窗口中选择

您可以根据需要灵活添加多个文件或整个文件夹，构建自己的分享列表。

4. 在浏览器中查看​

添加完成后，点击 “浏览器打开” 操作，您将看到一个基本的文件共享列表页面。

局域网访问：如果另一台设备和您的设备处于同一局域网，只需在浏览器中输入 http://<您的局域网IP> 即可访问并下载文件。

5. 在子网或公共网络分享​

您可能还想通过其他网络环境访问共享文件，小烨远控为您提供了更灵活的方案：

1. 登录账号：请先点击左上角头像，登录小烨通行者账号
2. 开启子网/外网：登录完成后返回HTTP共享页面，点击 “子网/外网” 的开启按钮
3. 获取访问链接：开启完毕后，您将会看到两种链接：

• 子网Uri：使用同一小烨通行者账号登录的两台设备，或者加入同一网络组的两台设备之间可以相互访问，非常适合团队协作或多设备间同步
• 外网Uri：您可以在其他任意设备或手机上访问此链接（如果访问不通，稍等几秒刷新重试即可）

温馨提示​

为了您的数据安全，不需要分享的时候请及时关闭相关功能。小烨远控始终将您的隐私和安全放在首位。

版本寄语​

小烨远控3.0.5的HTTP共享功能，旨在为您提供一种简单、灵活、安全的文件分享方式。无论您是在家庭局域网中与家人共享照片，还是在办公环境中与同事协作传输文档，亦或是通过子网/外网功能实现更灵活的访问，HTTP共享都能让整个过程变得更加轻松高效。

小烨远控3.0.5 现已开放下载，欢迎访问官方网站或应用商店更新至最新版本，体验全新的HTTP共享功能！

在微服务和云原生架构大行其道的今天，服务之间的通信效率成为系统性能的关键瓶颈。你是否还在为REST API的低效序列化而烦恼？是否在寻找一种既能跨语言又能保持高性能的通信方案？今天，跟随作者一起来认识gRPC，以及.NET生态如何完美支持这一现代RPC框架。

如果你对gRPC的概念有所了解，可以直接跳入第3章节；如果你对gRPC已经完全熟练掌握，那就可以完全跳过本文^=^

一、什么是gRPC？为何它如此重要？​

gRPC是由Google开源的高性能远程过程调用框架，它基于HTTP/2协议，使用Protocol Buffers（protobuf）作为接口定义语言和数据序列化格式。

gRPC的几个核心优势：

• 高性能：使用protobuf二进制序列化，相比JSON体积更小、速度更快
• 多语言支持：支持C++、Java、Python、Go、C#等多种语言
• 双向流式通信：基于HTTP/2，支持客户端、服务端双向流式传输
• 强类型：通过.proto文件明确定义接口，生成强类型代码
• 自动代码生成：提高开发效率，减少手动编写样板代码

gRPC的几种通信模式：

1. 一元RPC：客户端发送单个请求，服务端返回单个响应，这种是最基本最常用的交互，完全可以媲美REST API接口调用；
2. 服务端流式RPC：客户端发送请求，服务端返回流式响应
3. 客户端流式RPC：客户端发送流式请求，服务端返回单个响应
4. 双向流式RPC：双方同时发送流式消息

二、.NET对gRPC的支持：成熟且强大​

微软对gRPC的支持可以说是全力投入。从.NET Core 3.0开始，gRPC就成为.NET平台的一等公民。

官方支持情况：

.NET gRPC的技术特点：

• 完全托管实现：基于.NET原生实现，无需依赖C++库
• 与ASP.NET Core无缝集成：共享配置、日志、依赖注入等基础设施
• 性能优异：微软官方基准测试显示，gRPC性能远超传统REST API
• 跨平台支持：Windows、Linux、macOS均可完美运行

三、实战演练：创建完整的gRPC服务与客户端​

接下来跟随作者一块创建一个基本的gRPC示例，包含服务端和客户端。

3.1 环境准备​

• Visual Studio 2022（需安装ASP.NET和Web开发工作负载，如下图所示）
• .NET 6.0 SDK或更高版本

3.2 创建gRPC服务端​

步骤一：创建项目

1. 启动Visual Studio，选择“创建新项目”
2. 搜索“gRPC”，选择“ASP.NET Core gRPC 服务”

1. 项目名称设为GrpcGreeter
2. 选择.NET版本（推荐.NET 8.0或更高）

步骤二：查看项目结构

创建完成后，可以看到以下两个核心文件：

• Protos/greet.proto：定义gRPC服务的接口文件，这里包含了一个请求/响应数据结构，一个接口函数SayHello；

• Services/GreeterService.cs：实现gRPC服务的业务逻辑

步骤三：运行服务端

按F5运行服务，控制台会显示服务监听的地址，如https://localhost:7208。

3.3 创建gRPC客户端​

步骤一：创建控制台应用

1. 另开一个Visual Studio实例
2. 创建“控制台应用”项目，命名GrpcGreeterClient

在客户端控制台项目中添加以下几个NuGet包，作用可以文章开头的描述；

步骤二：添加proto文件

1. 在客户端项目中创建Protos文件夹，把服务端的greet.proto文件复制到该文件夹
2. 修改greet.proto中的命名空间，修改是为了方便区分，不修改也不影响使用；

编辑.csproj文件，将proto文件加入项目编译流程：

尽管微软并未宣布放弃对Web技术或跨平台框架的支持，但在多场关键技术会议中，公司高层反复强调——WinUI已是Windows 11上构建现代化、高性能、AI就绪原生应用的首选框架。

一、从“选项之一”到“生产平台”：微软为何全力押注WinUI？

过去几年，Windows应用生态呈现碎片化：Electron、React Native、Flutter、Tauri……开发者拥有众多选择，但系统体验也因此变得割裂——内存占用高、启动慢、界面风格不统一。

在Build 2026上，微软Windows UI与人工智能副总裁Chris Anderson明确回应了社区最关心的问题：“我们不会构建另一个新框架。WinUI就是Windows应用的生产平台。”

为此，微软甚至去掉了“3”这个版本号，将其简化为“WinUI”，以此承诺：

• 不会进行破坏性重构
• 不会轻易放弃或替换
• 长期稳定投入，适合企业级应用

二、打磨基本功：解决撕裂、内存与控件缺口

过去开发者对WinUI的主要顾虑集中在基础体验和企业控件缺失。而微软本次给出了具体路线图：

“首要任务是提升性能、夯实基础、确保质量，并修复大量缺陷。” —— Chris Anderson

这些改进意味着：WinUI不再只是“演示级”框架，而是真正可以承载金融仪表盘、HR管理工具、计费软件等企业级应用的平台。

三、为AI智能体时代而生：WinUI + AI工作流

微软同时强调了WinUI在AI时代的新定位——原生支持AI智能体工作流。

具体包括：

• 开发人员可利用AI智能体帮助规划、构建和优化WinUI应用
• 支持将遗留应用（WinForms/WPF）智能迁移到WinUI
• 针对AI辅助编程提供更清晰的控制流与更快的迭代体验

换言之，微软并不只是简单地在WinUI上“叠加”AI功能，而是让框架本身为AI驱动的开发流程而优化。

四、开放但不失重点：WinUI与其他框架共存

微软并未“宣战”其他框架。Windows依然是开放平台，React、SwiftUI、Compose等优秀模式会被借鉴。但微软明确希望：当开发者想要构建最佳Windows原生体验时，首先想到WinUI。

为此，微软还提升了WinUI的透明度——几乎全部移到了公共代码仓库，并承诺实现WinForms/WPF与WinUI之间“万无一失”的互操作性，让企业可以渐进式迁移，而非一夜重写。

五、微软内部“Windows回归”的信号

多家外媒在Build 2026后评论：今年是近年来微软谈论Windows原生应用最多的一届大会。

具体证据包括：

• 组建新团队专门负责Windows 11原生应用开发
• 开始将“开始菜单”中的推荐与所有应用列表从React Native重写为原生实现
• 计划用WinUI重写文件资源管理器，以实现全局一致的体验

这些动作表明：Windows在微软内部的战略优先级正在回升，而WinUI正是这一战略的技术底座。

六、携手开发者，共建下一代Windows应用

作为长期关注Windows技术演进的观察者，我们相信一个好框架需要与真实开发场景持续磨合。WinUI正在快速补齐短板，而我们也已经在远程控制、企业办公工具等领域积累了落地经验（参考案例：小烨远控）。

如果您或您的团队正在规划Windows应用开发，或者希望将现有应用现代化迁移至WinUI，欢迎联系我们。我们可以一起评估可行性、设计架构，并利用WinUI的原生性能与AI就绪能力，把产品做得更好。

在微软全力投入WinUI的今天，正是拥抱Windows原生生态的最佳时机。

想象一个最常见的场景：

你在一个输入框里打字，屏幕另一边的文字标签同步变化，不需要你点任何“保存”或“刷新”按钮。

这就是 UI 自动更新。

没有数据绑定的做法​

数据变化的地方越多，这种“手动搬运”的代码就越多。改一个字段漏掉一个地方，界面就会显示不一致。

有数据绑定的做法​

中间两步完全由框架完成。你只需要做一件事：告诉 UI 和数据之间是什么关系。

下图展示了一个可输入文本框和一个展示文字的文本标签，当在文本框输入文字时，文字自动传递给绑定变量，然后又反向绑定到文本标签，实现了实时自动更新。

2. 让 UI 自动更新的两个核心​

2.1 数据绑定：建立连接​

在 XAML 中声明“这个控件的这个属性，等于那个数据的那个属性”。

比如：

<TextBlock Text="{x:Bind 用户姓名}" />

这行代码的意思：这个 TextBlock 显示的内容，永远等于“用户姓名”这个数据。

不需要写任何 C# 代码来赋值。

2.2 INotifyPropertyChanged：发送通知​

这是初学者最容易踩的坑。

普通 C# 属性变化时，WinUI 不会自动感知。你必须让数据类主动说一声“我变了”。

public string 用户姓名 { get; set; }

private string _用户姓名;
public string 用户姓名
{
    get => _用户姓名;
    set
    {
        _用户姓名 = value;
        通知UI我变了();
    }
}

通知的方式有多种：

方式一：原生 INotifyPropertyChanged

继承 INotifyPropertyChanged，实现 OnPropertyChanged 接口，并在绑定变量变化时调用通知接口。

public event PropertyChangedEventHandler PropertyChanged;

private void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
    PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}

方式二：借助 CommunityToolkit.Mvvm

使用现成的 .NET 库来简化通知过程。

3. 基本示例：制作一个简单的应用启动器​

用一个实际项目来串起所有概念。界面很简单：

• GridView 网格展示应用列表（图标 + 名称）
• 点击某个应用后，启动该应用

3.1 项目结构​

这里简化结构，主要包含两大部分：

• ViewModel（视图模型）：包含了数据定义，并负责通知
• MyAppsPage（界面）：XAML，负责显示

3.2 数据模型​

定义每个 App 应用长什么样，主要信息包含：图标、名称、描述。

3.3 视图模型​

这是整个数据绑定的中枢。

这里主要暴露一个应用列表，用 ObservableCollection 类型，这样增删应用时 UI 会自动刷新。

public class AppLauncherViewModel : ObservableObject
{
    public static ObservableCollection<AppInfo> AppItems;
}

3.4 界面 XAML​

核心绑定写法：

3.5 运行效果​

最终运行起来如下所示：

• 界面展示一行应用图标和名称
• 鼠标点击任意应用，启动对应 App

全程没有写任何“点击 → 找控件 → 赋值”的代码。

4. 小结​

如果发现绑定未生效，最可能的原因主要如下：

WinUI 3 的数据绑定，主要就是两件事：

1. 声明关系：XAML 里用绑定语法
2. 发出通知：ViewModel 实现 INotifyPropertyChanged

理解这套关系后，写 UI 就变成“描述数据长什么样”，而不是“搬运数据”。代码量减少，bug 也减少。

背景​

在实际使用远程桌面软件或访问远程设备资源时，我们经常会遇到一个场景：

两个人的不同设备，分别登录了不同的账号，想访问对方网络资源，怎么办？

对专业人员来说，可以考虑搭建VPN/内网穿透等，但对普通用户搭建成本太高，出问题也很难排查维护。

小烨远控 3.0.1 的网络组功能，可以让两个人的异地设备轻松组建到一个网络。

网络组是什么？​

简单说，可以把网络组理解为一个虚拟局域网。

把不同账号下的设备拉进同一个“房间”（网络组），它们就能像在同一个局域网一样互相访问，虚拟IP直连，不需要公网IP，不需要端口映射。

实战：两台设备跨账号组网​

环境准备​

步骤1：创建网络组​

1. 打开小烨远控，登录账户A
2. 左侧菜单：网络组 → 创建网络组
3. 输入名称：MyGroup（只支持字母、数字、下划线）
4. 点击创建

创建成功后，下方列表会显示你创建的网络组。

💡 小技巧：点击“创建并加入”会把当前设备自动加进去，省一步操作。

步骤2：另一账号加入网络组​

1. 在另一台设备上登录账户B
2. 进入 网络组 → 加入网络组
3. 输入前面创建的网络组名称：MyGroup
4. 点击加入

加入成功后，账户B的设备也会出现在网络组中。

步骤3：验证互通​

在网络组界面，每台设备都会显示一个虚拟IP。打开命令行，ping 对方的虚拟IP：

🚀 核心亮点：跨账号网络组​

在过去，使用远程控制软件时，同账号下的设备可以轻松互连，但一旦涉及不同账号，往往需要复杂的配置、中转服务器甚至第三方工具。

现在，小烨远控 3.0.1 彻底解决了这一痛点。

网络组是一个虚拟设备群组，允许您将多个不同账号下的设备加入同一个逻辑组中，实现跨账号直接互通，无需额外配置。

📖 如何使用网络组​

第一步：创建网络组

使用账户 A 登录小烨远控，进入 网络组 → 创建网络组，输入一个名称（如 MyGroup），点击创建即可。

💡 提示：名称仅支持字母、数字和下划线。

创建成功后，您可以选择 “创建并加入”，将当前设备自动加入网络组；也可以稍后通过网络组右侧的 “加入” 按钮手动加入。

第二步：邀请其他账号加入

使用账户 B 登录小烨远控，进入 网络组 → 加入网络组，输入账户 A 创建的网络组名称（如 MyGroup），点击加入即可。

第三步：测试网络互通

加入成功后，两台设备会分别获得一个虚拟 IP 地址。您可以使用 ping 命令测试互通性：

在日常的Windows服务器或工作站管理中，远程桌面（RDP）是我们最常用的工具之一。但很多人可能忽略了一个关键的安全设置——网络级身份验证（NLA）。今天我们就来详细聊聊它的原理、效果对比以及开启建议。

1. 什么是NLA？基本原理与版本支持

网络级身份验证（Network Level Authentication，简称NLA） 是一种在建立完整的远程桌面连接之前，先进行用户身份验证的技术。

基本原理

在没有NLA的传统模式下，当你发起RDP连接时，目标计算机会先为你分配桌面会话资源、加载图形界面、启动登录屏幕，然后你才输入用户名和密码。这类似于你先走进了房间，才被要求出示证件。

而启用NLA后，在连接初期，客户端就必须先将你的身份凭证发送给服务器进行验证。验证通过后，服务器才会开始分配会话资源和加载桌面环境。这相当于在房间门口就设置了门禁，证件不合格连门都进不了。

支持版本

• 服务器端：从 Windows Server 2008 和 Windows Vista 开始正式支持NLA。
• 客户端侧：从 Windows XP SP3 开始支持，但成熟集成在 Windows 7 及更高版本中。

目前主流的Windows 10/11、Windows Server 2016/2019/2022/2025 都完整支持NLA。

2. 开启NLA vs 不开启NLA：效果对比

为了直观理解差异，我将从连接效率、视觉表现和安全风险三个维度进行对比。

2.1未开启NLA时的连接效果：先出现锁屏登录界面，然后才是提示输入用户密码。

2.2 开启NLA时的连接效果：直接出现Windows登录提示窗，输入密码之前不会消耗服务端资源。

服务端强制开启NLA​

系统属性 -> 远程 -> 远程桌面 区域，勾选“仅允许运行使用网络级别身份验证的远程桌面的计算机连接”即为开启NLA，此时就强制开启了NLA。

服务端强制开启“只允许NLA连接”后，对于那些不支持NLA的客户端，连接时将直接报错，避免了会话资源的消耗；

3. 总结：为了安全，强烈建议开启NLA

通过上述对比可以清晰看到，关闭NLA虽然能兼容极老的系统（如Windows 2000、非标准RDP客户端），但它带来的代价是严重的资源浪费和巨大的安全风险。

尤其是在公网或暴露在互联网上的远程桌面服务（强烈不建议直接暴露3389端口，但如果有例外情况），关闭NLA相当于给攻击者留了一条无需验证就能消耗你服务器资源的“后门”。

最终建议

• ✅ 默认策略：在所有支持NLA的操作系统上，务必勾选“仅允许运行使用网络级身份验证的远程桌面的计算机连接”。
• ✅ 兼容问题处理：如果遇到旧版客户端无法连接，可以考虑升级客户端系统，或者在内网隔离环境且部署了防火墙白名单的前提下，个案化关闭NLA，而不是全局关闭。
• ✅ 进一步加固：即使开启了NLA，也建议配合强密码、账户锁定策略或非标准端口（次要手段）使用。

总而言之：开启NLA，用最小的配置成本，获得连接前置身份验证和安全防护的双重收益。这是所有Windows管理员应该遵循的安全最佳实践。

还记得那些年我们用过的WinForm应用吗？灰色的边框、方正的按钮、一成不变的外观。在这个看脸的时代，用户对桌面应用的视觉要求越来越高。而WinUI 3的出现，让.NET开发者终于可以轻松打造出具有现代感的桌面应用。

本文将带你从零开始，用WinUI 3打造一个具有毛玻璃效果、自定义标题栏的现代化应用。最终效果将媲美Windows 11原生应用。

一、为什么选择WinUI 3？​

二、环境准备​

在开始之前，请确保你已经安装了：

• Visual Studio 2022（17.0+）
• .NET 6 SDK 或更高版本
• WinUI 3 项目模板（可通过VS Installer安装）

三、创建项目并启用云母背景​

3.1 创建新项目​

选择“空白应用，打包的 (WinUI 3 Blank App)”模板。

3.2 启用云母材质​

云母（Mica）是Windows 11引入的半透明材质，能根据桌面壁纸动态取色，营造通透感，在Window对象的xaml文件开启即可；

<Window.SystemBackdrop>
    <MicaBackdrop />
</Window.SystemBackdrop>

四、自定义标题栏​

专业应用通常会隐藏默认标题栏，让内容区延伸到顶部。

4.1 修改MainWindow.xaml中自定义个标题栏​

<Grid x:Name="AppTitleBar"
      Height="32"
      VerticalAlignment="Top"
      Background="Orange">
    <TextBlock x:Name="TitleTextBlock"
               Text="My WinUI3"
               Margin="12,0,0,0"
               VerticalAlignment="Center"
               Style="{StaticResource CaptionTextBlockStyle}"/>
</Grid>

4.2 设置标题栏拖拽区域​

在 MainWindow.xaml.cs 初始化时设置扩展区域到标题栏；

public MainWindow()
{
    InitializeComponent();
    this.ExtendsContentIntoTitleBar = true;
    SetTitleBar(AppTitleBar);
}

这样就得到了一个自定义标题栏；

五、核心布局控件实战​

WinUI 3提供了强大的布局控件，掌握它们是构建现代UI的基础。

5.1 Grid——网格布局​

Grid是最常用的布局控件，适合构建复杂界面，如下定义了上下两行布局，第一行做自定义标题栏，第二行做导航栏；

<Grid>
    <Grid.RowDefinitions>
        <!--标题栏内容-->
        <RowDefinition Height="Auto"/>
        <!--导航栏-->
        <RowDefinition Height="*"/>
    </Grid.RowDefinitions>
    <Grid x:Name="AppTitleBar" Grid.Row="0"/>
    <NavigationView x:Name="AppNavPanel" Grid.Row="1" />
</Grid>

5.2 StackPanel——简单堆叠​

StackPanel用于简单的内容堆叠，可以水平或垂直排列，如下定义了一排水平排列按钮；

<StackPanel Grid.Row="1" Orientation="Horizontal" Spacing="8" HorizontalAlignment="Center">
    <Button Content="New" />
    <Button Content="Edit" />
    <Button Content="Delete" />
</StackPanel>

5.3 综合-卡片式列表​

结合Grid和StackPanel，我们可以创建类似Windows 11设置的卡片式界面，如果你想进一步添加滚动条，外层包裹ScrollViewer即可，当ScrollViewer的内容区域超出窗口范围时，会自动添加滚动条，如下所示：

六、总结​

WinUI 3为.NET桌面开发者带来了前所未有的现代UI体验。通过本文的学习，你应该已经掌握了：

✅ 启用云母/亚克力毛玻璃效果

✅ 自定义标题栏，打造专业外观

✅ 使用Grid和StackPanel构建灵活布局

✅ 创建卡片式界面

✅ 响应式窗口适配

相比传统WinForm，WinUI 3既有简单容易上手的一面，也有高级复杂的功能，高级功能虽然复杂，但带来的视觉和用户体验提升是巨大的。如果你想在2026年打造一款让人眼前一亮的桌面应用，WinUI 3是一个不错的选择。

在日常工作中，我们经常需要将本地电脑上的文件拷贝到远程服务器或办公电脑上。传统的做法是通过网络共享、FTP或者云盘中转，但这些方式要么配置复杂，要么速度受限。

今天分享一个 Windows 远程桌面自带却容易被忽视的实用功能——磁盘重定向。配置完成后，你的本地硬盘分区会直接出现在远程桌面的“此电脑”里，拷贝文件就像操作本地电脑一样简单。

操作步骤​

第一步：打开远程桌面连接​

按 Win + R，输入 mstsc，回车打开远程桌面客户端。

第二步：进入本地资源配置​

在远程桌面连接窗口中，点击左下角的 “显示选项”，切换到 “本地资源” 选项卡。

第三步：配置磁盘映射​

在“本地资源”选项卡中，点击 “详细信息” 按钮。

第四步：勾选要映射的驱动器​

在弹出的窗口中，展开 “驱动器” 列表，勾选你希望映射到远程桌面中的本地磁盘分区。

• 勾选 “驱动器” 复选框可以选中所有分区
• 也可以按需单独勾选 C 盘、D 盘等

确认后点击 “确定”。

第五步：连接远程桌面​

正常输入远程电脑的 IP 和凭据，连接到远程桌面。

最终效果​

连接成功后，打开远程桌面窗口中的 “此电脑”，你会看到“重定向的驱动器和文件夹”栏目下，出现了你刚才勾选的本地盘符。

现在，你可以像操作本地文件一样，直接在远程电脑和本地磁盘之间拖拽、复制、粘贴文件，无需任何中转工具。

注意事项

1. 网络和权限限制：某些企业环境下，IT 管理员可能通过组策略禁用了磁盘重定向功能，此时该选项可能不可用或无效。
2. 安全建议：仅在自己信任的远程电脑上使用此功能。在公用或不受信任的远程电脑上勾选此选项，可能导致本地数据泄露。
3. 性能提示：映射的磁盘在远程桌面中读写文件时，实际数据是通过网络传输的，大文件拷贝速度受限于网络带宽。

结语

这个小技巧帮你省去了搭建文件共享、上传云盘等中间环节，尤其是在临时需要传几个文件到服务器时，效率提升非常明显。

如果你也经常使用远程桌面工作，不妨试试这个功能。

任何应用程序都难免会遇到异常——网络断开、文件缺失、空引用、内存不足……关键在于如何优雅地处理这些异常，而不是让应用直接崩溃。

WinUI 3 作为新一代 Windows 桌面应用框架，提供了多层级的异常处理机制。本文将详细介绍 WinUI 3 中常见的异常处理方式，帮助您构建更健壮的应用。

一、异常处理的层次结构​

WinUI 3 应用中的异常可以在不同层级被捕获：

限于篇幅，本文介绍最基本常用的异常处理。

二、Application.Current.UnhandledException​

这是 WinUI 3 应用中最关键的全局异常处理入口。任何未被捕获的异常最终都会到达这里。

基本用法

在 App.xaml.cs 中：

public partial class App : Application {
    public App()   {
        this.InitializeComponent();
        // 订阅全局未处理异常事件
        this.UnhandledException += OnAppUnhandledException;
    }

    private void OnAppUnhandledException(object sender,  Microsoft.UI.Xaml.UnhandledExceptionEventArgs e)  {
        // 标记异常已处理，阻止应用崩溃
        e.Handled = true;

        // 记录异常信息
        LogException(e.Exception, "UnhandledException");

        // 显示友好的错误提示
        ShowErrorDialog("应用遇到了一些问题，已尝试恢复。");
    }
}

关键点说明​

⚠️ 重要提示​

UnhandledException 只能捕获 UI 线程上的异常！ 后台线程、异步任务中的异常需要其他方式处理。

三、TaskScheduler.UnobservedTaskException​

处理 async/await 任务中未被观察到的异常。当 Task 被 GC 回收且异常未被观察时触发。

使用方法​

public App() {
    this.InitializeComponent();
    this.UnhandledException += OnAppUnhandledException;
    // 订阅未观察到的任务异常
    TaskScheduler.UnobservedTaskException += OnTaskUnobservedException;
}

private void OnTaskUnobservedException(object sender, UnobservedTaskExceptionEventArgs e) {
    e.SetObserved();  // 标记异常已被观察
    LogException(e.Exception, "UnobservedTaskException");
    // 可以选择显示提示或记录日志
}

实际场景示例​

// 这样的代码可能会导致 UnobservedTaskException
async Task DangerousMethod() {
    await Task.Run(() => {
        throw new InvalidOperationException("后台操作失败");
    });
}
// 调用但不等待或处理异常
_ = DangerousMethod();  // 异常可能被忽略

最佳实践​

始终使用 try-catch 包裹异步操作，或使用 await + try-catch 正确处理异常。

四、特定场景的异常处理​

文件 I/O 操作​

private async Task LoadFileAsync(string filePath) {
    try   {
        var file = await StorageFile.GetFileFromPathAsync(filePath);
        var content = await FileIO.ReadTextAsync(file);
        // 处理文件内容...
    }

    catch (FileNotFoundException ex)   {
        await ShowErrorDialog($"文件不存在: {filePath}");
        LogException(ex, "FileNotFound");
    }

    catch (UnauthorizedAccessException ex)   {
        await ShowErrorDialog($"没有权限访问文件");
        LogException(ex, "UnauthorizedAccess");
    }

    catch (Exception ex)   {
        await ShowErrorDialog($"读取文件失败: {ex.Message}");
        LogException(ex, "FileIOError");
    }
}

网络请求异常​

private async Task<HttpResponseMessage> SendRequestAsync(string url) {
    try
    {
        using var client = new HttpClient();
        client.Timeout = TimeSpan.FromSeconds(30);
        return await client.GetAsync(url);
    }
    catch (HttpRequestException ex)
    {
        LogException(ex, "NetworkError");
        throw new NetworkException("网络连接失败，请检查网络设置", ex);
    }
    catch (TaskCanceledException ex)
    {
        LogException(ex, "RequestTimeout");
        throw new TimeoutException("请求超时，请稍后重试", ex);
    }
}

五、小烨远控的异常处理实践​

在实际开发中，异常处理不仅是为了防止崩溃，更是为了帮助开发者快速定位问题。

一键反馈​

在小烨远控中，我们设计了便捷的异常反馈机制：

如果您在使用小烨远控的过程中发生了异常，只需点击异常界面的一键反馈即可将错误信息反馈给我们，错误信息不包含任何个人数据。

功能特点​

六、最佳实践总结​

✅ DO（推荐做法）​

1. 始终在最外层设置 UnhandledException 兜底
2. 记录详细的异常日志（类型、堆栈、时间、上下文）
3. 给用户友好的提示，不要展示太琐碎的技术日志；
4. 在适当的层级处理特定异常（如网络、文件操作）
5. 提供异常反馈渠道，让用户能帮助改进应用

❌ DON'T（避免做法）​

1. 不要吞掉异常而不记录（e.Handled = true 但啥也不做）
2. 不要在 UI 线程执行耗时操作（用 async/await）
3. 不要忽略 Task 的异常（使用 try-catch 或 await）
4. 不要在 catch 中抛出相同异常（会丢失堆栈信息）
5. 不要在生产环境显示完整的异常堆栈给用户

结语​

异常处理是桌面应用开发中不可忽视的基础设施。WinUI 3 提供了完善的异常处理机制，合理利用这些机制，可以让您的应用更加健壮、用户更加满意。

记住：好的异常处理不是让应用永不报错，而是当错误发生时，应用能够优雅降级、记录问题、帮助用户恢复操作。

如果您在使用小烨远控过程中遇到任何问题，欢迎通过异常界面的一键反馈功能告诉我们，帮助我们做得更好！

作为一名Windows桌面开发者，你是否曾困惑过：微软到底有多少个UI框架？Win32、MFC、WinForms、WPF、UWP、WinUI……这些名词让人眼花缭乱。今天，我们就来梳理一下Windows UI框架的发展历程，并重点介绍微软当前主推的WinUI 3，带你迈出Windows现代桌面开发的第一步。

一、Windows UI框架的三代演进​

回顾Windows桌面开发的历史，我们可以将这些框架大致划分为三个阶段：

第一代：原生时代 — Win32 / MFC​

Win32 API 是Windows最底层的界面编程接口，直接与操作系统对话。用Win32开发桌面应用，你需要手动处理窗口消息（WM_PAINT、WM_CLOSE等），管理句柄和资源。优点是性能极高、控制力强，但缺点是开发效率低，即便是创建一个按钮也需要几十行代码。

MFC（Microsoft Foundation Classes） 是对Win32的C++封装，将窗口、控件等抽象为C++类，简化了开发流程。在90年代到2000年代初，MFC曾是Windows桌面开发的主流选择。但由于其依赖C++的复杂性和历史遗留问题，如今已逐渐退出舞台。

特点：底层、高性能、开发效率低、现代开发中较少使用

第二代：托管时代 — WinForms / WPF​

随着.NET Framework的推出，微软带来了两款重磅的托管UI框架：

WinForms 于2002年随.NET Framework 1.0发布。它采用“所见即所得”的设计理念，拖拽式开发极为直观，代码简单易懂。对于传统的业务系统开发（如进销存、ERP），WinForms至今仍有大量应用。

WPF（Windows Presentation Foundation） 于2006年发布，带来了革命性的变化：采用XAML声明式UI、矢量图形、数据绑定、MVVM模式。WPF让界面与逻辑分离，实现了真正的“UI与代码解耦”。目前仍有大量企业级应用运行在WPF之上。

特点：托管代码、开发效率高、生态成熟、WPF适合复杂界面开发

第三代：现代时代 — WinRT / UWP / WinUI​

WinRT（Windows Runtime） 随Windows 8推出，为触摸屏和Metro风格而生，引入了一种新的应用模型和API设计。

UWP（Universal Windows Platform） 是WinRT的进化版，口号是“一次开发，多端运行”（PC、Xbox、HoloLens等）。UWP支持现代UI特性（如亚克力效果、流畅动画），但由于应用分发必须通过Microsoft Store，且API受限，开发者接受度不高。

WinUI 3 是微软最新的原生UI框架，可以看作是UWP的“解绑版”——它将UWP的现代UI控件库独立出来，不再强制要求通过Store分发，允许开发者使用完整的Windows API。WinUI 3是微软目前唯一重点投入的桌面UI框架。

特点：现代UI、完全原生、无分发限制、微软当前主力方向

二、为什么要选择WinUI 3？​

1. 官方战略方向​

从微软的官方宣言和版本迭代来看，WinUI 3已成为Windows桌面开发的主力框架。WinForms和WPF虽然仍会维护，但新特性基本不再增加；而WinUI 3持续迭代，与Windows 11的新特性紧密结合。

2. 现代化的UI体验​

WinUI 3内置了Fluent Design（流畅设计体系），让你的应用天生具备：

• 云母材质（Mica） 和 亚克力效果（Acrylic）：毛玻璃般的质感
• 圆角与动效：符合Windows 11的设计语言
• 深色/浅色主题自动适配：无需额外代码

3. 完全的API访问权限​

与UWP不同，WinUI 3应用可以调用所有Windows API（包括注册表、系统服务、文件系统任意位置等），没有沙盒限制。这意味着你可以将现有Win32/WPF应用的强大功能平滑迁移到现代UI上。

4. 多种分发方式​

WinUI 3应用可以：

• 直接以.exe方式运行
• 打包为MSIX通过Microsoft Store分发
• 通过其他安装包工具分发

三、创建你的第一个WinUI 3应用​

理论讲完，我们来动手创建一个简单的WinUI 3应用。

步骤1：创建项目​

1. 打开Visual Studio 2022，点击“创建新项目”
2. 在模板搜索框中输入“WinUI”，选择 “空白应用，打包（WinUI 3）”
3. 点击“创建”，输入项目名例如“小烨远控”，即可创建一个普通的WinUI3项目

步骤2：认识项目结构​

创建完成后，你会看到这样的结构：

一、全屏模式​

设计思路

这是最直觉的一种方式。进入“全屏”后，远程桌面瞬间铺满整个屏幕，标题栏、边框、任务栏统统隐去，只剩下对端电脑的桌面。你就像坐在那台电脑前一样，视野完全被接管。

在全屏显示模式下，远程窗口通常会占据你当前所在的屏幕，鼠标被锁定在其中。想切回本地看个消息、回个微信，需要按一下退出全屏的快捷键。

体验特点

• 沉浸感最强，适合长时间专注工作
• 画面利用率高，不受本地窗口布局影响
• 在多显示器环境下，全屏通常会占据当前屏幕，鼠标被锁定在其中

适用场景

需要暂时“住”在远程电脑里，不受本地任务打扰的时候。

二、固定分辨率模式​

设计思路

这种方式更“传统”。在连接之前，你告诉客户端：我要一个 800x600的桌面。于是远程主机真的按这个分辨率输出画面，客户端则原样呈现，每个像素都对应得整整齐齐。

体验特点

• 画面清晰锐利，点对点显示
• 不受本地窗口大小影响，远程桌面内容布局稳定
• 当你用固定分辨率模式连接远程桌面后，窗口本身是有最大尺寸限制的——你不能把它拖到超过预设分辨率的尺寸。

适用场景

对画质有要求、窗口大小基本固定的场景，比如远程调试代码、查看设计稿。

三、缩放模式​

设计思路

窗口拖多大，远程桌面就填多大。画面通过插值算法等比缩放，始终铺满当前窗口。这背后其实是一套插值算法在起作用。窗口变大了，内容被“撑大”；窗口变小了，内容被“压缩”。结果是：画面始终适配窗口，但文字边缘不再那么锐利，图标细节也略有损失。如果你在 4K 屏幕上把一个远程窗口缩得比较小，那些文字可能变得不太好辨认。

体验特点

• 窗口可以任意调整，画面始终按照比例适配
• 适应性最强，无论窗口形状、大小如何变化，都能完整显示
• 缩放过程中，画面清晰度会有所变化，文字和图标细节不如原分辨率锐利

适用场景

日常办公、窗口大小经常变化的操作，对画质不苛求的场景。

四、三种模式，各自取舍​

从设计初衷来看，这三种模式分别满足了不同的使用习惯：

它们各自的侧重点不同。但有一个共同点：分辨率在连接后就固定了——全屏模式下分辨率由显示器决定，固定分辨率模式下由预设值决定，缩放模式下虽然窗口可以变，但画质会随缩放比例变化。

五、小烨远控：在清晰与灵活之间，找到一个新答案​

有没有一种方式，既能像缩放模式那样随意调整窗口，又能像固定分辨率那样保持画面清晰？

小烨远控的做法是：动态调整分辨率，而不是缩放画面。

当窗口被拖大时，它告诉远程主机：“现在屏幕变大了，请按新尺寸输出画面。” 当窗口缩小时，同样也会实时调整。每一次窗口变化，都触发一次分辨率更新，画面始终以 1:1 的方式呈现，不做任何插值，没有锯齿，也没有留白。

整个过程不需要重连，不需要手动设置，窗口怎么变，画面就怎么适配。它既没有缩放模式的模糊，也没有固定分辨率的“一锤子买卖”，更不需要像全屏那样“锁死”你的操作。

这种体验，更像是你在操作一台本地电脑：窗口可以随意拖拽，内容始终清晰。

注：小烨远控是为了两台异地电脑打通互联用的，因此需要在两台电脑上登录使用；

✨ 更新亮点​

📊 更清晰的网络状态显示​

• 网络连接状态一目了然，实时显示当前网络状态
• 状态提示更加直观，网络异常时快速感知

🖥️ 托盘图标全面升级​

• 新增系统托盘图标，最小化窗口后可常驻托盘运行，再也不用担心误关窗口了😂
• 后台运行时不再占用任务栏空间，桌面更整洁

🎯 为什么这些更新很重要？​

网络状态可视化让你在远程办公、技术支持时，能够第一时间发现网络波动，避免因网络问题导致的操作延迟或中断。

托盘图标功能则是为了那些需要长时间保持远程连接的用户——服务器管理员、远程工作者等。现在你可以将程序最小化到托盘，既保持连接又不会干扰日常工作。

📥 立即体验​

小烨远控 2.0.78 已全面推送，欢迎更新体验！

下载地址：https://xiaoyeapp.com/download

感谢大家一直以来的支持！我们会持续优化，带来更好的远程桌面体验。

一、基础操作：保存RDP文件​

Windows远程桌面连接（mstsc.exe）允许我们将连接配置保存为一个扩展名为.rdp的文件，这样下次就不用重新填写所有信息了。

操作步骤：​

1. 按下Win + R键，输入mstsc，打开远程桌面连接窗口
2. 输入计算机IP地址和用户名
3. 点击“连接”按钮下方的“显示选项”展开更多设置
4. 在“常规”选项卡中，点击下方的“另存为”按钮
5. 选择保存位置，输入文件名，点击保存

现在你桌面上就有了一个rdp文件，双击它就能快速发起连接。

二、进阶技巧：让RDP文件记住密码​

默认保存的RDP文件不会包含密码，每次连接还是需要手动输入。要实现真正的“一键连接”，我们需要一个小技巧。

两步搞定记住密码：​

第一步：先勾选“保存凭据”，然后另存为rdp文件；

第二步：运行rdp文件

1. 再次双击rdp文件，此时需要输入一次密码，完成连接后将自动保存；

原理：rdp文件的“记住凭据”操作将凭据保存到了Windows凭据管理器中，以后双击这个RDP文件，就能直接登录，无需再次输入密码。

提醒：公共电脑上不要随便保存凭据；

三、安全提示：RDP文件的黄色警告​

双击RDP文件时，你可能会看到一个黄色的安全警告：

这个警告是Windows出于安全考虑而设计的，因为RDP文件可能来自不可信来源，双击后会自动执行连接。但如果你是自己创建的RDP文件，或者来自可信同事，这个警告每次出现确实有点烦人。

如何让RDP文件变得“可信”？​

要让Windows信任你的RDP文件，需要对其进行数字签名。签名后的RDP文件会有以下特征：

• 黄色警告栏变为蓝色或绿色（表示发布者已验证）
• 显示“此远程连接已由可信发布者签名”

RDP文件签名方法：​

1. 使用代码签名证书：可以从正规CA（如Symantec、DigiCert）购买代码签名证书
2. 使用rdpsign签名：

rdpsign /sha256 <你的证书指纹> <rdp文件>

3. 验证签名：右键点击RDP文件 > 属性 > 数字签名选项卡，可以看到签名信息

再次双击rdp文件，看起来清爽了不少。当然签名不仅仅是为了好看，更重要的是为了防止关键信息的篡改，如果别人修改了你的rdp文件关键信息，签名信息将瞬间失效，会再次弹出橙色警告。

四、总结与最佳实践​

1. 个人日常使用：按步骤二设置记住密码的RDP文件，方便快捷；
2. 团队共享连接：使用未保存密码的RDP文件，配合共享密码管理工具
3. 安全敏感环境：启用组策略中的“始终提示密码”，或使用证书签名的RDP文件
4. 跨平台使用：其他平台的支持rdp协议的远程桌面客户端一般也支持rdp文件导入，这样也会方便不少；

如果您使用小烨远控，默认和rdp文件体验效果一致，双击即可连接，您也可以选择记住密码，记住密码和上述过程类似，都是保存至您的本地系统Windows凭据管理器；

掌握了这些技巧，相信你的远程工作体验会更加顺畅。如果你有任何问题或更好的建议，欢迎在评论区留言讨论！

我们很高兴地宣布，小烨远控2.0.82版本正式发布！ 本次更新带来了一个极具诚意的政策：两台设备，永久免费。无论您是为家庭电脑提供技术支持，还是需要在两个办公地点间无缝切换，这个免费版本足以覆盖大多数个人用户的日常需求。

为什么选择小烨远控？​

在免费的基础上，小烨远控更坚持在安全与体验上做到极致。

1. 安全，从底层设计开始
   • 设备按账户隔离：您的设备仅对您自己的账户可见，天然避免了来自公网的随意扫描和攻击。
   • 全程加密，无惧窥探：所有远程连接数据均经过高强度加密，确保您在公共网络下操作也足够私密。
   • 无需公网IP：告别复杂的端口映射和网络配置，从根本上减少了网络攻击面。
2. 性能，为高效工作而生
   • 国内多节点加速：我们在国内部署了多个网络节点，系统会自动为您选择最优路径，显著降低延迟，让远程操作像在本地一样流畅。
   • 原生RDP体验：完美支持Windows远程桌面协议，如果您是Windows用户，能享受到最熟悉、最高效的原生桌面访问体验。
3. 便捷，一个账号通行
   • 支持邮箱、微信、手机号等多种登录方式。您也可以使用已有的Microsoft、GitHub账号快速接入，无需重复注册。一个“小烨通行证”，即可管理您的所有远程设备和未来更多服务。

如何开始？​

体验小烨远控非常简单，只需三步：

1. 访问小烨远控官网（https://xiaoyeapp.com）下载客户端。
2. 使用您喜欢的登录方式（邮箱账户需要先注册，第三方如微信则直接登录）。
3. 在两台您自己的设备上登录同一账号，即可开始永久免费的远程之旅。

小烨远控2.0.82，致力于成为您安全、高速、简单的远程桌面伙伴。 无论您是远程办公的技术人员，还是帮家人维护电脑的“家庭IT顾问”，都欢迎来试试看。

如果在使用中遇到任何问题，或有任何建议，欢迎随时通过官网渠道向我们反馈，我们将竭诚为您服务！