小弟我从学校出来的时候是Java Web后端背景，现在也在接触现代化Node.js前端框架和我司的数据与ETL相关产品。之前还没毕业的时候在前东家实习，用C#写过WinForm，给客户做了个处理气象数据的小工具（数据处理的核心调用的已有其他软件的dll），对Windows桌面应用程序的开发也就仅限于C#和WinForm的浅薄经验。简单恶补下知识，现在Windows桌面应用程序GUI技术基本有如下这些：
微软自己家的：
①最古老的调用Win32API，用C++写
②WinForm，和.net完全绑定，用C#写
③WPF，和.net完全绑定，用C#写，但是XAML写界面的话对高分辨率以及缩放很友好，界面渲染也很酷炫
④UWP，这个不提了吧，微软自己在这块的声音也越来越弱了吧
别人家的：
①Qt，网上找到的特点包括但不限于：界面酷炫、方便多平台移植。我印象最深刻的VirtualBox的GUI就是用它做的
②Delphi，这个会的人不多了吧
③基于Chromium和Node.js的Electron：做的最牛逼的当属MS家的VSCode，完全接近于现代化前端开发的那一套

看了昨天买向日葵控控被关照的帖子后，我突然想如果要做一个像TeamViewer、向日葵这种的远程桌面客户端的话，GUI方面的技术选型应该选什么？
Electron我觉得不太可行，毕竟还是相当于跑在浏览器里面的，像是远程桌面这种会调用操作系统自身API的东西应该会有很多局限。
Qt网络上的其他资料有提到学习成本较高，这个先不谈。
现阶段我觉得最可行的应该是WPF，WPF看介绍貌似是可以做到类似于Web界前后端分离的模式，但WPF如果后端是C#搭配.net的话，像远程桌面这种和系统API以及网络请求较多的应用场景下会不会有性能问题？

其实看下来Windows桌面应用这块GUI的选型真没有完美的方案，如果要做一个远程桌面客户端，你的选型是什么？

winui + webview 挺好的，如果熟悉xaml的话纯winui也很舒服，不知道楼主所谓”完美方案“是什么，像web一样几乎没有其他选择才算完美？

当然是qt

对于远程桌面客户端来说，WPF,Electron这些框架是用来做和用户交互的窗口那部分功能的，用哪个都没啥关系。底层的网络连接、系统控制之类的功能肯定是c++写的。

delphi 最简单。。实际上很好入门

其实这个东西的难点有下面几个：
1. 如何快速采集被控端桌面信息，目前有2种思路。一个是截图，一个是记录屏幕绘制信息再回放。截图流量消耗大，截图也有很多种办法，有GDI的，有DX的，有驱动hook的。记录屏幕绘制信息回放的目前我就知道Windows的远程桌面是这么干的。好处是流量小，网络环境差时也能有不错的效果。
2. 内网穿透，大部分机器都在内网，怎么穿透也是个难点，有的机器甚至都穿透不了，只能走中转服务器转发
3. 如果有音频的话，音频采集又是一个难点。这方面没有研究过，只是知道有什么回声消除之类的要去解决。
4. 控制的话也是个难点，你这边移动个鼠标，那边要能接受并移动。这个一般要用win32的API，这个要是从头来一遍的也是深坑。此外还有权限控制等等杂八七糟的东西。

目前最快捷的是webrtc，不过用了webrtc后还是要自己搞协议和转发服务器等等。但是比从头来一遍已经好很多了。

你确定客户端只需要适配Windows？如果是的话，那确实可以只用WPF来写界面。

这种远控的协议实现，主要的参考对象就是各种VNC变种的开源代码。