附议
如果只有一个人做研发相关工作，在早期千万不要花费时间在 Devops 上，这是一个时间怪兽，而且和游戏开发是两条平行线，首先做好版本管理就可以了。
Unity 提供一个 Cloud Build 选项，可以去了解了解，功能相对来说简单一些，但是如果买了订阅应该就是免费使用了
Metabase 非常好用，免费版本功能完全够用

如果用 Unity 选择使用 URP 或者 HDRP 开发，买 Asset 时候注意是否支持 URP 和 HDRP ，有的资源版本过老，可能不能很好的支持目前强推的 SRP (Scriptable Render Pipeline, URP 和 HDRP 是它的两个官方实现)
大部分热门付费资源都有它的的免费版本，可以先尝试试用一下再决定是否购买

我一般会时不时看一眼 https://node.green ， 还有的时候要维护一些老的 node 版本的项目，也可以扫一眼看看能不能直接用。

简单翻了一下，粗浅的理解是`<span>{a}</span>`中的{a}看似是一个闭包捕获，但其实本质上是函数调用`React.createElement("span", null, a)`中的一个形参
于是在后续逻辑中` <span>{a}</span>`中的 a 和`setInterval(() => { console.log(a) }, 2000)`中的 a 基本上没有任何关系，产生上文所说结果就是很自然的了

一楼说的或许是这种
A.pipe(mergeMap(valueA => forkJoin([B, C, D]))).subscribe(([valueOfB, valueOfC, valueOfD]) => {});

简单来说，
let result = yield func()
此时 result 的值和 func 的返回值没有丝毫关系，你如果在看书的话可以接着往下看，yield 的作用只是暂停当前生成器的运行然后等待下一次的 next 调用，并把下一次 next 调用传递的参数传递给 result ，你可以参考一下下面的例子

function doSomething() {
setTimeout(() => {
gen.next("result")
},0)
}

function* generatorFunction() {
const result = yield doSomething()
console.log(result)
}

var gen = generatorFunction()
gen.next()

这个问题我们之前和团队里的朋友也有一个激烈的讨论，讨论的焦点就在于，
给定一个这样的路由，/book/{bookID}，当 bookID 不存在的时候，是直接给一个 404 还是返回 200 用 Body 中的一个自断来传递错误信息。
我个人理解后面的那种做法，借楼问一下大家，
- 这时候给 200 返回值总感觉有点奇怪，是否给 400 会更好一些？
- 如果错误时返回一个特殊结构的 Body ，是否有必要在正常返回的时候也额外包装一层，比如说{error:null, ressource: T} ?

之前用过 Packet Sender ，支持 TCP 和 UDP

Unity Editor 主要吃 CPU 性能吧，MAX 和 PRO 应该只有在 Play Mode 有性能区别，而且这点性能区别也可能被 Play Mode 一些 Debug 功能吃掉，体感上的提升可能不是那么大。

但是既然买了，就别换呗，16 寸用起来肯定比 14 寸更舒服。

PS 2020.2.xf 版本是真的不稳定

- 纯前端开发， 配合 VSC 和 WebStorm ，体验只会比 Win 本好不会更差
- 纯 Node 开发，同上
- 涉及 Node Native Modules 开发，请做好和工作流有关的调研
- 工作流强烈依赖 Docker ，请做好和 Image 相关的调研，有 x86 工作站 /服务器可以忽略本条，mac 本地当成一个 docker client 即可
- 反正我现在基本用不到本地的 Docker Desktop ，因为兼容性实在是个问题

- Jetbrains 系 IDE 目前重度使用过 WebStorm, PyCharm 和 EAP 版本的 Rider ，PyCharm 经常无法连接到 Debugger ，需要重启才能运作，目前没找到什么 Workaround ，不知道是系统问题，Python 版本问题还是 PyCharm 问题

@svampire 是的，而且 2021.2 系列的版本使用的体验真是一言难尽，BUG 贼多，只能说勉强能用

@luozhiyun 兄弟观察的挺仔细的，手头的 16 寸还留着，以防真的遇上了解决不了的问题。不是什么上得了台面的游戏，小众圈子里圈地自萌罢了
@link1994 平时社交圈过于狭窄，一直没有遇到心水的女孩子。的确，不做开发的话我宁可搞一套 ROG ，同价格配置可以直接起飞

@BlackJac95 国内没啥人用 Nest 吧，感觉 egg 更主流一些，我们是因为首席架构特别喜欢 Nest ，所以没得选

@zhpalt 对，本身就是原型项目，主要还是测试新的 Native Unity Editor (2021.2.2f)，大项目还是用着之前的 LTS 并没有迁移到这台电脑上

@zhpalt 这是我最近七天的内存压力曲线，很少有超过 25%的情况，基本开发场景是
- Jetbrain rider x2 一个客户端，一个服务端
- Unity 2021.2 x1 开发游戏
- Vscode x1 用来写一些脚本
- Docker for Mac 分配了 2G 内存，用来跑本地数据库

供你参考


Testflight 的话只有版本号改变需要审核，单纯增加 BuildNumber 应该是不会有额外审核的。

开箱即用的方法应该是不存在的。
要想避免 O(n)的查询复杂度的话，万变不离其宗的方法就是加索引，比较简单的就是加个对于 status 的倒排索引

倒排索引的 key 就是 status 的值，如下例子
[1] => {user1, user2, ...}
[2] => {user3, user4, .....}

如果服务器是 wsgi 的话，建议直接上 uwsgi 或者 gunicorn 来进行多 worker 部署，这两个都有能力部署多个 worker ，在实现接口的时候没那么多负担

我理解你的问题是，为什么 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%的内存

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