1. iPhone X 一直到 12 的刘海比例是相对合适的，虽然不完美，但刘海在短边上，顶栏还变厚了，用手机的时候对视线没那么大影响。
2. iPhone 13 系列把刘海变窄了，虽然屏占比变高，但视觉上更像是顶部缺了一块而不是屏幕向两角各扩展了一块，其实是变难看了。此前某些安卓手机极端追求屏占比结果搞得不伦不类也是这个原因。
3. MacBook 的屏幕刘海在长边，这个缺了一块的感觉会更明显，而且很容易注意到这个刘海。我已经用 SwitchResX 强制把分辨率改回 16:10 ，回到和 Intel 16 寸一样的显示效果了。感谢 MiniLED ，刘海那一栏不显示内容的时候完全不发光。
4. 既然能在笔记本上加刘海，那平板也不是不可以加刘海。平板的刘海只会比电脑和手机的更恶心——电脑不会竖屏用，手机只有看视频玩游戏的时候会横屏，而 iPad 刘海无论加在哪一边，总会有一批人大部分使用时间会被恶心。

单说通勤的话，北京可能比较难受，但是上海广州深圳应该还是能找到离公司不远的房子的。

YouTube Music 没有桌面客户端其实挺恶心的

现代文也没必要分。小学学语文老师就说过一群人既有男的也有女的就用「他们」，「他」这个字本来也没有男字旁，就应该男女都可以表述，省得用「他」指代女性还有人出来打拳

每当我坚定地觉得还在用 8G 内存已经是对 Mac 这个品牌的不尊重的时候，点开本站二手交易区和微博关注的几个买全新 /二手的博主，M1 Mac 清一色的 8+256 或者 8+512 ，极少见到 16G 内存

大幅增强多任务、后台能力，完整支持外接显示器，部分开放侧载权限，提高稳定性。至于上 macOS 就别想了，苹果不会这么做，作为用户也不希望如此

苹果的所有在线服务，最稳定的只有一个：APNs ，就是手机上的消息推送。其余的，抽风都是日常

@vain
阿里的所有服务都集成了这个东西，包括优酷啥的，特别恶心

@agagega
复杂的情况下你可以自己定义 Binding ，@ Binding 和$只是语法糖，Binding 的本质就是一个封装了 getter 和 setter 的对象： https://developer.apple.com/documentation/swiftui/binding

@MakHoCheung
SwiftUI 有 @ Binding 这个东西，如果你的 User 是 struct 并且 user 是 @ State ，那可以直接$user 传给子组件，子组件 @ Binding user: User 。这种情况因为都是值语义所以不需要定义 ViewModel 了

我没能太理解你的问题。

@ ObservedObject 和 @ State 标记都是用来做数据绑定的，View 里如果引用到了这些标记的变量，当它们改变时，View 也会对应更新。

之所以要区分 ObservedObject 和 State ，是因为 Swift 不同于 JS ，是一个严格区分值语义和对象语义的语言。Swift 中，struct 和大部分没有 NS 前缀的内置类型都是值语义，即任何一部分被修改了都会视为整个对象被修改；而 class 和 Foundation 里 NS 开头的类型都是对象语义，对它们属性的修改并不会被视为对整个对象的修改。

因为 MVVM 的核心就是追踪绑定数据的改变，所以 SwiftUI 必须区别对待值语义变量和对象语义变量。对值语义用 @ State ，任何修改都会简单触发 View 重新渲染；对对象语义用 @ ObservedObject ，被它修饰的类型都要满足 ObservableObject 这个协议，这些类型中任何被 @ Published 修饰的成员发生修改，整个对象就会触发 objectWillChange 事件。

这和 ViewModel 本身没有关系，只是因为 ViewModel 本来就是我们自己定义出来封装事件逻辑的模块，所以通常会实现为 class ，然后加上 @ ObservedObject 做修饰。

SwiftUI 里还有个修饰符叫 @ StateObject ，也是修饰对象语义的，和 ObservedObject 的区别在于后者不会维护对象的生命周期，而 StateObject 在生命周期上和 State 类似，由当前组件来维护。

在 Mac 上用过 InkScape 和 GIMP ，都很卡，大概是优化不够。Windows 上没试过。相比 Qt ，GTK+更像是 Linux 环境里的原生 Toolkit ，也不意外

如果 Java 里面已占用内存超过这个最大值但是又不能 GC 怎么办？

👍看到越来越多 SwiftUI 写的作品

《 C++ for the impatient 》，有中文译版，不错的书

有时候我也很想搞 NAS ，但理清需求，NAS 说实话对现阶段自己而言还是就存存电影这种体积大又不需时刻同步的文件。个人文档体积小，但是需要经常在外面查看和修改，更适合公有云。

我用 OneDrive 超过十年了（当年还叫 SkyDrive ），十年前的文件还安然躺在里面，同时期电脑里的某些文件早就随设备变迁丢失。更何况目前很多所谓成品 NAS 软件水平根本不行（防杠：至少在我自己看来），App 体验别说和 Dropbox 这类做得好的比，和国内的微云比也没有多出彩，这还不提 OneDrive 和 Office 以及 Win/Mac 系统 API 的深度整合。可能这也是时常看到有人吐槽 Nextcloud 不稳定，但还是有很多人喜欢它的原因：生态。一些人觉得能有个稳定地方存文件就够了，另一些人想要完整的跑在自家服务器的个人云，本质需求不同。

所以我给自己折腾 NAS 定了原则：买硬盘可以，买主机可以，折腾开源方案或者自己动手写也可以，但不买某晖某通这种成品😁

这个文件已经是 v1 API ，被移除了： https://github.com/llvm/llvm-project/commit/6154c4115cd4b78d0171892aac21e340e72e32bd

应该是 Kaleidoscope 教程没更新

@Z5460520
抓着中介问房子是哪年装修的就行，自己基本也能看出来新旧。三年前市场上还有挺多刚装修好的新房间，经过两三年还在市场上，可以租了。