对比字体渲染效果 不是应该
相同字体(如小米字体 MiSans 俩系统都改字体)
相同网页(或能调排版的软件)调好 css 字体参数(大小间隔字重等等)
同一屏幕下(24 寸 4k 苹果 hidpi 微软 200%缩放)
用手机的微距镜头拍屏幕字体吗？(非截图)
把结果图放上来 一切不就清楚了

我对现今 macOS 了解不深 还停留在几年前的黑苹果印象 但当时就是同一屏幕下(24 寸 4k)双系统(虽然都是默认字体)
因为是普通 IPS 屏 没有 oled(紫边)或其他屏幕等像素排列之类的差异
感觉苹果 UI 很舒适很有设计感和整体性 但别人提到的字体渲染问题 我感觉两者都足够清晰锐利 没有字体边缘的各种问题(不过我更喜欢苹果默认字体)
(可能印象模糊了 但 Win10 的 1909 到现在 Win11 的 23H2 我感觉新软件的高分屏缩放导致的问题愈发减少了 至少现在很舒适)
所以我的个人浅显的主观结论是 Win 的 200%缩放下字体没问题 retina 级别屏下与 masOS 差异不至于有一眼的差距

@caobug #22
有讲清楚了就好 能对别人有帮助还是很开心的 : )

Rust 文章的话 不太好写 写起来时很难兼顾到不同熟练度的 Rust 小伙伴（主要还是我自己能力有限）

举个例子
就像一开始其实我想**直接**用 `while true {}`和`loop {}`为什么不一样 来解释这问题的（前者迭代 0+次 后者 1+次）
但是这样会引入题目中没提到的 while 语句 以及它们另外的差异（ loop-break <value>能返回值而 while 恒为`()`之类的） 最后还得再迁移到 for 语句来解释

这样就有可能将问题复杂化了 而如果跳过中间例子直接说“const_expr 在 borrowck 阶段不求值” 不熟悉的小伙伴有可能一下子转不过来

且问题涉及 if 语句 所以最后决定用`if false {}`作例子来渐进地解释 比较好理解

Rust 文章同理 讲一个点 从多浅讲到多深 我就有点犯难了
有的知识点实在涉及太多 比如 Pin 感觉没十几页纸实在讲不清楚 一想就头都大了 0.o

@DianQK #21
嗯呐 这个确实就是关键所在

若我没记错的话 似乎 rustc 的编译流程会有两次的常量折叠/传播 一次是在前端的 MIR 中 另一次是在后端如 LLVM 中
（好像是前端优化一次能降低给后端的 IR 代码复杂度）

MIR 中支持常量传播应该是比较早前的事了（或许有相关公告） 似乎是支持控制流的（代码可能在 mir 部分的 const_prop.rs ？文件名应该长得差不多）
但并不知道是否支持“消掉 if const_expr”的行为
（我不知道这种分支优化的术语应该是什么 死代码消除 Dead Code Elim ？或者是叫 Sparse Cond Const Prop ？中文可能是 稀疏条件常量传播 之类的 或许也不准确）

但比较尴尬的是 常量传播是在 MIR 的优化阶段进行的 而 borrowck 是在 mir-opt 之前进行的（如果我没记错的话）

所以正如老哥你所说的 常量传播时应该已经有借用检查了
（以及我感觉理论上应该确实是能在借用检查前算 const 的 就是不知道最终会不会增加 MIR 部分编译的总耗时）

编译流程层面的改动影响对 rustc 而言还是挺大的（如 Polonius 也只是 borrowck 部分的平替） 所以短期内可能不会有相应优化了（个人感觉 不知道目前有没有人提对应的 RFC ）


以上的话并不严谨 我也暂时没能去进行校验 或许会有些错漏或过时（记忆有点旧了）

有条件的朋友或许可以补充下相关链接~

@DianQK #17
或许有些区别
简单点概况，NLL(Non-Lexical Lifetimes)的迭代进化(即下一代的 Polonius)应该依然并不能解决此问题。

因为楼主这问题本质上是 rustc 编译流程的限制。如图： https://blog.rust-lang.org/images/2016-04-MIR/flow.svg
根据**目前**的编译流程，Borrow Checking 发生在 MIR 阶段，此刻的 CFG(Control-Flow Graph)仅将`if true {}`识别为`if some_cond {}`。
故而`if true { <code> }`无法等价于`loop { <code>; break }`或`{ <code> }`，因为它们的 CFG 是不一致的。（参考引用 数据流分析中的 CFG ）
最后将类似`if false {}`这样的死代码消除的优化行为，是在 LLVM 的 codegen 优化阶段进行的，所以此前 borrowck 并不认识"true"或"false"。

