不知道 OP 是否看了 WWDC19 的演讲“通过 SwiftUI 的数据流”，这个是最初 SwiftUI 发布时苹果官方对于数据流的介绍。如果没有看过建议补一下 https://developer.apple.com/wwdc19/226 。苹果 WWDC 里的演讲虽然代码不多，但是概念讲解很生动。我认为这应该是学习 Swift 时选择的第一手资料，然后再去 hackingwithswift 等地方学习有经验开发者总结的教程。

上面链接里的教程由于是最早期的版本，个别 API 存在一些变动。比如里面提到的 BindableObject 已经更名为 ObservedObject ，@Published 属性引入后也不需要像视频里那样手动写更新了。

Apple Developer 里的学习资料很多，而且近几年的演讲视频都配了中文字幕很不错。不过因为一些术语也翻译成了中文，搜索起来有点麻烦。

@zj9495 我也发现 macOS 只需要添加服务器证书就可以用了，iOS 实际上会更严格一些，需要安装的是 CA 。

有两个可能的问题，一个是时间太长，另一个是 EKU 没有设置好，我觉得后者可能性更大一些。
iOS 的相关规定可以参考 https://support.apple.com/zh-cn/HT210176

苹果要求的 serverAuth EKU 应该无法直接添加给 CA ，所以需要多一个步骤。

1. 自行签署一个 CA
2. 用 CA 签署一个服务器证书，EKU 中包含 serverAuth
3. 为设备安装 CA 证书，NAS 使用服务器证书

具体教程可以看 https://stackoverflow.com/questions/21297139/how-do-you-sign-a-certificate-signing-request-with-your-certification-authority/21340898#21340898
注意回答中的代码有一行 extendedKeyUsage ，这个就是 EKU ，需要取消前面的 # 注释。其他的安装教程操作即可。

目前没有什么有效方案，我为此换了显示器。是否有这个问题要看型号，和品牌不完全相关，推测可能是色彩的某个方案存在兼容性问题。触发条件也不是非常明确，我之前是睡眠唤醒后经常遇到，显示深色内容时闪烁更加明显。要缓解的话只能关闭显示器电源，过一小会重新接上。

我以前遇到过，可能是 macOS 命令行的 bug 。

问题的追溯是这样的：首先 oh-my-zsh 在 shell 启动的时候会调用 git ，如果用的是系统自带的 git ，本质上是在调用一个 wrapper 去寻找 Xcode 路径里面的 git ，在重启后第一次执行这一过程耗时较长。

我印象中 Big Sur 时期会有这个问题，我升级到 Monterey 之后似乎没再遇到过了。

解决方法一是升级系统和 Xcode 试试。如果不想升级的话，可以安装 brew 里面的 git ，避免 oh-my-zsh 调用系统自带的 git ，这样就不会在重启后第一次运行时卡住。

MP4 是封装格式，内容主要取决于里面的视频流。QuickTime 自带录屏要保证实时性，编码速度不能慢，所以就没时间做很多压缩优化，码率就会高。所谓 FFmpeg 的转换格式，其实是给视频流重编码了，这时候重视的是质量和体积，所以可以用较长的时间来进行编码，而且 CPU 占用会非常高。

FFmpeg 可以也支持录像转封装和硬件加速编码，OP 可以试试别的参数，理解一下不同用法

直接从 App Store 下载的不能了，需要有砸过壳的未加密 IPA 才可以。这个目前只能通过越狱设备导出。

会让问题再晚 20 年被发现（

哪怕用 unsigned int 也行啊

查了一圈，Safari 目前恐怕还无法使用上这个功能。它目前已经实现的 API 是描述本地文件的对象 https://developer.mozilla.org/en-US/docs/Web/API/FileSystemHandle ，但是问题在于创建这个对象的方法还不支持 https://developer.mozilla.org/en-US/docs/Web/API/Window/showDirectoryPicker 。使用这套 API 的第一步就进行不下去了😂

App Store 下载 Xcode 真的折磨，万恶之源是在校验部分。首先是 IDE 里面的小文件极多，检验效率低，内部还有套娃的子模块也要独立的校验，这样递归下去几乎没完没了。

更坑爹的事情是，校验这么多文件对 IO 的压力很大，苹果为了“优化”用户的体验，把它设置成后台运行，限制了线程数和优先级，造成这一个过程龟速运行。这个后台好像是写死的，没有抢占，甚至电脑没有前台任务时，它依然坚持极低的资源占用。反正我是没有找到什么手段让它能多用点 CPU 资源赶紧完成，所以每次都是睡前放在那不管让它慢慢搞吧。

你自己也说了“如果不是系统阻塞，那我完全可以在线程内执行其他的，后面再回来执行”。其实协程就是对你这种做法的抽象，通过生命周期和上下文来更轻松地控制调度。这和你直接在线程内做非阻塞 IO 没有本质区别。协程的思想可以降低写非阻塞程序时的心智负担，提高可读性、降低出错的可能。

这是 bug ，一般是由访达扩展触发的。你去“系统偏好设置”-“扩展”-“‘访达’扩展”，看看有没有启用的扩展，都关闭之后重启电脑看看有没有恢复。我这边之前就是因为开启了 Keka Finder Integration 出现了图标异常。

看起来 nginx 做了设置，那可能就是 django 应用里没有处理好。我不了解这个框架，可以参照前面几楼里的说法，查查 django 的资料看看如何处理这个 proxy header 。

目测是 nginx 反代时没有设置好 header 。用户的访问通过 nginx 转发到 Django ，IP 当然变成了 localhost 。解决方法是在 nginx 的反代里添加有关来源 IP 的 header ，一般是叫 X-Forwarded-For 或者 X-Real-IP 之类的。网上应该能搜到更具体的教程。

这个我前几天也发现了，看了一下控制台，是 WebSocket 的问题。准确来说是当网络连接经过 socks 代理的时候，就会出现这种问题。

目前观察到的原因是 Safari 有一个试验性功能叫做 NSURLSession WebSocket ，字面上理解就是用了一套新的 API 实现 WebSocket 。从 macOS Monterey / i(Pad)OS 15 起，这个功能成为默认选项。实测关闭后就不会有这个问题了，相关讨论可以看 https://developer.apple.com/forums/thread/685403 。

所以解决方案有这两种：

1. 不使用 SOCKS 代理，而仅用 HTTP/HTTPS 代理；
2. 在 Safari 的“偏好设置”-“高级”里，勾选“在菜单栏显示‘开发’菜单”。然后在“开发”-“试验性功能”里，取消勾选“NSURLSession WebSocket”。

直接禁用进程的运行权限就行了。

$ chmod 000 /Applications/BaiduNetdisk_mac.app/Contents/PlugIns/baiduNetdiskSync.appex/Contents/MacOS/baiduNetdiskSync

在 macOS 上的话，~/Library 是没那么容易被删掉的。这些文件夹都有额外的 ACL 规则保护。在 home 下运行 ls -le 就能看到不少用户内置文件夹包含这样一条规则：group:everyone deny delete，这就会阻止非 root 用户的删除。