可能 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 都按照统一的标准格式化了，以绝后患

保研。
实习并不等于入职，
工作并不一定快乐，
只有学历是硬通货。

个人愚见，
想要理解这些问题，需要把这些概念拆开了去理解
首先是最下面的 IO，IO 可以按阻塞，非阻塞区分，也可以按同步，异步区分，组合起来就有 4 种情况，比较常见的有同步阻塞和同步非阻塞。这个网上有很多博客讲的很好，我就不在这里献丑了
理解了 IO 之后，接着就可以看 IO 多路复用，常见的有 select，epoll，
IO 多路复用里，无论何种实现都会有一种方式通知“你”我这边有数据，你可以开始处理了，或者说这些 socket 里有可读的数据，你可以去调用他们的 read 函数了，我们将这种通知统一抽象为事件，也就是 event
所谓事件驱动，event driven，本质上就是寻找一种方式不断的去聆听到来的事件，并对到来的事件进行处理的一种编程范式。
以 Node 的事件循环 event loop 为例子，其实可以简化为以下代码，通过主线程跑一个死循环 while，不断的去拿到当前可以处理的事件，在主线程处理它，然后循环

```
while(events = wait_for_events()){
process_events(events)
}
```
此处的事件可以有很多种
1. 最常见的 IO 多路复用器告诉你哪些 socket 可以读了，主线程去读这些 socket，此时的 read 并不会阻塞主线程
2. 还可以比如说 settimeout 的定时器到时间了，主线程就会把闭包里的东西执行一下

以上可以引申出来大部分的时候我们可以认为所有跑在 nodejs 主线程的程序不需要考虑多线程问题，因为真正的脏活累活都交给了内核或者背后的 IO 线程池去做了。这样做的好处是我们极大可能的避免了线程切换带来的开销，坏处就是一个 foreach(1e100)这样的耗时任务就可以把整个主线程堵塞。

---
我不知道什么叫收银员非阻塞，但是顾客极多导致主线程来不及处理到来的事件的时候，就需要部署多个主线程，这也是 pm2 多 instance 部署能带来性能提升的原因。

---
没看过 HAProxy 和 Nginx 的具体实现，所以不确定以上的对 Node 的观点是否可以迁移到这两个上。

个人愚见，
按照你对 C/S 端架构的理解，可以理解为每次在浏览器上打开网页都是一种动态加载客户端的行为。只不过客户端的载体（ HTML，CSS，JS 之流）并不会持久化在浏览器端。

感觉可以再深入一下，根据我的理解这两个语句应该是等价的。

能否提供一个最小的出现 bug 的情形呢？