在 Rust 2018(Rust 1.31)引入 NLL 后，生命周期的推断精度更高了，而下一代的 Polonius 会支持更复杂的控制流(Control Flow)。但是如上所述的原由，依然不能在此阶段进行条件求值，所以问题依在。

* NLL: https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes
* 编译流程中的 MIR: https://blog.rust-lang.org/2016/04/19/MIR.html
* 数据流分析中的 CFG: https://github.com/rust-lang/rustc-dev-guide/blob/master/src/appendix/background.md#what-is-a-dataflow-analysis
* rustc 概览(包含各编译阶段): https://rustc-dev-guide.rust-lang.org/overview.html


我希望能由浅入深解释问题，但无法太深。前面的回答并无涉及到更多的编译器部分的具体内容，是因太冗长容易导致阅读阻力大，很少人愿意认真看(完)。（但即使现在这长度，似乎大家也习惯 tl;dr 了）

希望我有解释清楚。 : )

FIX: @buxiuxi 第 9 项忘 at 了

综上

6. 楼主的代码符合 Rust 的所有权规则吗？符合的，因为问题并不在所有权转移上，而是在编译期所有权检查时是否会进行具体求值的判断上。

7. @DianQK 所以**目前**而言不是 bug ，或许以后编译器更聪明效率更高了就支持此优化了。

8. @binhb @qdwang @rrfeng 的说法是对的。

9. 为啥这里 release 函数会释放 dog ？因为 fn release(self)的参数是 self ，跟 std::mem::drop()一样，调用时会获取其所有权，并在此函数结束后 drop 掉。

续上

3. 对于 Code 3 ，即楼主的第一次修改尝试，实际上等价于将 loop 和 break 去掉（因为此控制流总是执行），所以必然会执行赋值语句，故而编译通过(Ok)。

4. 对于 Code 4 ，即楼主的第二次修改尝试，依然可以将 loop 和 break 去掉，此时情况等价于 Code 0 ，所以一样是编译不通过(Error)。

5. 对于 Code 5 ，即 @Kaiv2 提到的编译成功的写法，因为 break 进去 if 里了，情况就不一样了。此时控制流的逻辑只有两种情况：情况一，若不进入 if 语句里，则无限循环，那么就不会执行后面的使用 person 及 person.dog 的代码了，就没问题；情况二，进入 if 语句，则成功执行赋值，且最后必定 break 出去，执行后面的代码，依然没问题。所以这种不涉及对具体求值有依赖的控制流是能编译通过的。

回到原问题，person.dog 的各种赋值写法：
https://i.imgur.com/Bs5I6kb.png

0. 对于 Code 0 ，即上一条回复提到的本质问题，此处尽管写着 if true ，然而 Borrow Checker 并不默认此代码总是执行，而是认为可能执行也可能不执行。（当然，当 build release 编译优化阶段时，if true 就会被优化掉了，而所有权检查阶段并不会，或许是太耗时了）

1. 对于 Code 1 ，与 Code 0 本质一样，Borrow Checker 会认为此 for 语句可能不会执行，所以“Rust 的检测器似乎没有认真评估 for 中的条件”确实是对的，并不会在此阶段评估。

2. 对于 Code 2 ，因为有 else 分支且调用 unreachable!()，所以理论上后续使用 person 时必然已经经过 if 部分的赋值语句（因为 else 部分会 panic ，即不会执行后面代码）

直接简化问题，此问题本质上，与下面代码无法编译通过的原因是一致的：
https://i.imgur.com/IH475bN.png

**即在编译期 Borrow Checker 是不进行具体值计算的。**

如上面的 if 分支，在生命周期检查期间，并不知道 1 == 0 总为 false 且永不执行此代码块。故而在使用 name 时，无法得知所有权是否已被转移。
甚至将 1 == 0 直接换成 false ，此期间 Borrow Checker 依旧不知道 false 总不执行代码块，即认为是**有可能**调用 drop(name)触发所有权转移的。

@uni @lanlanye @sdsaaeee 我也是因为新的类型标注功能，在今年将 3.8 升到 3.11 了。

目前截至 2023 年 10 月份，对 3.11 而言，库的兼容程度比预想中的要好。

@Mohanson @youthfir 另外 PyTorch 2.1.0 Stable 版本昨天发布了，已经支持了 Python 3.11 ，或许可以考虑升级了~

