我理解你的问题是，为什么 x86 的 docker 可以直接运行 arm64 的 docker image ？

以 Docker Desktop 为例子，安装时会自动安装 qemu 依赖，不同架构的镜像靠的是 qemu 模拟，可以参考以下回答
https://stackoverflow.com/questions/66350893/why-macosx86-can-run-docker-arm-container-arm64v8-alpine/66435150#66435150

可以通过 docker manifest 来检查一个镜像的架构，比如
docker manifest inspect --verbose arm64v8/alpine

"platform": {
"architecture": "arm64",
"os": "linux",
"variant": "v8"
}

坐标法国
14 寸满血 PRO + 32G + 1T
发布会结束立即下单，估计是因为换了美式键盘的缘故，预计到达时间 11/04 - 11/08

然后探讨下你叙述中显露出的一些问题，仅供参考

1. “登录 1000 人，每个客户端每 20ms 给服务器发送一条测试消息，长度为 10 的字符串”
不知道你的游戏框架的序列化是怎么做的，若是想要反映真实情况，仅仅用字符串来模拟肯定是不够的，建议在压测环境中引入序列化和反序列化，这样可以更多暴露出在这个过程中的内存、CPU 问题

2. “每个客户端每 20ms 给服务器发送一条测试消息”
不建议给 20ms 间隔，每个客户端直接将单个 TCP 链接打满更具备压测意义

3. “10 多分钟开始客户端大批掉线”
不知道你客户端掉线的原因是什么，若是用 TCP 的话，最好可以知道连接断开的原因然后具体分析，正常情况下掉线一定是不正常的

最后，
若是你的序列化方案就是字符串序列化，而又不想自己写压测逻辑的话，可以考虑用你的服务器结构实现一个最简单的 HTTP Server，然后用成熟的 HTTP 压测工具去压，这个不具备任何业务逻辑，但是能很好暴露出你潜在的服务器处理能力。

这里我用的 wrk， 可以参考一下我在 MacBook Pro (16-inch, 2019) 2.3 GHz 八核 Intel Core i9 下的结果，
wrk -c 400 -t 4 -d 5 http://localhost:13023/

Running 5s test @ http://localhost:13023/
4 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 3.11ms 1.25ms 38.01ms 88.82%
Req/Sec 20.08k 2.02k 23.81k 83.33%
407661 requests in 5.10s, 60.65MB read
Socket errors: connect 153, read 101, write 0, timeout 0
Requests/sec: 79880.37
Transfer/sec: 11.88MB

最近也在做类似的事情，可以参考一下我的方法论

1. 时间指标
- 平均响应时间
- 最大响应时间，用来衡量极端情况下的用户承受的最大延迟
- 方差，标准差，用来衡量用户承受延迟的分布
- 有能力的话可以做一个直方图，并不需要全量记录，个人感觉取 1%抽样就足够了

2. 内存指标
我用的是.net core, 一些概念可能和 java 不一样，可以类比下
- GC 次数，特别是不同代的 GC 次数
- GC 时间占总执行时间的比例
- 若是 GC 次数不正常，可以考虑间隔每段时间取堆内存的 snapshot，若是工具支持，最好可以拿到内存分布的热点图，比如这个函数这一行分配了全体的 90%的内存

在有以上数据的情况下，即使没有同类型的框架可以横向比较，也可以自己根据压测结果优化迭代，再行压测比较。

已经下单 14 寸 PRO 版本，没买 max 版本实在是囊中羞涩
到时候看看 16 核 GPU 能带来什么样的体验

可能 Conditional Types 可以帮到你
https://www.typescriptlang.org/docs/handbook/2/conditional-types.html

看一下 select_related 是否能满足你的需求
https://docs.djangoproject.com/zh-hans/3.2/ref/models/querysets/#select-related

看一下 webstorm 的 local history，或许还能救

没有 stash 的话基本没办法了

看到这题感觉回到了大学。

如果仅仅要求支持以上的几种形态的话，简单的做法就是定义等差，等比，开方等差的规则，然后判断当前数列不满足条件时，做差去递归求解就是了。别忘了加上最大递归层数的限制。后期如果增加需求加规则就好了。

