亮度真的可以调整的好高，自带的音响聊胜于无。

6.2 中午下单，6.4 中午到货，从浙江嘉兴发货，顺丰特快陆运，速度还是可以的，目前正在使用，多用用感受下效果。目前来看，用手机拍摄的显示器白色背景发黄，mac 偏冷的问题依然存在，和 dell 一样，但是颜色比较正，大小缩放会比 27 的戴尔体验更好，不用调整任何设置会比 dell 省事儿点，重量我感觉和 dell 的不相上下。 遇到一个问题是刚开始插上的时候，CPU 疯狂上升掉帧，现在没问题了。

显示器信息：
```
显示器：
彩色 LCD：
显示器类型： 内建视网膜 LCD
分辨率： 2880 x 1800 视网膜显示屏
帧缓冲深度： 30 位彩色(ARGB2101010)
主显示器： 是
镜像： 关
联机： 是
自动调节亮度： 否
连接类型： 内置
LG UltraFine：
分辨率： 3840 x 2160 （ 2160p/4K UHD 1 - 超高清）
UI 看起来类似： 1920 x 1080 @ 60.00Hz
帧缓冲深度： 30 位彩色(ARGB2101010)
显示器序列号： 203NTWG6J625
镜像： 关
联机： 是
旋转： 支持
自动调节亮度： 否
连接类型： 雷雳 /DisplayPort
```

@geniusmyn 会的，目前到货日期变成了预计 6.11 ，是顺丰快递，不知道送哪里发货，目前还看不到轨迹

@hun2008hun 带不动了吗，30hz 不太行啊，体验太差，需要试试 hdmi 或者 dp 吗

@IslandOwnerHuang 哈哈哈，我也是搜索看到的

@hun2008hun 可以尝试下 2304 * 1296 ，按住 option 点缩放

@hun2008hun 哈哈哈，分辨率你调整的多少？ 默认的感觉太大了。

@cedoo22 其实也没那么多要求，就是体感一个舒服，现在 mac 和 dell 视野切换的割裂感有点难受。

@INFP 一是这个价格超过我预期太多了，二是我看了下发货日期。。预计送达日期：8-10 周。。。

@INFP 收到，多谢多谢，我现在有点倾向 LG UltraFine 4K 了，因为想多用几年，如果现在买个不习惯的，到时候有好的想买，觉得出二手麻烦，还不如一开始买个自己觉得舒服的。在想是官网 24 期还是京东+额外售后。

@INFP 原价买 UltraFine 有点冤的，是啊，就感觉这显示器，都过了好多年了，还是这个价格，整体方面没太多提升。

@Davic1 我倒是没有 windows 对接的需求，就还好。Ergo 款是说 https://item.jd.com/100022498296.html 这个吗？ 不知道和 Ultrafine 4k 对比的效果如何，之所以对 Ultrafine 4k 有认知，是因为之前公司买过一台，确实用起来比较舒服。

@royantar 价格有点稍微超了，不知道 27B1U7903 体感和 Ultrafine 4k 差别大不大。

@INFP 确实，你说的对，我之前的习惯一直是写代码在 MacBook Pro 上，浏览器在外接显示器上，2 个显示器切换视野的时候，色差就非常不舒服，如果合上盖子只用外接 dell ，感觉自己亏了，另外请教下 UltraFine 是从官网买的吗？ 购买体验和售后上有没有什么问题可以分享~

建议参考下其他类似 saas 产品 api 的设计，作为一个平台，api 还是挺重要的

@Casbin API 所有的 url 设计都是 get+post ，path 上全是动词，实际可以使用 http method 来解决，model 好多是复用的，删除的时候也需要传入整个 model 吗？也没有写清楚哪些是必填的，example value 最好有一些真实的数据，会比较直观。response 也是一言难尽，都用的一个，data 和 data2 的作用分别是？

{
"data": {},
"data2": {},
"msg": "string",
"name": "string",
"status": "string",
"sub": "string"
}

没人吐槽下 RESTful API 吗

推荐 2 个 api 设计的指南，我会经常参考 google 的 https://cloud.google.com/apis/design?hl=zh-cn

微软 azure 的 https://docs.microsoft.com/zh-cn/azure/architecture/best-practices/api-design

另外有些场景想不太明白也会参考 https://docs.github.com/en/rest/repos/repos 和 https://docs.digitalocean.com/reference/api/api-reference/#operation/list_deployments

总是看到有人说 RESTful 不好用，复杂场景搞不定，自己思考过，参考过好的设计吗？

对资源设计不清晰，order 和 address 属于不同的资源，如果是修改用户的配送地址 put /users/:userId/address/:addressId 如果是修改某个订单的地址 put /orders/:orderId/address ，address 一般有单独的维护页面，用户可以管理自己的多个配送地址，这个地方是有 address id 的，而下单后，address 信息会固化一部分到订单中，用户有临时修改这个订单地址的时候，一般来说就不太用 adress id 了，一般来说是收货地址，如果是多个地址，那么也可以在 path 上再区分