[PyTorch 2.1: automatic dynamic shape compilation, distributed checkpointing]( https://github.com/pytorch/pytorch/releases/tag/v2.1.0)

[Support Python 3.11 #86566]( https://github.com/pytorch/pytorch/issues/86566)
e

@kneo 对于前者，是的，GIL 都在。

原话的完全句子是 _“目前的 Per-Interpreter GIL 子解释器仅供使用 C-API 创建，而暂时并不支持仅使用 Python 代码创建。所以编写纯 Python 代码时 GIL 对多线程并行的性能影响尚在。”_ （请原谅我的措辞不当）

Faster CPython 的 Plan 中有提到使用 Python 代码创建此类子解释器 [Enabling subinterpreters from Python]( https://github.com/faster-cpython/ideas/blob/0905dcc8ba76ff1f49b173437f4bc9359aa5ca19/3.13/README.md#enabling-subinterpreters-from-python) 。

对于后者，是今年 1 月份创建的 PEP 中 [PEP 703 – Making the Global Interpreter Lock Optional in CPython]( https://peps.python.org/pep-0703/) 提到的，但是否真能在明年 3.13-rc 版赶出来，感觉持悲观态度，要实现 `--disable-gil` ，看起来难度并不低。

@Kirscheis 现在能类型标注的都会标上 但写 Python 又希望简短精炼 写起来总有种左灯右行的冲突
(type hints 冗长显眼 typeCheckingMode 开 strict 时外部库对类型标注支持又不好一片标红 看着血压拉满)

@Muniesa 是的 以前都单层嵌套的单引号套双引号 想再嵌套都会考虑拆开写
3.12 的 f-string 可能更依赖语法高亮了

补充：
曾经 vp9 和 opus 主要是封装到.webm 及.mkv 里 后面似乎两者都补上了支持.mp4 容器

但添加"--merge-output-format mp4/mkv"参数时 yt-dlp 似乎依然为 vp9 和 opus 保持优先 merge 为".mkv"
而"--merge-output-format mp4"则可以强制 merge 为".mp4" (ffmpeg-v6.0 其他版本未测试)

yt-dlp 默认参数是 --format "bestvideo*+bestaudio/best"
(另外有默认的 Sorting Formats 参数 则确定“谁画质音质更好” 这个 bestxx 就是按此默认排序挑选 当然你可以改)

斜杆后的"best" 指有音轨的视频如 编号 22(720p mp4a.40.2) 就直接使用".f22.mp4"作为最终文件".mp4"而没有合并步骤(如无额外嵌入需求)

但一般先匹配斜杠前 而斜杠前半段就是“最佳视频轨道”和“最佳纯音频轨道”

如油管 4k 视频：
一般最佳视频轨道是 编号 313(VP9 的 2160p 纯视频 封装为.f313.webm)
一般最佳纯音频轨道是 编号 251(Opus 的纯音频 封装为.f251.webm)
然后 yt-dlp 默认会自动 Merge 两者 封装格式依然是.webm (Ref: https://www.webmproject.org/about/)
所以最终的".webm"文件就是包含上述两者的你想下载的有声音的视频了

如果你想封装为其他格式 可以考虑设置如下参数：
--merge-output-format mp4/mkv (如上述例子有 vp9 结果就会自动合并为".mkv"文件)

如果最终只有".f313.webm"和".f251.webm"文件 且没合并
那可能是参数设置问题(可用--verbose 看 log 判断)
或者是 ffmpeg 等合并工具出了问题

(*没仔细校验每一句话 但大致应该是没问题的 以上)

情况类似 做过一些尝试 结论如下
1. 显示器插独显上 那么就放弃 Chrome 走核显硬解 AV1 因为解完还得花 CPU 精力 Copy 到独显再输出 流程复杂会卡顿 所以只能 Chrome 正常走独显 软解 AV1 只要 CPU 够强 8k60 也是可以的
2. 显示器插主板上(核显) Chrome 也走核显(UHD770) 那么直接硬解 8k60 的 AV1 就 ok 了 Chrome 的 F12 里的 Media 会显示硬解 确实很流畅

但除非纯看 AV1 视频 否则 2060S 不就等于没有吗
(*双显示器一个接核显一个接独显尝试过确实是可行的 但对各方面兼容性等持怀疑态度)

油管 8k 基本是 AV1 而目前软解 8k 的 AV1 不算容易 要性价比只能硬解

亲测 UHD770 硬解 8k60fps 的油管 AV1 没任何问题(双通道高频内存) 显示输出当然也是支持 4k 的
那么合理推测 Intel UHD Graphics 730 是没问题的(看论坛讨论也证实可行)

所以个人结论是 i3-12100

Python 3.11 没赶上 Ubuntu 22.04 LTS 有点可惜

不知道即将到来的 Fedora 37 是否会用上 Python 3.11.0 (测试版似乎带的是 Python 3.11 rc 版)

@zhlxsh 一直在 3.8.10 目前不敢乱动