补充一些资料。

苹果向媒体 9to5Mac 确认，后续固件更新会给 MacBook Pro M3 机型带来盒盖输出 2 台显示器的功能。
https://9to5mac.com/2024/03/04/14-inch-m3-macbook-pro-multi-display-support/

Asahi Linux 开发者表示该功能在 M2 上已实现。M2 的 Mac mini 支持通过 USB-C 同时输出 2 台显示器，而 M1 的 Mac mini 只能通过 USB-C 输出一台，另一台显示器需要接到 HDMI 。
他认为苹果是能将此功能 backport 到 M2 MacBook Air 和 MacBook Pro 机器上的，只是他对此表示悲观。
https://social.treehouse.systems/@marcan/112039424335241551

等拆解吧，也有可能是 MUX 芯片。

@aquatichunter chrome://flags/#windows-scrolling-personality

https://v2ex.com/t/1016076#reply25

Chrome 解码 YouTube 的 av1 流能较稳定浮现。Google 已知此问题。
https://issues.chromium.org/issues/40075992
https://issues.chromium.org/issues/325934989
https://issues.chromium.org/issues/325741616

给大家说下后续。
Google 已知此 bug ，会关掉 macOS 平台的 av1 硬解测试并尝试在版本号 122 或 123 中解决。

https://issues.chromium.org/issues/40075992
https://issues.chromium.org/issues/325934989
https://issues.chromium.org/issues/325741616

我的指纹也是，甚至可能录上两分钟后就无法解锁了。
目前的解决方案是用指关节背去录。

@zaizaizai2333

再测试了一下，可能是 Chrome 的上屏时候出了问题，Stats for nerds 没有报掉帧，但是掉帧观感是肉眼可见的。
刚刚用 yt-dlp 下载了流 ID 为 399 的 1080p av1 的源测试，QuickTime 播放是不掉帧的。

这里是一个录屏，左边 QuickTime ，右边 Chrome 播放同一条 av1 流（ 399 ）。
https://www.dropbox.com/scl/fi/68biyqqzpm9bija4gu64p/av1-chrome-framedrop.mp4?rlkey=plhpcldadxaytc5toqvuex2jj&dl=0

对上方一些回帖的朋友提供一些补充信息：
对于软解来说，M1 的性能已经足够 H.264 (AVC), VP9, AV1 4K 视频。
对于非 M3 的机器来说，Chrome 在遇到 AV1 时会用 libaom-av1 软解，所以肯定不会掉帧。
在 M3 系列上，Chrome 会调用 VideoToolbox 硬解，现代显卡/SoC 的硬解是一个单独模块，和 CPU 以及 GPU 的理论性能都没有关系。硬解是否掉帧只看其模块在设计时有没有 target 对应的规格。

M3 系列在硬解某些 YouTube 的 av1 流可能会掉帧。
Safari 的解决方式是遇到掉帧立刻切换为 vp9 ，Chrome 会一直以掉帧方式播放。
暂时的解决方式是安装 not yet, av1 插件暂时屏蔽 av1 流。
https://chrome.google.com/webstore/detail/not-yet-av1/dcmllfkiihingappljlkffafnlhdpbai

根据都市传说，此年间的 MacBook 去掉电池（或电池故障）靠 AC 供电时，CPU 只会运作在 800 MHz 。

友情提醒单卖的 Magic Trackpad 其 polling rate 是 90Hz （无论接 USB 还是蓝牙）。
笔记本内建的是 125Hz 。

使用者可感知的 UI 流畅性和单核性能是相关的。
Intel MacBook Pro 的 9 代 Coffee Lake i9 单核性能大概是 M1 的 2/3 。
在长时间运作或多线程运作时，Intel 的单核性能会因为功耗限制或散热限制，逐渐滑落到其峰值的 2/3 甚至 1/2 。M1 的 MacBook Air 只会降低 10% - 20% 左右。

装个 winget 就行了。winget 可以安装 msstore 里的软件的。

不好意思没看到远程也需要同一个账户，请忽略上述回答。

Windows Server + RemoteApp

@Pazakui1259
@coolmint
补充一下，从 Pixel 7 开始的 Pixel 手机也可以双 eSIM 在线了。楼主有双 eSIM 的需求也可以考虑一下 Pixel 。

就楼上的码率相关回帖做补充。

有损压缩中，不同编码间不能直接比较码率大小，但可以笼统来说 AAC 比 MP3 更符合人的听觉特性。

同种编码，使用不同编码器在相同码率下也会有不同的质量。
就 AAC 而言，业界领先的编码器为 Fraunhofer FDK AAC 和 Apple CoreAudio 。我没有找到应用 FDK AAC 进行编码的流媒体平台，但是苹果是肯定在 Apple Music 和 iTunes Store 中应用 CoreAudio 编码器的。

Google 在 YouTube Music 中使用的 AAC 编码器质量极低，256 Kbps 会员音质成品甚至不如免费能听的 160 Kbps 的 Opus 。

附一个 CoreAudio 和 FFmpeg 内置 AAC 编码器在 80 Kbps 下的对比
https://satellitemx.github.io/static/aac/

另附关于 Tidal MQA 分析
https://www.youtube.com/watch?v=pRjsu9-Vznc

@Explr
电脑不需要代理的呀，所有数据都是浏览器通过蓝牙从你手机拿的。
我的意思是因为你的手机的 Passkey 是存在 Google 账号里的，需要先从里拿数据所以可能需要代理。
你好像唯独没有测试电脑不开代理，手机开代理的情况吧。
iOS 设备的 Passkey 是存在 iCloud Keychain 或其他密码管理器里的，不需要代理。
国行 Android 手机我不太清楚。

扫码只需要蓝牙。
Google Chrome 只是可以通过手机上的 Chrome 唤起配对流程面去扫码而已，实际上还是蓝牙。
Passkey 是可以存在 Google 账号里并同步到其他 Android 或 ChromeOS 设备的，这种情况下可能是没连梯子导致网络请求失败？
Android 手机还支持作为硬件密钥，验证流程是很相似的，你得区分一下。