我找了一圈，似乎 ios 还不能通过 nfc 连接 wifi ，而这个功能在安卓机上基本所有品牌都支持。我在想既然可以通过 nfc 弹 mini app ，那么只要这个 app 覆盖率足够广且它能支持配置 wifi ，那么 ios 上这事就算能干了，访客 wifi 用这种形式配置挺方便。
找客服问了下说不支持，如果技术角度能做，那这产品脑子就不是一般的糊，门店 wifi 对很多顾客是刚需，特别是在信号差的门店。

(我也从官方搞了张免费的，到货了再看看数据

@TomyJan 写成了~不过没扫成，提示要同意 app store 的新版协议，多碰了几次所有设备都直接提示失败了，可能是被风控了😂明儿再试试

有 ios 适用的 nfc app 或者写入说明吗

这东西的 tun 模式是直接通过 ip rule 接管的流量，规则是不带特定 mark 的流量走特定路由表的默认路由，所以可以起到接管全局流量的效果。
我也被坑过，当时解法是开了另一台同内网 vps ，连上了。我觉得可能设置防火墙阻止和 cf 建立连接，重启机器应该也能 work 。
后来在网页上点了一堆东西，用它的 zero trust 把 exclude 模式切成 include 模式，这样就能只对手动添加的 ip 段生效了。

要用 openssl ，开 vendored 这个 feature 就静态链接了。

我现在树莓派就是专门拿来开笔记本的(笔记本常年关盖子当台式机用，很难按开机键)，插了根网线到笔记本上。
系统对接到了 homekit ，有网就能开机 https://github.com/ihciah/wol-homekit

ps: 最低成本是搞一个 openwrt 的路由器，放个后台脚本自动连接校园网，再跑个自己搓的程序用于 WOL(开机指令用 homekit 或者 tg bot 等下发，都不需要自建中心服务器)。

用 secretive ，私钥放硬件里提不出来，只签名

怎么到哪都有 BQ 233

创业公司产品需要快速迭代，并且可能需要较为独立地设计和实现功能，要求一定的抗压能力我感觉是合理的。
虽然这个 jd 我只是帮人发，但也不是无脑乱发：据我所知团队里有极其天才的成员，所以要求略高并给出了对应的薪酬（薪酬范围可以自行 google 一下），也挺合理。

如果你看好这个产品的未来，不妨试试和牛逼的团队一起搞。

我觉得楼主想法没啥问题。靠自己有什么问题？就是看不起走后门的，那么自己有后门也不应当走。别的没收获，至少心里舒服。

我记得以前某个客户端，api 甚至默认监听 0.0.0.0 ，局域网内即可直接拿到配置信息

看了一圈楼主的代码，感觉是天赋型选手。见过太多技术水平、德行和位子配不上的，更觉得楼主这种很可惜。

大小端是在将多个字节解释为单个 primitive type （例如 u32, u64, i32 等）时遇到的问题。
那么你现在需要将其理解为 u64 吗？并没有。所以不涉及大小端问题，直接逐 byte 比较即可。
嫌慢可以上 SIMD ，一些现成库有实现，编译器可能也能将其自动向量化。

> 不要把 go 再传播到其他语言了 / 都用 rust 了. 还调 go

这个实际存在的需求：不是所有人都会写 rust ，并且也不是所有组件都能被快速重写。作为一个帮助 go 转 rust 的工具，它对于解决实际需求和促使大家重写都有积极意义。正如 zig 与 rust 的关系一样（如果你已经能用 rust 了那么就不需要 zig ），理想情况是大家都不需要依赖本项目，但达成理想的过程可能需要。

> 真要用 rust 重写的话也应该是从 go 调 rust 开始,逐步把实现迁移成 rust

主逻辑应当被优先重写。如果只是优化 go lib 的性能，除了 rust 外还有很多手段可以用，最终业务开发者还是只写 go 。go runtime 确实无法避免，但这个是技术细节了。

> 这样就可以直接 rust 写业务代码了

在我当前公司内部有一个网关就这么开发：使用我们提供的 rust 网关框架，业务开发只写 go 。

> go 调用 rust

在规划中啦！ go 调用 rust 一般是同步 call ，直接 CGO 即可。异步的话需要一点额外的工作。

> 现在能支持 windows 平台吗

支持的。现在 rust2go 支持 tokio/monoio 等 runtime 。

> mem-ring 的 How it Works

有空我写下～这部分在那篇介绍 blog 里也有比较简短的介绍。

> 字节要开始转 rust 了吗

很久以前就开始了，我当前公司内网的一堆基础 sdk 都是我从零搓的。

@fgwmlhdkkkw 没看懂，麻烦直白一点？如果你是指我的前一条回复，那么我确实可以 post 一些数据，但参考意义并不大，例如：
在基于 CGO 的版本中，走异步调用，单核 1000 并发请求模拟 10ms 延迟的 go(GOMAXPROCS=2)，QPS 87000 左右(可以以此估算延迟)，go1.22.4 下 cpu 占用率 44.18%，go1.18.10 下 cpu 占用 65.35%(两个 go 版本的 QPS 接近)。测试使用的 Request 是例子 DemoComplicatedRequest 。内核版本 6.7.3 ，cpu 是 intel platinum [email protected] 。
如果要涉及方案对比，这个数据对比更无法得出的可被公认的数字，因为对比方案的实现和序列化方式都是因人而异的。
本文和此次分享侧重技术方案本身，向大家介绍一个全新的问题，以及我解决该问题的设计与思考，纯技术分享性质，希望对这个问题或技术本身感兴趣的人多多 comment ！

@povsister 性能数据是因人而异的，要看参数和响应的类型与大小，也和使用异步或同步接口有关，以及 go 版本。考虑到这些 diff ，我这里目前没有非常官方的数据，你可以在你的场景下测下(简单写一下 benchmark)，对比 rpc 等方式应当有较大提升。