不想要仅仅如此的话可以看一下如何做一个求解器，举个现成的例子，你在 wolfram alpha 上直接搜索 1，3，5，7，9，他就会提示你这是个等差数列，并给出通项公式，网址： https://www.wolframalpha.com/input/?i=3%2C5%2C7%2C9%2C11

最后，作业还是自己做吧。

- 需要额外更新的操作放到此异步方法内，额外更新的是同步操作

需要等待额外更新的操作结束才返回么？如果需要等待，那没必要用 Task.Run 再包一层

如果不需要等待，只是希望执行了以后就不管了，那么去掉 async，await，直接用 _ = Task.Run(...) 就可以了，Task.Run 会在线程池上执行操作，所以并不会开辟过多的线程。

---
另附，
1 、普通处理只需 CPU 计算
如果的确这个普通处理会耗费相对较多 CPU 时间，而期望调用函数尽快返回的话，用 Task.Run 是一个比较常见的方法

2 、需要数据库读写等 I/O 操作
此处建议直接找原生支持 Task 的异步方法的库

之前 15 寸坏了的时候，也在犹豫是换 M1 还是 16，因为技术栈是.net core 服务端+Unity，了解了一下 c#开发技术栈在 M1 上的支持程度。

简单来说，现阶段来讲是无法取得很好的开发体验的。原因楼上也说了，.net core 3.1 很难支持，.ne5 只能靠罗塞塔，jetbrains rider 目前也只是罗塞塔，mac 上的 vs 体验真的一言难尽，vs code 虽说也有 c#插件，但是体验也是一言难尽。

Unity 的话目前只有最新的 alpha 原生支持 M1，但是 burst compiler 还处于无法用的状态，罗塞塔版本的话，c#重载速度让人如鲠在喉。

所以老老实实 intel Mac

就算不用 ipv6 负载均衡实例和地址转换服务也是可以解决的，毕竟能省一点是一点
既然是 ecs，大部分 ecs 实例天然支持 ipv6 的，然后直接用 ecs 的 ipv6 地址做 AAAA 解析就好。如果不想暴露 ipv6 地址在审核通过后取消掉 AAAA 解析就好（谨慎使用）。
现代 web 框架的网络层应该是都支持双栈 tcp 协议的，所以理论上解析做完了以后没有代码要改，还是很方便的。

对于 Select 来说是这样的，你还是需要一个 while 循环来保证及时更新 socket 的就绪列表
要补充的一点是，这里拿 read 和 select 作比较不是很好，应该拿 poll 来做比较，因为 select 并不仅仅可以轮询 read 状态，和 poll 一样，是可以查询 read, write 和 error 的

对于 Epoll 来说也是一样的，通过调用循环阻塞的调用 epoll_wait 来获取最新的事件状态。

@mmqc Mac OS 11.4 (20F71)

不至于，手头有一个根据配置文件生成的 cs 文件，2993 行，移动顺滑

JetBrains Rider 2021.1.4
Build #RD-211.7628.50, built on July 13, 2021

不想折腾的话可以用 Turbo Boost Switcher 简单关闭睿频，但是单核性能也会因此被限制
实际控制功耗的话可以用 Volta, 但是 Volta 一是收费，二是他需要部分关闭 SIP，因为他加载的 kext 文件显然苹果不可能给他签名
实在想折腾的话之前 github 找到过一个项目可以参考下 https://github.com/sicreative/VoltageShift

补充一下，实验不是很严谨，看一下大致比例即可
上文所说的功耗一般指 CPU Package Core 功耗, CPU Computing Highside 的功耗通常会更高

实践下来外接 4k 能清净的方法就是限制 CPU 功耗，
实测下来不启用 dGPU 的情况下，限制在 55w-60w 没有任何压力，单烤甚至风扇不用满速
接了外接显示器后，手动把功耗限制在 35w 左右，感觉还行

附上一份前几天无聊做的 CPU 功耗和 Cinbench R23 跑分的对照表，i9-9880H
15w - 3597
20w - 4554
25w - 5448
30w - 6106
35w - 6757
40w - 7253
45w - 7702
50w - 8065
55w - 8285
62w - 8905

楼上已经说得很好，可以用 pre commit hook 来做格式化的琐碎事情，或者 jetbrains 系的 ide 都可以设置在 commit 之前做 code cleanup

建议专门找个时间按照统一标准把整个 repo 都按照统一的标准格式化了，以绝后患