应该是和 go 的调用约定有关，只保存被调用者保存（ callee-saved ）的寄存器，调用者保存（ caller-saved ）的寄存器是由函数本身生成的代码自己负责的。

因为协程不是像线程那样由 OS 强行抢占的，是只有在特定的切换点才能切换，可以把这个切换的过程理解成一个特殊的函数调用 [而且 go 里面就有这么一个函数 runtime.Gosched()] 。caller-saved 寄存器如果需要保存的话，编译器会生成相应的代码，不用协程调度器保存。

@statumer 非整数倍缩放的情况就反过来了。

Windows 里主流软件基本都兼容系统的缩放（不分整数倍和非整数倍）。

Linux 里 Xorg 对非整数倍缩放的支持度几乎为 0 （不考虑先 2 倍整数缩放再 xrandr --scale 这种方式，这样相当于全局强行插值，所有程序都是模糊的，Windows 至少兼容的程序可以很清晰）。

Wayland 现在兼容性又不是很好，用个 Chrome 都容易出问题。

NetworkManager 的网络配置项是分用户级配置和系统级配置的。

你把 NetworkManager 里的 WiFi 配置设置成“所有人都可以连接”就可以不用登录也能自动连接了。（唯一缺点是 WiFi 密码会变成明文存储）

del 不是删除对象，是删除变量。可以近似理解成，语义上相当于一个更强的"=null"（和 Java ，C#等语言相比）.
就和你在 Java 里写如下代码一样：
AppConfig app = AppConfig.getInstance();
app = null;
这样做显然不会销毁单例。和 Python 里的这种情况是一回事。

@qbqbqbqb 再补充一下，PC 相对寻址其实是 64 位引入的，32 位里 offset(%eip)只能用在跳转语句上，所以 32 位里用的比较多的还是绝对寻址的方式。而 64 位的话就因为寻址范围的原因，PC 相对寻址更常用。

@qbqbqbqb 更正一下，偏移量是有符号的，所以 R_X86_64_32 的范围只有 2G ，上面错写成 4G 了

补充一下 x86 的几种内存寻址方式，总体上其实就 2 种（这里不讨论寄存器寻址和立即数寻址）：

寄存器相对寻址，AT&T 汇编写法是 offset(base, index, scale)
1 ）地址计算方法是 base + index*scale + offset
2 ） base 和 index 是寄存器，offset 是 32 位立即数（直接写在指令里的常数），scale 是 1,2,4,8 中的一个
3 ） scale, index, base 可以依次省略（ scale 默认为 1 ，其它默认为 0 ，有 base 的时候不能省略括号，否则省略括号），不省略 base 的时候可以省略 offset

程序计数器(PC)相对寻址，32 位写法 offset(%eip)，64 位写法 offset(%rip)
1) 中间那个特殊的寄存器是程序计数器（ Program counter, PC ），代表的是将要执行的下一条指令的地址。
2) 只能指定一个 32 位立即数偏移量，不能做其它计算。

全局变量的地址一般是写在 offset 的位置的。这就是为什么 x86 的 ELF 里就这几种寻址方式的原因。

@LotusChuan 你说的这种是基于 PLT 的相对寻址（ R_X86_64_PLT32 ），用于 shared 库的。

OP 说的 R_X86_64_PC32 是基于程序计数器（当前代码执行地址）的相对寻址，是用于可执行文件内部的，这种相对寻址不用修改任何东西。用这个的原因主要有两部分
1. 现在的操作系统为了安全，不仅 shared 库是随机地址加载（基于 PLT ，动态链接的时候需要修改程序里的基地址；这个特性称为 Position-independent code, PIC ），就连可执行文件本身的代码段、数据段也是随机加载（整体上加了一个随机偏移量，相对当前执行代码的位置不变，所以可以用基于 PC 的相对寻址，不用修改任何基地址；这个特性称为 Position-independent executable, PIE ）
2. R_X86_64_32 绝对寻址，全称是 32 位绝对寻址，使用的地址长度只有 32 位，能寻址的范围定死在 0x0~0xffffffff ，如果用这种的话程序的全局部分（代码段+数据段）就只能使用低 4G 的虚拟地址空间了；而 R_X86_64_PC32 虽然寻址范围也只有这么大，但它的寻址窗口是随着当前执行代码的位置滑动的，整体上可以寻址范围更大。

