@ecnelises
不好意思，没看到楼主后面的回复。但是 Firefox 设置关闭最后一个 Tab 后不关闭窗口，然后 Cmd+W 关闭不了窗口这个问题，好比改了设置又觉得原来的设置为什么没生效……或者，只能理解成 Cmd+W 快捷键在两种语境下冲突了吧。

另外有一篇很好地解释 macOS 和 Windows 在关闭窗口和退出程序这个问题上不同设计理念的文章，推荐给大家： https://www.zhihu.com/question/21143701/answer/2521552530

> 反光 mac ，虽然有 command+q 或 command+w ，但关闭逻辑混乱。不亲手试一次，你根本不知道逻辑是什么情况。比如在 firefox 下，command+w 关闭的是标签页，但是在 finder 下，关闭的却是窗口，而又有一些软件，并不是关闭，而是把软件最小化到 dock 而已。

这个哪里混乱了？就以你说的 Finder 为例，按 Cmd+T 可以出新标签页，而且 macOS 大量原生软件都是支持多标签页的，然后你会发现 Cmd+W 实际上关闭的就是标签页，只不过当只有一个标签页时就直接关闭窗口了，这和浏览器的逻辑是完全一样的（除了早期火狐，关掉最后一个标签页不会关闭窗口，而是打开一个空白页）。

> 再来说 command+q ，直接就把整个应用相关的所有进程都退出了，无法只关闭当前活动进程，而只关闭当前活动进程的快捷键竟然没有。更甚的是 command+q 在 command+w 的旁边，在 command+1 的下面，误触的概率极高，而一旦误触，你就要面临该应用的所有窗口所有进程都被退出。

所以很多软件会有 Cmd+Q 时确认的对话框。至于关闭某个特定进程，这个本来就不是通用系统快捷键应该做的事情，因为你并不知道同一个软件的不同进程之间会不会有什么依赖关系。Windows 也一样。

> 另外是否还有大神能否解决 mac 切换窗口后，要等上近一秒后才能输入的问题？

Cmd+Tab 和 Cmd+`切换都看不到这个现象，你指的是切换不同桌面吗？那也不用等上一秒。

鉴于 Rust 本来就受 OCaml 启发很大，Rust with GC 大约可以看作 OCaml 换个马甲。而 OCaml 也基本能满足楼主说的每点要求。

@ashong
多谢，以前还没听说过这俩东西

@libook
无意义文件这个问题确实不好解决，只能放在目录里藏起来作为软件私有的存储

19 年就想买，但觉得太贵了，20 年初在家办公望着笔记本实在憋得难受果断下单，用到现在感觉还不错。

面板啥的不太懂。功能上说这款显示器的优点在于支持 Thunderbolt 还带扩展口，并且和 macOS 深度整合（在控制中心调节亮度、支持自动亮度调节、适应 Mac 的原彩显示）。缺点就是连接 PC 很麻烦，最好用 Thunderbolt ，但除了 NUC 和笔记本，普通 PC 支持 Thunderbolt 的太少了。我在亚马逊买了号称支持双向 DP-C 的线，还没到货。

如果有什么可以改进的地方：支持更高功率反向充电、升级到 USB4/Thunderbolt4 、把那几个 5Gbps USB-C 口升级成 10Gbps. 其他也没了，毕竟不是苹果自家，不会把 MiniLED ProMotion 啥的加进去的，这个价格也拿不下。

不过我猜更有可能是这款显示器不会更新，慢慢淡出舞台。当年 Dell 的 P2415Q 传言会在 2019 年更新，这都三年了还一点动静没有，所以即使在 Mac 用户群里，24 寸 4k 也是个小市场吧。

Intel Mac 后期本来也没啥扩展性了（除了 Mac Pro ），所以也没啥必要怀念…

你想想为什么很少有用 Mac 做服务器的。虽然 Mac 和主机定位截然相反，但原因其实是类似的

终极方案：用 SwitchResX 把分辨率改回无刘海的，这样菜单栏就会自动下移到刘海下面

VBox 已经说明过了，自己是 x86 平台的虚拟机软件，不会继续适配 Apple Silicon

遥想 2014 年自己第一台 Mac 下单后到货前那个激动的心情，甚至睡不好觉，可以理解哈哈哈哈

@Jackhuang
可以的，在命令行程序里 Import 这个系统框架就可以了。理论上甚至可以封装成 Python/JavaScript 等语言的 API

Rails 的 ActiveRecord 基本介绍在这里： https://ruby-china.github.io/rails-guides/active_record_querying.html

其实 Rails 这套 ORM 也不是只能在 Ruby 这种高度灵活的动态语言里才能实现，至少大部分我感觉是可以在元编程和静态反射能力强的静态语言里实现的（比如 Rust ？）。其实写 Rails 的时候感觉这套理念也没有太出奇（毕竟 Active Record 本身其实也是一个设计模式的名字），但用其他框架的时候才意识到原来 ORM 可以做得这么水，哈哈哈。

其实 ORM 的一大痛点在于它的对象模型和 SQL 基于的关系模型并不兼容。如果放弃用面向对象建模数据库，而是在一个类型系统足够强大的强类型语言里（ C++模版？）对关系模型建模，也许是条好出路。

首先 iPadOS 就是 iOS 换皮，所以 1=2.

1.1 ，能否上架 App Store 仅和你使用的 iOS SDK 有关，比如今年年底可能 Apple 就会宣布所有新 App 必须使用 iOS 16 SDK 提交（和最低支持的系统版本不是一回事，注意），也就是说 App 必须使用 Xcode 14 构建。这是一环套一环的关系：Xcode 对运行的系统版本可能有要求，而系统版本可能对芯片有要求。所以如果以后某代 macOS 不支持任何 Intel CPU 了，而最新的 Xcode 又只能运行在这个 macOS 上，那就意味着 Intel Mac 就无法上架 iOS App 了。（不过应该是很久很久以后的事情）

1.2 ，Xcode 有完备的 AArch64/x86_64 交叉编译工具链，所以 M1 和 Intel 编译出的 Binary 是没区别的。

3.1 同 1.1.

3.2 ，Mac 开发会比 iOS 开发多一个构建选项，即你是要 Universal Binary 还是 Apple Silicon 还是 Intel. 不清楚现在 Mac App Store 是否有相关限制要求必须提交 Universal Binary ，不过这三个选项和你用 Intel 还是 Apple Silicon 没关系的。这点同 1.2.

3.3 上架 Mac App Store 会要求应用强制在沙盒环境，其他流程会比自己发行稍微简单些。自己发行软件需要通过自己的密钥签名，然后提交给苹果做 Notorization 扫描（和 App Store 审核不同，这个是自动的，一分钟就能搞定），完成这两个步骤用户就可以正常打开了。