我比较推荐 24' 4k，因为高 dpi 显示效果和 mbp 的效果同样细腻。macOS 的话 27' 4k 应该也还行，不过没有试过。
2k 分辨率就不太推荐，因为靠近了或者遇到字体略小的文本眼细的情况还是能看清像素点的

楼主可以想办法应聘虾米音乐产品经理，然后就能提这个需求了

每天的帖子按照回帖数排序。
每天早上 8 点刷新。
所以你每天 7 点 59 会发现一大堆帖子
然后 8 点整后一个都没有了

记录时间然后比较时间差？

@verrickt 很简单，用 100 缩放的分辨率长宽乘 2 即可。比如 24 寸 1080p 就是 1920x1080 同时乘 2 为 3840x2160。13 寸常用分辨率为 1366x768，乘 2 就是 2732x1536。当然 pc 显示器和笔记本显示器也略有区别，pc 像素密度略低一点，大概在 96pixel/inch，24 寸 1080p 是大约 91pixel/inch。笔记本 13 寸 768p 密度大约是 117，比 pc 显示器略高一些是因为人眼比 pc 显示器更近。不过一般来说像素密度在 96x2 和 117x2 的 pc 显示器和笔记本显示器，200 缩放的情况下效果是比较理想的，比如 mbp 的 13 寸 2560x1600。

我有个吃灰的 1b+ 单核 700mhz，那来做代理转发发现处理速度到 500+kb/s cpu 就性能瓶颈了。。。

nginx 说不定比 python 还内存占用小

举个例子，某些单片机的 sleep 就是根据晶振频率来空循环一定次数实现的，这种肯定就不会也没法在 sleep 时干别的事

应该是会变慢的。
对于一般 web 项目基本影响可以忽略。
不过引擎支持总比 polyfill 看的顺眼。可能有实现方式上的优化。
像 async generator 这东西翻译之后可谓是相当的复杂

http 代理通常是代替你请求资源。https 因为证书通常只能用 connect 做转发。
所以步骤是客户机发送 connect 请求连接到代理，代理收到请求后简历到指定服务器的端口的连接，并双向转发 tcp 数据包。

因为 http(s)代理在完成 connect 部分后就相当于一条到指定主机端口 tcp 隧道。任何 tcp 流量理论上都可以通过此隧道转发。

飞利浦 优派也有。
只不过 dell 的 p2415q 最早出现而且品质也还可以。

不是做不出来，而是市场很小。通常笔记本屏幕缩放大多在 150%左右例如 13 寸 1080p，甚至 125 缩放例如 15 寸 1080p，13 寸完美 200 缩放要约 2732 1536 的分辨率。实际上达到这个像素密度级别的产品很难找到。普通笔记本的 150 缩放在很多情况下效果没有 200 缩放理想。

笔记本屏幕达到这个级别的产品通常价格都在万元以上，如 xps15 4k 系列，各种 3k 的 13 寸超级本

自己写中间件转换呗。。。mysql 和 node 又不知道你的 string 是不是合法的 json string，mysql 也没有 json 这个类型

UP2715K 是真土豪。。P2415Q 用户只能看看。。。

win shift s