投 Tauri 一票，只要你们前端的兼容性做到普通网页的程度（可以在不同版本的现代浏览器中正常加载），那就没有什么 webview 不同导致的 bug 可担心的。
flutter 始终都是移动端优先，做出来的应用体验如同在使用 Android 模拟器，桌面体验较差，成熟度比传统 Web 技术差远了。
@zengxs Tauri 就是原生开发+Webview 做核心 UI 啊，只不过帮你包了一层 API 方便使用而已。

@xuanzc880 知道你走代理和知道你通过代理访问的所有域名是两个概念。
据我所知国内 53 和 80 端口的上行流量会全部镜像一份到某部门，具体风险自己考虑吧。我发这些只是提醒不知道这种行为的用户其中可能的风险，你了解风险并接受当然可以正常使用。
@xx3122 解决方法是你要仔细阅读并完全理解文档，然后自己手动编写配置。简单地说自己额外搭建一个 dns 服务，并把 clash 中所有 dns 服务器列表全部删除，dns 指向自己搭建的服务。

@reorx toml 很符合你说的严格、规范啊，本来就是规范化的 INI 。至于重复你想想它的设计目标就是配置文件，和 json 不一样。

@studyingss 我的意思只是提醒普通用户或没有仔细阅读文档甚至源码并手动编写配置的用户，如果使用了默认的（官方示例 or 提供商托管）配置，大概率访问的域名已经暴露给了 ISP 和有关部门。
这是 clash 本身设计的“缺陷”，虽然通过外部服务可以一定程度缓解，但对很多用户（尤其是终端而非网关）是很难达成的。
当然你要说不尽人意也未必，只是不尽我们意，对服务提供商来说各种泄露流量外加配置托管，可以由服务商控制哪些流量被代理（大部分用户不会自己写配置），方便还能节省成本，好用的很呢。

显卡虚拟化 vGPU 直通 /显卡直通+lookingglass 那样的图形 API 捕获+shm 取回画面应该是理论上最合适的。
除此以外，如果是 Linux/kvm + qemu 虚拟 linux guest 的话可以用 virtio 的图形驱动，据说性能很好。
Windows/hyper-v 虚拟 Windows guest 的话，可以修改引导直接真机启动虚拟机系统，打游戏什么的可能这种方法是最合适的了。
再其次就是 parallels/VMware workstation 这样的专业桌面虚拟化产品提供的图形驱动了，性能倒是不差，但高负载还是不行。
再然后 VirtualBox 的图形驱动和 qxl 等开源实现，基本上能保证日常操作流畅，视频游戏之类就不用想了。
最后就是 rdp/vnc/x 转发等远程协议了，网络好的时候能不卡就不错了。

@jsq2627 这下倒车回到当年 pac 时代的黑名单了，不过也确实过滤大量敏感域名后能缓解相当一部分问题。
但黑名单终归不可靠，过度依赖规则的维护，除非极轻度使用，可靠性上不如早就流行的 CN ip + geosite:cn 的白名单方式。
终归 clash 更像是为服务的提供者而非最终用户设计的，注重易用性、忽略安全、节点切换，以及规则托管，都是为了方便服务的提供者。还有一些行为，如节点如果未指定默认视为不支持 UDP ，且如果规则到最后也没匹配到支持 UDP 的节点的话会默认直连（ Match,final 也会漏掉）而非丢弃。怎么看目标客户都像是为服务提供者设计的。

@fengtons 没有像这么多的人，真到那么一天谁给你想办法？

@yanyumihuang 这不就是我上面说的，换用外部 dns 服务器才能缓解 clash dns 模块的泄露问题。clash 的 dns 流程只拿来匹配 IP 规则用，最终结果还是发送域名的连接请求（这会导致实际配置的 dot/doh 全部失效，dns 解析全部暴露给远端网络提供商，不过这就是另一个问题了）。
更稳妥的方法是连 fake-ip 也不用，完全放弃 clash 的域名规则，域名分流全部由外部 dns 服务配合 ipset/nft set 实现。
一句话说，使用 clash 内置的 dns 模块（和依赖 dns 模块的分流机制）会暴露域名给有关部门。如果你觉得自己日常访问的所有被封禁的违法违规的境外网站全部向有关部门披露都没问题，那当然可以正常使用；但很多用户可能根本就不知道这种行为，所以我觉得还是需要提醒一下风险。

@yanyumihuang 然而我看到的 issues 显示类似问题基本都没有回应。至于用 adghome ，就符合我最开始所说的不使用 clash 内置的 dns ，如果用了 clash 内置的 dns 必然会暴露。

@yanyumihuang IP 类规则 noresolve 除了直接访问 ip ，通过域名解析到的都不会生效了，大部分场景都没意义了。这些规则加 resolve 是为了避免影响用户的配置，正常来说匹配到这些规则前已经被其他规则 resolve 过了。
你倒是说说怎么配置加密 dns 能正常使用还不泄露。我上面说过了，如果 dot/doh 指定了境内的服务器，那同样还是泄露，只不过泄露的对象从 ISP 变成了 dns 提供商，最后都会归到有关部门；如果只指定境外的 dot/doh 服务，且不说大部分都被屏蔽了，就算能直连对响应速度的影响也是剧烈的。
clash 的 dns 模块不支持通过代理解析，这是“把自己的使用问题归到工具上”。
另外 clash 的 dns 提供的 dns 模块 nameserver 和 fallback-nameserver 的并发查询本身就是 leaked by design ，泄露就是软件设计的符合预期的行为。

