如果是 27 寸的物理大小小了，那不清楚有没有更大一点的、5k 分辨率的。

@yhgogogo 小是指逻辑分辨率 1920x1080 小了，看的东西少了？感觉并不会。大多数网页和应用都是以 1080p 或者更小的 720p 为目标优化的。个人感觉会比较舒服。有机会的话你可以去试试。
另：MacBook Pro, 14-inch M1 Pro 屏幕的默认缩放下，逻辑分辨率为：1512x982 ，你也会觉得更“小了”、看的东西少嘛

@ccppgo PHP 还是强啊👍

跟我大学时刚接触的 PHP 相比，应该已经不是一个概念了

————
看了下，排名里你贴的这个 PHP 框架跟 fiber-prefork 的 QPS 基本一样了。确实很强。
Java 的好多异步框架名列前茅，后续 Java 17 （还是多少来着）的类协程语法支持好了后，应该真的大有可为了。
好多 PHP 的框架也都在 30w QPS 以上，这在以前真的很难想象，感觉在好几年前，就算是 php-fpm 也很难达到单机十几 w 的并发。时代进步真快。

有一次代码 bug 死循环了，C 壳接近轴的地方有点烫了，但丝毫风扇还是纹丝不动，键盘和触摸板区域有些温热

M1 Pro 14 寸 MBP ，冬天冰手，开多点 IDE 和连双屏后，情况有所缓解🐶还没听过风扇的声音，很怀疑这台电脑里是不是真的有个风扇（

@yhgogogo 200%，也就是类似 1920x1080 的 UI 。

运营商投诉呀，必须整改的

27 寸 4K ，大小正好，也没有颗粒感，眼睛看着舒服。

给家里人用也行啊。

如果确实不需要的话，损伤不太多的话建议出了或者回收了。应急备用机家里有个几百块老安卓够了。

如果是高并发服务的话，go 确实香，跑在老 i5 Mac 笔记本单机 QPS 20w+，内存占用 50M 可能还不到，静态编译体积几 M ，Docker 镜像只需要 from scratch 或 busybox/alpine ，也就是 jiM 到十几 M 大小（ hello world 应用 json 返回，fiber 框架）。

同样的服务用大家最熟悉的 Java Spring Boot ，可能只能几百一千 QPS 吧，内存占用几🐔，镜像体积至少小几百 M （即使只有 JRE+应用也挺大了）。

当然肯定会有人说，用 Spring Boot 比不公平，应该用 Vertx 之类的异步框架。不过现在主流 Java 版本写异步可能还是没那么顺手的，至少不像 go 那么顺手和自然。不然的话，可能 QPS 几 w 单机也还是行的，内存占用稍多些，JVM 本身启动开销大点。

如果不是高并发服务，而是业务复杂些的 2B 应用，go 因为设计比较简洁，写起来可能会非常啰嗦，语法糖各种没 JVM 系的 Spring 框架及 Kotlin 语言那么顺手。收益反而也比较小。（ go 开发难度增加很多，部署和运行时带来的收益可忽略不计）

以前我在 windows 上也一样，疑似是移动硬盘自己的策略？
老款 Mac 没出现过，是不是因为有后台读写？纯属猜测。没怎么在 Mac 上用过移动硬盘，没注意过。
以前用 windows 完移动硬盘上的游戏，为了防止硬盘睡眠导致加载卡顿，写了个批处理每 10s touch 一个文件，不过这个方法有点土，要求不高的话可以参考。

二开，二开。（

@Senorsen 靠又没打完。升级后：AMD EPYC 7K62 48-Core Processor

@Senorsen 上海五区

@Donahue 我升级前，Intel(R) Xeon(R) Gold 6133 CPU @ 2.50GHz

M1 Pro ，没有你这些硬件问题，但有个很致命的系统问题：用久了（其实也才几天不关机而已）后内存泄漏，在中文输入法下一切动画都会卡顿，中文打字非常卡顿。彻底关闭对应程序（如 Chrome 微信 VSCode ）后对应程序的中文打字暂时恢复正常，但很快（ 1 天）会卡回来，重启整个系统后恢复的久一点（几天，不到一周）。

尽早换，坏道会越用越多