至于为什么只有这几种寻址方式，是因为 x86 指令集里寻址的偏移量就只有 32 位。
如果需要用 64 位绝对寻址的话，就需要通过寄存器来相对寻址，原来 1 条指令变成 2 条（先把 64 位地址加载到某个通用寄存器，再执行想要的计算），效率比较低，所以只有必要的情况才会用这种方式。默认情况下程序都是用的上述几种 32 位偏移量的方式。

@zlstone 现在 GitHub 账号设置里面有一个是否允许用自己的代码仓库训练 Copilot 的选项

@css3 有的插件的格式化功能直接 new 的文件里是没有效果的（设置了语言也不行，比如 Python ），必须先保存一下才能用。

VSCode 有格式化功能，名称是 Format document （可以在 F1 命令面板里使用），快捷键 Alt+Shift+F 。

要安装对应语言的插件才能用。

用之前要先保存文件，直接 new 的文件不行。

所有方法都 O(1)是不行的
可以做到所有方法都是 O(log n)

主要有两大类：
* 跳跃表（ skip list ），单次操作时间复杂度为期望 O(log n)，实现较为简单
* 带有 order statistics 的平衡二叉搜索树（包括 AVL, 红黑树, Splay 等多种实现），根据实现的不同，单次操作时间复杂度为期望、均摊或严格 O(log n)，实现较为复杂

@archiyuan 下载个谷歌商店安装包就能启用的前提是需要手机本来就内置了谷歌基础服务。现在的华为手机都是不带这个基础服务的。

安卓 11 之后，手机不内置谷歌基础服务的话是肯定不能通过除了刷机以外的方法安装谷歌商店的。同时华为现在也不能解锁 BL 刷机。

“网络管理设置 DNS 不生效”检查一下是不是选项有错。

IPv4 的“DHCP”选项下手动设置 DNS 是附加 DNS ，原本自动下发的 DNS 仍然为默认 DNS 。
如果要强制使用手动设置 DNS 的话，要把地址获取选项设置成“DHCP ，仅地址”

同理如果有自动下发 IPv6 DNS 的话，GUI 里面 IPv6 的地址获取选项也要设置成“自动，仅地址”

总而言之就是，如果是应用层代理就需要解密 HTTPS ，可以监听。传输层（ TCP 代理）或者 TLS 层代理（ SNIProxy ）就不会中途解密 HTTPS ，不引起证书警告的情况下无法监听。

另外就是“HTTP 代理”尽管是一种应用层的代理协议，但它能够提供代理传输层的 TCP 流量的功能。

反向代理的话也要看实现原理。
如果是直接透传 TCP 或者 TLS 流量的，使用的就是后端服务器的证书，加密是从客户端到后端服务器直接建立的，无法监听。

如果是反代 HTTP 或者 websocket 的，反向代理就也需要自己的证书，并且只是加密上也是一段一段的，反代服务器可以解密出明文。

只说正向代理。
通俗地说就是“HTTP 代理”这种协议代理 HTTP 和代理 HTTPS 的原理是不一样的。代理 HTTP 时是代理服务器帮你向目标服务器进行请求（使用的是 GET POST 等方法）。代理 HTTPS 的时候是利用了 HTTP 里的一个特殊方法 CONNECT 建立一个 TCP 隧道，代理服务器实际上是在代理已经加密之后的的 TCP 连接，是无法监听里面的内容的。

（注意不是另外一种“HTTPS 代理”，现在一般都是用“HTTP 代理”通过 TCP 透传来代理 HTTPS 流量，“HTTPS 代理”很少见了）

备案扫脸是代替以前的幕布拍照的。如果不要扫脸的话就肯定要用幕布拍照。

如果你自己编译的 ip 命令没有链接 libcap 的话就不会有 drop_cap 这个功能