@yanyumihuang 你配置哪个 doh/dot ？如果是境内的那结果一样，如果是境外的现在还有哪个境外 dot/doh 服务器可以直连？就算能连上，极差的速度和稳定性对网络访问体验的影响就不用我多说了。
clash 的 dns 模块就是这样设计的，无论你怎么写规则，只要用到 dns 就会泄露。你非要说“用到 dns 就是规则的问题”那我也无话可说。
@Celebi 就正常使用啊，把 clash 的 dns 关掉，再启动另一个 dns 服务，然后把客户端使用这个服务。

@ALLROBOT 你知道用 clash （正常配置下）会让你访问的域名（无论是否走代理）暴露给 ISP 和有关部门吗？
具体看我另一贴的回复
https://www.v2ex.com/t/852908

@studyingss 你怎么就觉得没有呢，最简单的，全部通过 dot/doh 走代理解析，再配合一个大陆常用域名的白名单，不过就是牺牲一些准确性罢了。再比如用 edns 提供一个任意的 CN ip 通过代理以 dot/doh 向 8888 查询，再判断结果是否为 CN ip ，是的话再从国内直连解析。
当然以上这些使用 clash 内置的 dns 与规则分流是做不到的，连解析都不能走代理。问题就是 clash 的 dns 模块本身，不使用 clash 内置 dns 可以用外置的 dns ，配好走代理的 dot/doh ，你告诉我怎么会泄露？
另外像你这种规则写法是没必要的，除了耐飞等需要特殊配置的以外，在能被兜底规则匹配到的情况下提前加规则有啥意义？就算你请求中的少部分“热门”、“常用”域名没有产生 DNS 请求，你访问的不存在于规则列表中的域名是比前者更不宜暴露的。

@yanyumihuang 不会真有人不使用 IP 类规则吧？ geoip 匹配 CN ，这基本是分流的标配了，也只有 IP 匹配相对准确。clash 的 dns 模块不支持走代理只能直连，再加上从官方示例到各种托管提供的配置都在使用这种类似 chinadns 的“智能”分流方式，如果用户没有非常仔细地阅读文档并自己编写配置的话，那么他十有八九正在暴露所有访问的域名而不自知。另外还有些事情连文档都没写，不去仔细看代码都发现不了。你知道节点不支持 UDP 的情况下，你的 UDP 流量会怎么样吗？

提醒一下使用 clash 内置分流的用户，如果你启用了 clash 内置的 dns 功能，并且配置中有这样的项（来自官方示例）：
nameserver:
- 114.114.114.114 # default value
- 8.8.8.8 # default value
- tls://dns.rubyfish.cn:853 # DNS over TLS
- https://1.1.1.1/dns-query # DNS over HTTPS
- dhcp://en0 # dns from dhcp

那么你访问的*所有域名（包括走代理和直连的）将会全部暴露给本地 ISP 运营商与有关部门*。
YOU HAVE BEEN WARNED

因为 clash 具有这样的分流逻辑：获得一个域名后向所有 dns 服务器并发发送请求，取最快返回结果并判断是否为 CN ip ，且 clash 的 dns 请求只支持直连，无法通过代理发送。所以如果你的 nameserver 列表中包含：任何非 DoT 和 DoH 的项；任何大陆服务器。那么你的所有请求都会暴露。
除此以外如果你使用包括 chinadns 在内的各种同类软件都会出现同样的后果。

scoop 你自己写个 manifest ，改个版本号和下载地址不就行了。

@pengtdyd 这是什么爆论，先且不说 C/Cpp/zig/Rust 等一票原生语言本身没有额外开销，性能完全取决于具体代码。C 语言在性能方面也是具有一些劣势的：
1. 糟糕的标准库和依赖管理，很多 real world application 由于开发者为省事选择简单而非最优化的算法与实现导致性能损失。而像 Rust 这样提供方便的依赖管理，成熟且经过深度优化（复杂算法、simd 等）的库被广泛使用。
2. 手动资源管理外加宽松约束，导致的心智负担使程序员倾向于防御性编程和不必要的复制，外加理论上对编译器优化的限制。
3. 极大规模和复杂度的应用中 Java 等具有 JIT 的语言性能吞吐量等表现要好于 AOT 语言。（并且复杂度庞大的应用根本不可能由低级语言编写）
4. 开发成本过高。比如绝大多数 C 编写的网络服务并发性能肯定是不如 go 的，因为后者自带，前者除了 nginx 这种谁会去费劲优化。

这个库最大的优势是 bindings 容易，各语言都有。qt 那些太复杂了。

内核本身就支持内嵌 initramfs ，只不过正常情况不用，因为更新维护麻烦。或者可以把需要的内核模块都编译到内核里面，直接启动 rootfs ，这样也不需要 initramfs 。