推荐 https://httptoolkit.tech/
把已 root 的设备通过 adb 插上，可以自动配置好证书。

我到觉得两者没太大优劣之分。
rust 的单文件模块，一个模块代码很多的时候文件就会太长，不得不分模块。而 go 就可以用多个文件写同一个模块。
而 go 用目录分模块，模块很多一个模块代码很少的时候也会很麻烦，并且文件名不体现模块名。

但是 rust 整个的包管理 crate 系统要更好，lib 的归 lib，bin 的归 bin，比 go 都混到一起更清晰。

没有比对象对象存储 s3 这些更适合的网盘了。
可靠性好，速度快，按量付费，有 API 无论备份还是分享都很方便。

以微信的尿性，只要敢这么用登录直接封号。解封需要好友输入银行卡号 /人脸识别辅助验证。

你要用 clash 就自己仔细阅读文档自己配置，网上流传的和各种鸡场托管的绝大多数都极度不安全。
另外不建议用任何闭源客户端，有被收编的风险。

@iceorange #22 结果“乱七八糟”哪里是主观感觉了，你的程序存在 race condition，运行的结果是不确定的，那就是乱七八糟啊。
同样，这个后果造成的影响就是多数情况正常工作，偶发性的突然出现无法连接、没有回收等各种问题（出现冲突时时运行结果本身就是不明确的）。当然很容易让用户非常困惑并且难以排查（复现）。
又看了下你这个 pid，你的程序可能会使用自己的 pid，也可能会使用目标程序的 pid，当然存在 pid 回收后再次分配导致你的名称冲突，进而因为缺乏原子性造成 race condition 。

当然也不是说没有原子性就一定会有问题，但你需要考虑各种不同的情况，子进程嵌套调用、不同方式调用、僵尸进程、被 kill 后未回收等，这是非常 error prune 的。

@iceorange #9 因为操作 iptables 不是原子性的，一个进程在添加 /删除规则的同时正好有其他进程也在添加 /删除规则，最终的结果就是乱七八糟。
我看了一下你是用 pid 区分链名，多数情况下应该没有问题，但要是恰好有回收的 pid 导致重复就会导致非常令人困惑且难以排查的 bug 。
另外你的大多数逻辑甚至连文件 IO 都不写代码而是用 shell 命令实现，与其把 shell 脚本嵌入到代码里，直接用 shell 脚本不方便吗？
解析命令行参数和信号处理同样可以用库。至于检查错误，shell 脚本检查 shell 命令的错误当然比 rust 容易。

@iceorange 想象一下用户用你的工具并发启动多个进程，多个进程同时操作 iptables 会怎样。
nftables 一大亮点就是提供了多个程序并发操作防火墙的原子性。
因为你的核心逻辑基本是 shell 命令实现的，每次都需要需要启动多个外部进程，开销不小。
既然用 shell 命令实现，为啥不用 shell 脚本呢。

还以为是又发明了什么新的魔法，一看是操作防火墙的。
而且是通过调用 iptables 命令操作，十分不合适。
没有原子性、性能也不好，并发启动很可能出问题。
正确的做法应该是通过 libnftnl 这样的库。
而且你这样没必要用 rust 啊，直接用 shell 脚本更合适。

第一反应 halt

cpp 目前支持最好的应该是 clangd 吧，要是不行那就没办法了。

@okampfer #12 snowpack 是基于 rollup 实现的，不启用优化的情况下使用 rollup 把依赖的包编译成一个个的 ESM 。
启用优化后则在这个基础上再使用 bundler 把这些 ESM 打包到一起。

https://github.com/snowpackjs/snowpack/blob/main/snowpack/package.json#L51

暂时忘掉你所知的 OOP 和命令式的编程语言，然后学一下 haskell 。