CS | Orien Daily

🔑 Git reflog：误删分支后，Git 为什么还能救回来很多人以为，git reset --hard 之后，之前的提交就彻底消失了

Thu, 06 Aug 2026 03:00:58 GMT

🔑 Git reflog：误删分支后，Git 为什么还能救回来

很多人以为，git reset --hard 之后，之前的提交就彻底消失了。其实，Git 里的提交对象和分支名是两回事：提交本身通常不会被修改，分支只是一个指向某个提交的可移动指针。

git reflog 记录的正是这些指针曾经指向过哪里。执行 git reflog，你可能会看到类似 reset: moving to HEAD~3 的记录，以及操作前的提交哈希。找到目标哈希后，就可以用 git reset --hard <commit-hash> 把分支指针移回去；如果只是担心再次操作失误，也可以先用 git branch rescue <commit-hash> 建一个临时分支。

这个设计解决了一个实际问题：Git 允许你频繁重写本地分支历史，但不能因为一次误操作就立刻丢掉所有线索。只要旧提交还没有被 Git 的垃圾回收清理，reflog 就能提供恢复入口。

不过，reflog 是本地记录，不会随 git push 上传到远程仓库。换一台机器，或者仓库长期没有访问导致过期记录被清理，就不一定还能找到它。发现误操作后，越早查看 reflog，恢复成功的机会越大。

🧪 课后一题：你刚执行了 git reset --hard HEAD~3，想找回 reset 之前的分支位置，最可靠的做法是什么？

先执行

git reflog

找到 reset 前对应的提交哈希，再执行

git reset --hard <那个哈希>

，或先创建救援分支保存它。

💡 易混淆点：git log 展示提交历史，而 git reflog 展示本地分支和 HEAD 指针的移动记录，后者不是远程共享日志。

🔑 布隆过滤器为什么只能说“可能存在”当系统需要判断一个元素是否见过，直接保存完整集合可能很占内存

Wed, 05 Aug 2026 03:01:13 GMT

🔑 布隆过滤器为什么只能说“可能存在”

当系统需要判断一个元素是否见过，直接保存完整集合可能很占内存。布隆过滤器用一个位数组和多个哈希函数代替它：插入元素时，把多个哈希结果对应的位置设为 1；查询时，只要发现其中一个位置是 0，就能确定元素一定不存在。

但如果所有位置都是 1，也不能断言元素一定存在，因为这些 1 可能是其他元素共同设置的。这就是布隆过滤器的核心取舍：用很少的内存换取极快的查询，但允许出现“误报存在”。增加位数组长度或调整哈希函数数量，可以降低误报率；然而，简单地把某个位置改回 0 又可能误伤其他元素，所以普通布隆过滤器不支持安全删除。需要删除能力时，通常改用计数布隆过滤器等变体。

🧪 课后一题：如果布隆过滤器查询结果为“不存在”，这个结论是否绝对可靠？为什么？

可靠。在没有哈希错误和数据损坏的前提下，查询路径中只要有一个位为 0，插入该元素时就不可能把它设置为 1，因此它一定没有被插入；布隆过滤器只会误报“存在”，不会误报“不存在”。

💡 易混淆点：布隆过滤器的“存在”是可能存在，而“不存在”才是确定不存在；同时，普通布隆过滤器不能直接删除元素。

🔑 并查集为什么适合“连通性”问题，却不适合“路径”问题并查集（Union-Find / Disjoint Set Union, DSU）解决的核心不是“怎么走”，而是“是不是一伙的”

Tue, 04 Aug 2026 03:00:48 GMT

🔑 并查集为什么适合“连通性”问题，却不适合“路径”问题

并查集（Union-Find / Disjoint Set Union, DSU）解决的核心不是“怎么走”，而是“是不是一伙的”。当图上的边会不断加入，而你反复想问两个点当前是否连通时，如果每次都重新跑一次 BFS 或 DFS，代价会越来越高；并查集的设计思路更直接：它不关心整条路径长什么样，只维护每个点属于哪个集合。union(x, y) 把两个集合合并，find(x) 找到 x 所在集合的代表元，于是“x 和 y 是否连通”就变成比较 find(x) == find(y)。

它之所以高效，关键在两个优化。一个是 path compression：每次 find 时，把沿途节点直接挂到根上，后面再找就更快；另一个是 union by rank/size：总把更小或更浅的树挂到更大或更高的树下面，避免结构退化。两者一起使用后，单次操作的均摊复杂度接近 O(1)，严格地说是 O(α(n))，这里的 α 是反 Ackermann 函数，在实际规模里几乎可以当常数看待。这也是为什么 Kruskal 最小生成树、离线连通性判断、朋友圈合并、岛屿归类这类题几乎都会优先想到并查集。

但并查集的“快”，是靠主动丢弃大量路径细节换来的。它只告诉你两个点最后是不是在同一个集合里，却不会保留“经过了哪些边”“路径长度是多少”“谁是父谁是子”的真实图结构。所以它特别适合回答 connectivity，却不适合回答 shortest path、具体路径恢复、拓扑先后关系 这类问题。很多人一看到图连起来了，就下意识想用并查集一路做到底，结果在需要距离、方向、层次的时候才发现信息早就没被保存下来。

真正容易踩坑的地方，恰恰在这里：你以为自己维护的是一棵“树”，其实维护的只是一个“集合代表关系”。例如在 Kruskal 中，并查集只负责判断“加这条边会不会成环”，真正决定最小生成树权值的是排序后的贪心过程，不是并查集本身；再比如有些题要求删除边后的动态连通性，普通并查集不支持高效删除，很多时候要改成离线倒序处理，而不是硬在原结构上减边。换句话说，并查集很强，但它强在边界明确：只管合并与查询连通，不管路径语义。

🧪 课后一题：无向图有 6 个点，初始互不连通。依次执行 union(1,2)、union(2,3)、union(4,5)、union(3,5) 之后，1 和 5 是否连通？6 和 1 是否连通？答案：

1 和 5 连通，因为 1-2-3 与 4-5 在

union(3,5)

后合并成同一集合；6 和 1 不连通，因为 6 从未参与任何合并。

💡 易混淆点：并查集维护的是“属于同一个集合”而不是“图上的父子关系”或“实际路径”，find 出来的根只是代表元，不等于原图里的起点、终点或最近公共祖先。

🔑 write() 成功了，为什么文件还是可能丢？很多人第一次写文件时都会有一个直觉：write() 已经返回成功，数据就应该已经“进硬盘”了

Mon, 03 Aug 2026 03:00:45 GMT

🔑 write() 成功了，为什么文件还是可能丢？

很多人第一次写文件时都会有一个直觉：write() 已经返回成功，数据就应该已经“进硬盘”了。这个直觉是错的。write() 在大多数 Unix/Linux 系统里，通常只表示“内核已经收下这段数据”，而不是“存储设备已经真的写好”。内核之所以这样设计，不是偷懒，而是为了性能：如果每次写入都强行等硬盘落盘，程序会慢得像卡住一样。于是操作系统把数据先放进 page cache，等合适的时候再批量刷盘，这样吞吐量高得多。

这就带来一个非常重要的后果：程序看起来“保存成功”了，机器一断电，文件仍然可能丢，甚至可能只写进去一半。尤其是你在更新配置文件、日志文件、状态文件时，这个坑非常常见。很多人以为“我都 close 了，应该安全了吧”，也不完全对。close() 主要是释放文件描述符，刷盘可能仍然是延后的。真正要逼内核把修改推到稳定存储，通常要显式调用 fsync() 或 fdatasync()。

这也是为什么很多可靠软件不直接覆盖原文件，而是采用“先写临时文件，再 fsync，再 rename”的套路。因为 rename 在同一文件系统内通常是原子的：要么旧文件还在，要么新文件完整替换上去，不容易出现“文件存在，但内容只剩半截”这种恶心状态。不过这里还有第二层坑：你只 fsync 了文件本身，还不一定够。如果你新建了文件或者依赖目录项变化，目录也可能需要 fsync，否则断电后名字映射未必稳定。设计上这是把“数据内容”和“目录元数据”分开处理，目的是避免每次小改动都付出巨大的同步成本。

所以，write() 保证的是“本次系统调用把字节交给了内核”，不是“崩溃后这些字节仍然活着”。这套设计很实用，因为大部分写操作根本不值得每次都同步到底层设备；但一旦你在做配置保存、钱包、索引、状态机快照、提交记录这类关键数据，就不能再装作 page cache 和断电不存在。

🧪 课后一题：一个程序先用 write() 写完 config.json，然后立刻退出，没有调用 fsync()。如果这时机器突然断电，config.json 的新内容一定已经安全保存了吗？答案：

不一定。

write()

成功通常只表示数据进入了内核缓冲区，未必已经真正落盘。

💡 易混淆点：write() 成功、close() 成功、文件“看起来能读出来”这三件事，都不等于“断电后数据仍然存在”。

🔑 为什么“明明没共享数据”也会变慢：False Sharing（伪共享）多线程程序变慢时，很多人先怀疑锁、系统调用或者算法复杂度，但有一种更阴的情况是：线程之间逻辑上没有竞争，代码看起来也各写各的，性能却还是突然掉下去

Sun, 02 Aug 2026 03:01:41 GMT

🔑 为什么“明明没共享数据”也会变慢：False Sharing（伪共享）

多线程程序变慢时，很多人先怀疑锁、系统调用或者算法复杂度，但有一种更阴的情况是：线程之间逻辑上没有竞争，代码看起来也各写各的，性能却还是突然掉下去。这 often 不是“数据共享”，而是 cache line 共享，也就是所谓的 False Sharing。

现代 CPU 不会按“一个变量”来缓存内存，而是按一整块来搬运，常见大小是 64 字节，这一块就叫 cache line。假设两个线程分别修改 a 和 b，如果这两个变量刚好落在同一个 cache line 里，那么线程 1 一写 a，CPU 就会把这整行标记成自己最新；线程 2 再写 b，又会把同一行抢过去。于是两个核心来回“打架”，虽然改的不是同一个变量，但底层维护缓存一致性时，看到的是同一块内存，所以会反复失效、同步、重取，最后浪费大量时间在 cache coherence 上，而不是算业务逻辑。

这就是它名字里“false”的意思：表面上看像共享写入冲突，实际上程序语义上根本没有在争同一份数据。设计上，CPU 必须按 cache line 管理，因为按字节追踪一致性成本太高，硬件根本扛不住。所以这不是 CPU “笨”，而是工程上的现实取舍：用较粗粒度的缓存块换取整体吞吐，但代价就是程序布局不当时会踩坑。

最常见的坑出现在计数器、统计数组、任务队列元数据里。比如你开 8 个线程，每个线程维护自己的计数，本来以为不会互相影响，于是写成一个连续数组 counters[8]。结果这 8 个整数很可能挤在一两个 cache line 里，线程越多，互相打得越狠。解决办法不是“加锁”，那只会更糟；真正的修复方式是让高频写入的数据在物理布局上分开，比如 padding、按 cache line 对齐，或者干脆让每个线程持有自己独立的局部状态，最后再汇总。

但也别走到另一个极端。不是所有相邻变量都该强行 padding 成 64 字节，那会浪费内存，还可能让 cache locality 变差。关键判断标准很简单：如果多个线程会高频写，并且这些数据可能挨在一起，就该警觉；如果只是只读共享，或者很少修改，False Sharing 往往不是主因。

🧪 课后一题：有 4 个线程分别不停执行 cnt[i]++，cnt 是一个连续的 int cnt[4]。逻辑上每个线程只改自己的下标，但程序吞吐量很差。最可能的原因是什么？

4 个

int

很可能落在同一个或相邻的 cache line 里，多个核心频繁争夺同一 cache line 的写权限，发生了 False Sharing。

💡 易混淆点：False Sharing 不是“多个线程读写同一个变量”，而是“多个线程写不同变量，但这些变量落在同一个 cache line 里”。

🔑 并查集为什么几乎总和“路径压缩”绑在一起并查集解决的不是“找元素”，而是“判断两个东西是不是已经连在一起”

Sat, 01 Aug 2026 03:01:32 GMT

🔑 并查集为什么几乎总和“路径压缩”绑在一起

并查集解决的不是“找元素”，而是“判断两个东西是不是已经连在一起”。你可以把它理解成一堆集合在不断合并：今天把 a 和 b 连起来，明天把 b 和 c 连起来，后天再问 a 和 c 是不是同一组。如果每次都真的把整组数据搬来搬去，代价会很大，所以并查集故意只存一件事：每个点先指向一个“父节点”，最后一路走到代表整个集合的根。

它聪明的地方不在“能合并”，而在“合并很多次以后还能查得快”。如果你只是傻傻地把一个根挂到另一个根下面，树可能越长越歪，最后一次 find(x) 得一路爬很多层，性能会烂掉。路径压缩就是干这个脏活的：你既然已经顺着父指针爬到了根，那回头时就把路上的节点直接改成指向根。下次再查这些节点，基本一跳就到。也就是说，它不是靠更复杂的结构取胜，而是靠“查过一次就顺手把结构修平”。

这就是为什么并查集在动态连通性问题里这么常见，比如 Kruskal 最小生成树、朋友圈合并、岛屿连通、账号归并。真正重要的不是“集合”这个词，而是“合并关系会越来越多，查询也会越来越频繁”。路径压缩让这个结构越用越顺，而不是越用越重。

容易踩坑的地方也很直接。第一，union(a, b) 不是把 a 挂到 b，而是把 find(a) 的根和 find(b) 的根合并；如果你直接拿原节点乱连，整棵树就坏了。第二，路径压缩优化的是 find，不是 union 本身，所以很多代码看起来像“查找函数偷偷改了数据”，这不是副作用失控，这是设计本意。第三，如果题目需要维护集合大小、边数、权值差，你不能只会裸模板，因为额外信息要么挂在根上，要么在路径压缩时一起更新，不然答案会错得很隐蔽。

🧪 课后一题：有 6 个点，初始各自独立。依次执行 union(1,2)、union(2,3)、union(4,5)、union(3,5)。这时 1 和 5 是否连通？2 和 6 是否连通？答案：

1 和 5 连通，因为 1-2-3-5 已经被合并到同一集合；2 和 6 不连通，因为 6 从未参与任何合并，仍是单独集合。

💡 易混淆点：并查集只能高效处理“是否属于同一连通块”这类问题，不能直接告诉你两点之间的具体路径长什么样。

🔑 并查集为什么几乎总是“快得像 O(1)”很多人第一次看到并查集，会以为它只是一个“把元素分组”的小工具：find(x) 看看 x 属于哪一组，union(a, b) 把两组合起来

Fri, 31 Jul 2026 03:01:16 GMT

🔑 并查集为什么几乎总是“快得像 O(1)”

很多人第一次看到并查集，会以为它只是一个“把元素分组”的小工具：find(x) 看看 x 属于哪一组，union(a, b) 把两组合起来。真正有意思的地方不在功能，而在它的设计很狡猾。它不试图让每一步都绝对平衡，也不急着把整棵树修得漂漂亮亮，它只做两件事：合并时尽量把矮树挂到高树下面，查询时顺手把走过的路径压扁。结果就是，刚开始树可能有点歪，但你查得越多，它自己越像被“踩平”了一样，后面的查询会越来越短。

这就是为什么并查集常被用在连通性问题里，比如“两个节点现在是不是已经连起来了”“加上一条边会不会形成环”。Kruskal 最小生成树离不开它，图里动态判断连通块也离不开它。它快，不是因为每次都神奇，而是因为它把整理成本偷偷摊到未来了。你这次 find 多走了几步，没白走，路径压缩会让后面的人少走很多路。这种“顺手维护结构”的想法，比死记复杂度更重要。

很多初学者会背一句话：并查集时间复杂度接近 O(1)。这话不算错，但也容易把脑子带歪。更准确一点，它的均摊复杂度是 O(α(n))，这里的 α 是反阿克曼函数，长得很吓人，但增长慢得离谱，慢到你在现实里几乎可以把它当常数。所以工程上大家才会直接说“近似 O(1)”。但别把“近似”听成“真的随便写都行”。如果你只做路径压缩，不做按秩合并，通常也挺快；可要是两样都不做，那树就可能长成链，性能直接退化。

还有一个常见坑是，你以为并查集适合一切“分组”问题，其实不是。它只擅长处理“谁和谁连通”这种等价关系：自反、对称、传递。比如朋友关系、同一个集合、图的连通块，这些都行。但如果问题变成“谁比谁大”“依赖先后顺序”“最短路径是多少”，并查集就帮不上忙了。它只回答“是不是一伙的”，不回答“这伙人内部是什么结构”。

🧪 有 1,2,3,4,5 五个点，初始互不连通。依次执行 union(1,2)、union(2,3)、union(4,5)、union(3,5) 之后，1 和 5 是否连通？此时一共有几个连通块？答案：

1 和 5 连通；一共有 1 个连通块。因为前两次把 1,2,3 连成一组，第三次把 4,5 连成一组，第四次再把这两组合并，最后 1 到 5 全在同一组里。

💡 易混淆点：路径压缩不会改变“哪些元素属于同一集合”，它只是在重排父指针让树变矮；别把它理解成“额外做了一次合并”。

🔑 为什么 Shell 管道默认会“吞掉”前面的错误？在 Shell 里，很多人第一次写管道都会以为只要前面某一步失败，整条命令就算失败

Thu, 30 Jul 2026 03:00:44 GMT

🔑 为什么 Shell 管道默认会“吞掉”前面的错误？

在 Shell 里，很多人第一次写管道都会以为只要前面某一步失败，整条命令就算失败。实际不是这样。像 cat missing.txt | grep foo | wc -l 这种命令，Shell 默认只看最后一个命令的退出状态，也就是 wc -l。这意味着前面的 cat 就算已经报错，只要最后的 wc 正常结束，整条管道在很多脚本里仍然会被当成“成功”。

这个设计不是疏忽，而是早期 Unix 的取舍。管道的核心目标是把“数据流”接起来，让小程序像积木一样组合。Shell 把每个程序都当成独立过滤器，默认只关心最末端是否得到了可继续处理的结果，因为用户最常消费的就是最后一步的输出。这样做很简单，也兼容了大量老脚本，但代价是：如果你把它直接用于自动化，错误可能会悄悄溜过去。

真正踩坑通常发生在 CI、部署脚本和日志处理里。比如你写了 build_cmd | tee build.log，tee 几乎总能成功，于是即使 build_cmd 已经失败，脚本还是继续往下跑。表面看日志也有输出，实际上流程已经坏了。这种 bug 最烦人的地方就在于它不炸，它只是悄悄给你一个假成功。

所以后来大家常写 set -o pipefail。它的意思是：只要管道里任意一个命令失败，整条管道就失败。这样脚本才更像你脑子里想的那样工作。再配合 set -euo pipefail，Shell 会更早暴露问题，而不是帮你偷偷兜底。这里的重点不是“语法技巧”，而是态度：不要让脚本假装没事，错了就该尽快暴露。

不过 pipefail 也不是无脑全开就完事。有些命令失败是正常控制流的一部分。最常见的是 grep 没找到内容时会返回 1，这不一定表示异常。如果你开了 pipefail，又把这种返回值当成真正错误，脚本就会过度敏感。所以关键不是迷信某个选项，而是明确区分“业务上允许的未命中”和“真正的执行失败”。

🧪 如果执行 false | true，在 Bash 默认设置下整条管道的退出状态是多少？打开 set -o pipefail 后又是多少？答案：

默认是 0，因为只看最后一个

true

；打开

pipefail

后是非 0，因为前面的

false

失败会让整条管道失败。

💡 易混淆点：grep 返回 1 往往表示“没找到”，不等于程序出错；而 pipefail 关心的是退出码，不会替你判断这个 1 在业务上是不是合理。

🔑 为什么 epoll 不只是“更快的 select”很多人第一次接触 I/O 多路复用时，会把 select、poll、epoll 理解成“谁更快”的版本升级，这个理解太浅了

Wed, 29 Jul 2026 03:01:29 GMT

🔑 为什么 epoll 不只是“更快的 select”

很多人第一次接触 I/O 多路复用时，会把 select、poll、epoll 理解成“谁更快”的版本升级，这个理解太浅了。epoll 真正重要的设计点，不是把一个旧接口做了性能优化，而是把“每次都把所有 fd 扫一遍”改成了“内核记住你关心谁，谁真的就绪了再告诉你”。这背后解决的是工作方式的问题，不只是常数优化。

select 和 poll 的思路很直接：用户态把一批文件描述符交给内核，内核检查一遍哪些可读、可写，然后把结果返回。问题在于，这件事每次调用都要重复做，哪怕这 1 万个连接里只有 3 个真的有数据，内核还是得把 1 万个都看一遍，用户态也还得重新传一遍关注列表。连接数一大，开销就不在“读写数据”本身，而在“反复检查没事发生的对象”。

epoll 换了个思路。你先用 epoll_ctl 把自己关心的 fd 注册进去，之后内核替你维护这份关注集合。真正有事件发生时，内核把就绪的 fd 放进就绪队列，epoll_wait 取回来的就是这批“已经发生事”的对象。重点在这里：返回结果的规模更接近“活跃连接数”，而不是“总连接数”。这就是为什么它特别适合高并发但大多数连接都很安静的场景，比如网关、聊天服务、反向代理。

但 epoll 最常见的坑，不在 API，而在事件触发语义。尤其是 edge-triggered，也就是 ET 模式。很多人以为“来了一个可读事件，读一次就行”，结果程序随机卡死。原因很简单：ET 只在状态从“不可读”变成“可读”时提醒你一次，如果缓冲区里其实还有数据没读完，而你提前收手了，后面可能就再也收不到通知。正确做法通常是一直读到返回 EAGAIN 为止，把这次能吃掉的数据全吃掉。level-triggered，也就是 LT 模式，行为更像“只要你还没处理完，我就继续提醒你”，更稳，更适合初学时先把模型跑对。

所以，epoll 的设计哲学不是“帮你省一点循环”，而是把“关注集合”和“就绪结果”拆开，把重复劳动挪到一次性注册里，把运行时成本尽量压到真正有事件的对象上。这个思路在系统设计里很常见：别每轮都重新扫描世界，应该让系统在变化发生时主动暴露变化。

🧪 如果一个 socket 使用 epoll 的 ET 模式，并且一次可读事件到来后你只 read 了一部分数据就返回事件循环，最可能出现什么后果？

缓冲区里剩余数据还在，但因为状态没有再次从“不可读”变成“可读”，后续可能收不到新的可读通知，连接看起来像“卡住了”。

💡 易混淆点：epoll 更高效不等于任何场景都更快，真正容易搞错的边界是“连接总数很多但活跃很少”与“连接本来就不多”这两类负载完全不是一回事。

🔑 epoll 为什么快：它优化的不是“读写”，而是“等谁先准备好”很多人第一次听到 epoll，会以为它让网络收发本身变快了

Tue, 28 Jul 2026 03:01:09 GMT

🔑 epoll 为什么快：它优化的不是“读写”，而是“等谁先准备好”

很多人第一次听到 epoll，会以为它让网络收发本身变快了。不是。真正变快的是“找出哪些文件描述符已经就绪”这件事。在一个高并发服务器里，真正昂贵的往往不是 read 或 write，而是你手里有几万条连接时，系统每次都得回答同一个问题：现在到底该处理谁？

早期的 select 和 poll 很直接，但也很笨。你每次调用都要把整批 fd 交给内核，内核再从头到尾扫一遍，看哪些能读、哪些能写。连接数一大，这个“全表扫描”就开始浪费时间。epoll 的设计思路完全不同：先用 epoll_ctl 把你关心的 fd 注册进去，之后内核自己维护这批对象的关注关系；等某个 fd 真正发生状态变化时，再把它放进“就绪队列”。这样用户态调用 epoll_wait 时，拿到的不是“所有人里谁好了”，而是“已经好的那几个”。

这就是它快的根本原因：不是每次重新检查全部连接，而是把“关注集合”和“就绪结果”拆开。前者平时维护，后者按事件返回。设计上很像把“查名单”变成“等通知”，避免无意义重复劳动。这也解释了为什么 epoll 在连接很多、活跃连接相对较少的场景里特别合适，比如反向代理、聊天服务、长连接网关。

但 epoll 也不是用了就万事大吉。最容易踩坑的是 ET，也就是 edge-triggered，边沿触发。它只在状态从“不可读”变成“可读”时提醒一次。如果你收到通知后只读了一半数据就走，下次可能根本不会再提醒，你会以为程序卡死了。LT，也就是 level-triggered，水平触发，则更宽容：只要缓冲区里还有数据没读完，它就会继续提醒。所以很多线上 bug 不是 epoll 慢，而是程序员把 ET 当成 LT 用了，却没配合非阻塞 fd 和“循环读到 EAGAIN 为止”的写法。

再进一步说，epoll 的设计还体现了一个很重要的系统原则：把成本从“每次查询”转移到“状态变化发生时”。如果变化少、查询多，这种设计就赚大了；如果你的 fd 数量不大，或者本来就没什么并发，epoll 也未必比别的机制有决定性优势。工具本身没有神话，关键是它在优化哪一段路径。

🧪 如果一个 socket 使用 epoll 的 ET 模式，并且已经收到一次“可读”通知，但程序只读取了部分数据就返回事件循环，最可能发生什么？

缓冲区里剩余数据可能一直躺着，因为 ET 不会像 LT 那样持续提醒；只有再次发生新的边沿变化时才可能再通知，所以正确做法是配合非阻塞读并一直读到

EAGAIN

。

💡 易混淆点：epoll 快，不等于 read/write 更快；它优化的是“大量连接下寻找就绪 fd 的方式”，而 ET 与 LT 的区别也不是“一个更高级”，而是谁来承担“把数据读干净”的责任。

🔑 为什么 epoll 的边缘触发更快，却更容易把程序写挂很多人第一次学 Linux I/O 多路复用时，会把 epoll 的边缘触发（ET, Edge Triggered）理解成“高级版通知”，水平触发（LT, Level Triggered）理解成“普通版通知”

Mon, 27 Jul 2026 03:00:52 GMT

🔑 为什么 epoll 的边缘触发更快，却更容易把程序写挂

很多人第一次学 Linux I/O 多路复用时，会把 epoll 的边缘触发（ET, Edge Triggered）理解成“高级版通知”，水平触发（LT, Level Triggered）理解成“普通版通知”。这说法太糙了，真正的区别在于：内核到底是在“数据还没处理完”时反复提醒你，还是只在“状态发生变化”的那一刻提醒你一次。

先看水平触发。假设一个 socket 里已经有 4KB 数据没读走，只要这 4KB 还在，下一次 epoll_wait 仍然会告诉你“这个 fd 可读”。这种设计很啰嗦，但非常稳，因为你哪怕一次只读一点，甚至代码写得有点笨，内核也会不断催你把活干完。它像一个不会闭嘴的闹钟，代价是通知次数更多。

边缘触发反过来。它关心的不是“现在还有没有数据”，而是“从没有数据变成有数据”这个边缘。一旦 socket 从空变成非空，内核通知你一次；如果你这次没把缓冲区读空，剩下的数据还在，但因为“状态没有再次变化”，下一次未必还会提醒你。设计它的原因很直接：减少重复通知，减少用户态和内核态来回切换，让高并发服务器更省开销。

问题也正出在这里。很多 ET 程序挂掉，不是因为 epoll 有问题，而是因为程序员把它当 LT 在写。最典型的坑有两个。第一个坑是“收到可读事件后只读一次”。这在 LT 下通常还能凑合，在 ET 下就可能直接丢掉后续处理机会，因为内核已经提醒过你了。正确做法是把 fd 设成 non-blocking，然后在一次事件处理中循环 read，一直读到返回 EAGAIN 或 EWOULDBLOCK，意思是“现在真没了”。第二个坑是“收到可写事件后一直盯着写”。socket 可写往往是常态，如果你没设计好发送缓冲和事件注册策略，就会被大量无意义的可写事件拖死，CPU 空转得很难看。

所以 ET 更快，不是因为它神秘，而是因为它假设你更自律：你得一次把该做的事做干净。LT 则更像宽容模式，允许你每次只处理一部分，然后等内核继续提醒。写网络服务器时，如果你对事件循环、非阻塞 I/O、读写缓冲管理还不够扎实，先用 LT 往往更稳；如果你已经能保证“来一次事件就把状态推进到不能再推进为止”，ET 才值得上。

🧪 如果一个 socket 使用 epoll 的 ET 模式，并且已经收到一次“可读”通知，但你的程序只读了部分数据就返回事件循环，之后这个 socket 里剩余数据还没被读完，那么下一次 epoll_wait 一定还会再次返回这个可读事件吗？

不一定。ET 只保证在状态从“不可读”变成“可读”时通知一次；如果你没读到

EAGAIN

，剩余数据可能一直躺在缓冲区里，但因为没有新的状态变化，内核未必再提醒你。

💡 易混淆点：ET 不是“每来一个数据包通知一次”，LT 也不是“性能一定差”，真正边界在于你是否把一次事件处理到 EAGAIN 为止。

🔑 为什么 SSH 第一次连接会问你“Are you sure you want to continue connecting”很多人第一次用 SSH 连服务器时，会看到一段有点吓人的提示：系统告诉你它拿到了对方的 public key fingerprint，问你要不要继续

Sun, 26 Jul 2026 03:00:34 GMT

🔑 为什么 SSH 第一次连接会问你“Are you sure you want to continue connecting”

很多人第一次用 SSH 连服务器时，会看到一段有点吓人的提示：系统告诉你它拿到了对方的 public key fingerprint，问你要不要继续。这不是“多余的确认”，而是 SSH 整个安全模型里很关键的一步：它在防中间人攻击。

SSH 要解决的问题，不只是“把数据加密”，而是“我加密通信的对象，真的是那台我想连的机器吗”。如果没有身份校验，你确实能得到一条加密通道，但这条通道可能是加密连到了攻击者的机器上。SSH 的做法很直接：服务器先拿出自己的 host key，客户端把这个 key 记到 ~/.ssh/known_hosts，以后每次再连，都会检查“这台机器现在给我的 key，和上次是不是同一个”。

这就是为什么第一次连接时你会被要求确认。因为第一次还没有历史记录，客户端没法自动判断真假，只能把“是否信任这个 host key”的决定交给你。如果你确认了，以后只要 key 不变，SSH 就默认这是同一台机器；如果某天 key 突然变了，SSH 就会大声报警，因为这可能意味着两种事：服务器真的重装了，或者你正被中间人劫持。

这里的设计很实用。SSH 没有假装自己能在“第一次见面”时凭空知道对方是谁，它承认第一次信任必须从外部建立，这种模式叫 TOFU，Trust On First Use。它不完美，但在没有完整证书体系的小规模运维环境里很好用。问题也正出在这里：很多人第一次连接时根本不看 fingerprint，直接输入 yes，等于把最关键的一次校验草草跳过了。这样一来，TOFU 的安全性就被你自己抹掉了。

真正容易踩坑的地方，是“REMOTE HOST IDENTIFICATION HAS CHANGED!” 这类报错。很多教程上来就让你删 known_hosts 重新连，这做法太粗暴。你应该先问：为什么变了？是不是服务器重装了？是不是换了 IP 后 DNS 还指向旧名字？是不是负载均衡后端机器的 host key 不一致？只有确认变化是合理的，才去更新记录；不然你就是在主动忽略一次安全警报。

🧪 课后一题：如果你第一次 SSH 到一台机器时，没有核对 host key fingerprint 就直接接受，之后 known_hosts 里虽然有记录了，但这能不能保证你后续连接一定安全？

不能。因为如果第一次就连到了中间人，你记住的其实是攻击者的 host key，之后只是在稳定地连错对象。

💡 易混淆点：SSH 的 host key 用来证明“服务器是谁”，和你登录时用的用户密钥不是一回事；前者校验远端身份，后者证明你是谁。

🔑 编译器为什么喜欢 SSA 形式很多人第一次见到 SSA，会觉得它只是编译器内部一种“奇怪写法”：每个变量只能被赋值一次，循环入口还要插一个 φ 函数，看起来比普通代码更绕

Sat, 25 Jul 2026 03:01:19 GMT

🔑 编译器为什么喜欢 SSA 形式

很多人第一次见到 SSA，会觉得它只是编译器内部一种“奇怪写法”：每个变量只能被赋值一次，循环入口还要插一个 φ 函数，看起来比普通代码更绕。问题是，编译器不是为了优雅才这样折腾，它是在给优化开路。因为一旦“一个名字只对应一个定义”，数据从哪里来、流到哪里去，就突然变得非常清楚。你不用再反复猜 x 现在到底是哪次赋值后的 x，而是直接看到 x1、x2、x3 分别来自哪里，这让常量传播、死代码删除、值范围分析这些优化变得直接得多。

真正关键的不是“单次赋值”这四个字，而是它把“值的身份”和“变量的名字”拆开了。普通代码里，同一个变量名会在不同时间代表不同值；SSA 里，每个名字只代表一个值。如果控制流分叉后又汇合，比如 if 的两个分支都给 x 赋了不同结果，那么汇合点就用 φ 函数表达“这里的值取决于你是从哪条边走过来的”。φ 不是运行时真的调用了一个函数，它更像是控制流图上的占位符，告诉编译器：在这个点上，值的来源有多个候选，但每条路径上其实仍然很明确。

这就是为什么 SSA 对优化器特别友好。比如你看到某个 y3 = x2 + 1，而 x2 明明是常量 4，那就能立刻把 y3 改写成 5；如果后面没人再用 y3，这条计算还能被删掉。要是没有 SSA，编译器得先证明中间没有别的赋值悄悄改过 x，分析会复杂得多。说白了，SSA 不是让程序跑得更快的魔法，它是让“证明某段代码可以安全优化”这件事变简单了。编译器真正值钱的地方，不是会不会做优化，而是能不能在不改错行为的前提下放心地做优化。

🧪 课后一题：如果一个变量 v 在 if 和 else 两个分支里都被重新赋值，控制流汇合后还要继续使用它，那么在 SSA 里通常为什么需要引入 φ 函数？

因为汇合点后的

v

可能来自两个不同分支的定义，SSA 要保持“每个名字只定义一次”，就必须用 φ 在控制流汇合处显式表示“这个值取决于前驱路径”。

💡 易混淆点：φ 函数不是运行时真正执行的普通函数调用，它只是编译器在中间表示里用来描述“多来源合并”的记号。

🔑 Shell 里为什么要有 exit status很多人刚学命令行时，只盯着命令有没有“输出”

Fri, 24 Jul 2026 03:01:07 GMT

🔑 Shell 里为什么要有 exit status

很多人刚学命令行时，只盯着命令有没有“输出”。这其实抓错重点了。对 Shell 来说，一条命令最重要的不只是打印了什么，而是它最后到底算“成功”还是“失败”。这个结果不会靠一句英文提示来判断，而是靠一个很小但非常关键的数字：exit status，也就是退出状态码。

这样设计不是为了学术优雅，而是为了让程序能接着程序说话。人类看得懂 “file not found”，机器不该去猜你这句英文是什么意思。于是 Unix 很早就定了个朴素规则：命令结束时交一个整数出来，0 表示成功，非 0 表示失败。Shell 再根据这个数字决定后面该不该继续执行，比如 cmd1 && cmd2 只有在 cmd1 成功时才跑 cmd2，而 cmd1 || cmd2 则是在 cmd1 失败时才补上第二个命令。你平时觉得这些符号顺手，背后靠的就是 exit status，而不是输出文字。

这里最容易踩坑的地方是：有输出，不等于成功；没输出，也不等于失败。比如 grep pattern file 找到了会返回 0，没找到常常返回 1，但这不代表程序坏了，只是“没匹配到”。再比如有些命令明明打印了一堆错误信息，如果你不检查 $?，或者不把它放进 &&、||、脚本的错误控制里，Shell 还是可能继续往下跑，把后续步骤也一起搞脏。更坑的是管道。很多人以为 cmd1 | cmd2 里只要前面炸了，整个就算失败；实际上默认情况下，Shell 往往只看最后一个命令的退出状态。所以前面已经出错，后面命令如果照样退出 0，你会得到一个“表面成功”的假象。这就是为什么写严肃脚本时常要加 set -e，甚至 set -o pipefail：不是为了显得专业，是为了别让错误悄悄溜过去。

你可以把 exit status 理解成命令行世界里最基础的协议。输出是给人看的，状态码是给系统接线用的。没有这个约定，自动化脚本、CI、部署流程都会变成一堆脆弱的字符串匹配，稍微换个报错文案就全废了。

🧪 课后一题：执行 false && echo ok || echo fail，终端最终会打印什么？为什么？答案：

会打印

fail

。因为

false

的退出状态是非 0，导致

&&

右边的

echo ok

不执行，随后

||

发现左边整体失败，于是执行

echo fail

。

💡 易混淆点：0 在编程里常像“假”，但在 Shell 的 exit status 里，0 恰恰表示成功，非 0 才表示失败或特殊情况。

🔑 为什么 SSH 要记住服务器指纹：known_hosts 不是多余的麻烦很多人第一次用 SSH 连服务器，都会看到那句有点吓人的提示：The authenticity of host ... can't be established

Thu, 23 Jul 2026 03:00:56 GMT

🔑 为什么 SSH 要记住服务器指纹：known_hosts 不是多余的麻烦

很多人第一次用 SSH 连服务器，都会看到那句有点吓人的提示：The authenticity of host ... can't be established。看起来像是系统在找你麻烦，其实它做的是一件很硬核但很朴素的事：防止你连上的根本不是那台服务器。

SSH 不是只负责“加密”，它还要先确认“对面是谁”。如果没有这一步，中间有人冒充服务器，你照样会把密码、命令、文件都交出去。于是 SSH 设计了 host key，也就是服务器自己的长期身份公钥。你第一次连接时，客户端还不认识它，所以会把这个指纹展示给你；一旦你确认并接受，它就被记到 ~/.ssh/known_hosts 里。下一次再连，SSH 会先检查：这台机器现在给出的指纹，和上次记住的是不是同一个。

这就是 known_hosts 的意义。它不是地址簿，而是“我以前见过这个人，而且我记得他的脸”。如果某天同一个域名、同一个 IP，突然拿出一把不同的 host key，SSH 就会直接报警。很多新手这时会觉得“删掉 known_hosts 再连不就好了”，这动作能解决表面错误，但也顺手把安全检查废了。更糟的是，你会分不清到底是服务器真的重装了，还是有人在中间拦你。

这里的设计很有意思：SSH 不相信网络路径，只相信上一次确认过的身份。网络里的 IP 可以变，DNS 可以改，路由可以绕，但只要 host key 没变，客户端就知道自己还在和原来的那台机器说话。也正因为这样，云服务器重建、容器宿主替换、负载切换时，最容易踩的坑就是“主机变了，但你还拿旧指纹去比”，于是出现经典的 REMOTE HOST IDENTIFICATION HAS CHANGED!。这不一定代表被攻击，但它一定代表“身份发生了变化，先别装作没看见”。

真正靠谱的做法不是无脑删记录，而是先确认这次变化是不是合理的。比如服务器是否刚被重装，是否换了实例，是否确实更新了 host key。确认无误后，再用 ssh-keygen -R 主机名或IP 删除旧记录，重新接受新的指纹。顺序不能反，不然你是在把报警器当噪音关掉。

🧪 课后一题：如果你连 server.example.com 时，SSH 提示 host key 变了，但运维同事说“昨天刚把这台机器重装了”，这时候最正确的动作是什么？

先通过可信渠道确认新指纹是否真的是重装后生成的那一把；确认后再删除 known_hosts 中旧记录，并重新连接接受新指纹，而不是直接忽略警告继续连。

💡 易混淆点：known_hosts 记录的是“服务器身份”，不是“你自己的登录密钥”；它和 authorized_keys 不是一回事，前者防你连错人，后者决定你能不能登录。

🔑 为什么 2>&1 >out.log 和 >out.log 2>&1 结果不一样？很多人第一次学 Shell 重定向时，会以为这两句命令只是写法顺序不同，结果应该一样

Wed, 22 Jul 2026 03:01:28 GMT

🔑 为什么 2>&1 >out.log 和 >out.log 2>&1 结果不一样？

很多人第一次学 Shell 重定向时，会以为这两句命令只是写法顺序不同，结果应该一样。错了。它们的区别不在“语法长得像不像”，而在 Shell 是按从左到右依次处理重定向的，而文件描述符本质上只是进程手里的一组“编号好的出口”。1 是标准输出，2 是标准错误，2>&1 的意思不是“把错误也写进某个文件”，而是“让 2 指向当前 1 正在指向的地方”。

这就是设计上最容易被忽略的一点：重定向操作不是声明式配置，不是最后统一结算；它更像一连串立即生效的接线动作。比如 cmd >out.log 2>&1，Shell 先把 1 接到 out.log，再把 2 接到“当前的 1”，所以最后标准输出和标准错误都进了文件。可如果你写成 cmd 2>&1 >out.log，Shell 会先把 2 接到“当前的 1”，而这时候 1 还指向终端；然后再把 1 改接到 out.log。结果就是标准输出进文件，标准错误还留在屏幕上。

这套设计一点也不神秘，因为 Unix 从一开始就把“一切都当成文件接口来处理”。进程不需要知道对面是终端、文件还是管道，它只往编号 1 和 2 写数据。Shell 的工作只是提前把这些编号接到合适的位置上。这种设计非常实用：简单、统一、可组合。代价就是你必须理解“复制的是指向关系，不是名字本身”。

真正踩坑的时候，通常不是在课堂例子里，而是在日志和脚本里。你以为自己把错误输出也收进日志了，结果 CI 里报错还在控制台飞，日志文件里却干干净净；或者你把管道和重定向混着写，最后发现 stderr 根本没有进入下游命令。很多“日志丢了”的问题，不是程序错了，是 Shell 重定向顺序写错了。

🧪 课后一题：命令 python app.py 2>&1 | tee run.log 里，标准错误会不会进入 tee？为什么？答案：

会。因为先执行

2>&1

，此时标准错误被接到标准输出；而标准输出随后进入管道，所以两者都会流进

tee

。

💡 易混淆点：2>&1 复制的是“当下 1 的去向”，不是永远跟着 1 一起变化；它不是绑定关系，只是一次接线动作。

🔑 并查集为什么几乎总比你手写连通性判断更对并查集（Union-Find）解决的是一个很朴素的问题：一堆元素不断被“连起来”之后，你想快速知道两个元素现在是不是属于同一组

Tue, 21 Jul 2026 03:01:12 GMT

🔑 并查集为什么几乎总比你手写连通性判断更对

并查集（Union-Find）解决的是一个很朴素的问题：一堆元素不断被“连起来”之后，你想快速知道两个元素现在是不是属于同一组。它看起来像是个小技巧，真正厉害的地方在于设计思路很干净：它根本不关心这组里具体长什么样，也不关心连接路径是什么，只维护“谁和谁最终属于同一个代表元”。这就是它快的原因——它只保存判断连通性所必需的信息，别的都不存。

如果你自己硬写，最容易走进一条烂路：每次合并两组时，把整组元素重新扫描、重编号，或者用图搜索临时判断连通。这样在数据量一大、操作一多时，很快就会慢得离谱。并查集的做法更像是偷懒到极致：每个集合选一个根节点，元素只需要一路找到根，就知道自己属于哪一组；合并时，也只是让一个根指向另一个根。核心操作只有两个，find 找根，union 合并根。

但裸的并查集还不够好。真正让它“几乎等于 O(1)” 的，是 path compression 和 union by rank/size。path compression 的意思是：你查一次根，就顺手把沿途节点直接挂到根上，下次再查就更短。union by size 的意思是：小树挂大树，别反过来。为什么这样设计？因为所有性能问题本质上都来自树太高。你不控制高度，find 就会退化成一长串父指针追踪，最后跟链表没区别。

这里最容易踩坑的地方，不是原理，而是实现细节。第一种坑是把 union(x, y) 写成 parent[x] = y，这几乎总是错的，因为 x 和 y 可能都不是根，你是在随手改中间节点，结构会变脏。正确做法是先找 rootX 和 rootY，再决定谁挂谁。第二种坑是以为 path compression 会改变“集合内容”，其实不会，它改的是树形结构，不改连通关系。第三种坑是把并查集拿去做删除边、撤销合并这类操作；这就超出它的舒适区了，因为它擅长的是只增不减的连通性维护，不擅长回滚和动态拆分。

这东西为什么在算法里反复出现？因为很多问题的本质不是“图怎么走”，而是“关系是否已经连上”。Kruskal 最小生成树要它，是因为它只关心加一条边会不会形成环；账户合并、朋友圈、岛屿连通、网络分组也要它，因为这些问题都在反复问同一句话：这两个东西现在是不是同一类。你一旦看清问题本质只是“分组归属”，就别再上来就建整张图然后 DFS/BFS，那个数据结构已经重了。

🧪 课后一题：有 6 个元素，初始各自独立。依次执行 union(1,2)、union(2,3)、union(4,5)、union(3,5)。最后 1 和 5 是否连通？集合一共有几个？

答案：1 和 5 连通；最后共有 2 个集合，分别是 {1,2,3,4,5} 和 {6}。

💡 易混淆点：并查集只能高效回答“是否同组”和“合并分组”，它通常不能直接告诉你两点之间的具体路径，更不适合处理删除关系后的连通性变化。

🔑 伪共享：你的并发程序为什么比单线程还慢多核 CPU 的 cache 不是按单个变量管理的，而是按 cache line（通常 64 字节）为单位加载

Mon, 20 Jul 2026 03:02:41 GMT

🔑 伪共享：你的并发程序为什么比单线程还慢

多核 CPU 的 cache 不是按单个变量管理的，而是按 cache line（通常 64 字节）为单位加载。两个变量如果恰好在内存里相邻，落在同一条 cache line 上，哪怕线程 A 只写变量 x、线程 B 只写变量 y，它们也会互相把对方的 cache line 弈无效——这就是 false sharing，中文叫伪共享。

问题在于它完全静默。你的代码看起来每个线程操作独立变量，逻辑上无竞争，连 race detector 都不会报警，但性能可能比单线程还差好几倍。原因是一条 cache line 在两个核心之间反复弹来弹去，每次写操作都让对方核心的 cache 副本失效，触发 MESI 协议的 invalidate + reload 往返。

什么时候会踩坑？最经典的是计数器场景。你写一个 struct，里面放 N 个线程各自的计数 int，以为这样每个线程只碰自己的字段就安全了。但 N 个 int 紧挨着，全挤在一条 64 字节的 cache line 里，对齐得越整齐，伪共享越严重。

解法叫 padding：在每个变量后面补足无用字节，人为撑开到 cache line 对齐。C/C++ 里用 alignas(64)，Java 里在字段后面塞 6 个 long 占位，Go 从 1.19 起也支持 //go:alignas 注解。看起来浪费内存，实际上换回来的是几倍的吞吐。

更高级的做法是把只读数据放在一个 cache line、写数据放另一个，利用读写分离天然避免竞争。Linux 内核里很多 per-CPU 变量都做了 padding，不是洁癖，是被坑过才加的。

现代编译器和运行时也在帮你。比如 Java 的 @Contended 注解、C++ 的 std::hardware_destructive_interference_size（C++17 起），都是在语言层面把这个问题显式化。

判断你是否中招：如果一段并发代码的 profile 显示大量 cache miss 且性能随核心数增加不升反降，先怀疑伪共享。

🧪 假设 cache line 为 64 字节，以下 Go 结构体在 8 核上跑，每个 goroutine 只原子递增自己的 Counter 字段，哪个会触发伪共享？

// 版本 A
type Stats struct {
    Counters [8]int64
}

// 版本 B
type Stats struct {
    Counters [8]struct {
        n    int64
        pad  [56]byte
    }
}

答案：版本 A 会触发伪共享。8 个 int64 各 8 字节，共 64 字节，恰好填满一条 cache line，所有核互相失效。版本 B 每个元素被 pad 撑到 64 字节对齐，各自独占一条 cache line，无伪共享。

版本 A

💡 易混淆点：伪共享和 data race 是两回事。data race 是正确性问题，多线程同时写同一变量导致未定义行为；伪共享是性能问题，各写各的变量但刚好共享 cache line。你的代码可以是完全 race-free 的，仍然被伪共享拖垮。

🔑 为什么 epoll 比 select 更适合高并发连接很多人第一次学 I/O 多路复用时，会把 select、poll、epoll 理解成“都能同时监听很多 socket，所以只是写法不同”

Sun, 19 Jul 2026 03:00:36 GMT

🔑 为什么 epoll 比 select 更适合高并发连接

很多人第一次学 I/O 多路复用时，会把 select、poll、epoll 理解成“都能同时监听很多 socket，所以只是写法不同”。这理解太浅了。真正的区别不在“能不能监听多个连接”，而在内核到底是怎么帮你找出“谁准备好了”。

select 的思路很直接：你每次把一堆文件描述符交给内核，内核从头到尾检查一遍，看看哪些可读、哪些可写，然后再把结果还给你。问题也出在这里。假设你有 10 万个连接，但这一刻只有 3 个连接真的来了数据，select 还是得把那 10 万个都扫一遍。应用程序拿到结果后，自己也常常还要再扫一遍。连接数一大，真正耗时的往往不是“处理数据”，而是反复做这种无意义的全量检查。

epoll 换了个设计。它把“监听哪些 fd”和“哪些 fd 已经就绪”拆开了。你先用 epoll_ctl 把关心的 fd 注册进内核，后面不用每次整包重新提交。等某个 fd 真的发生了可读、可写之类的事件，内核会把它放进一个就绪队列。应用程序调用 epoll_wait 时，不是让内核再去傻扫一遍全部连接，而是直接拿已经准备好的那些。这就是它在高并发场景下更省事的根本原因：不是更快地遍历全部，而是尽量不遍历没事发生的那些。

这也解释了为什么 epoll 在大量“连接很多，但活跃连接很少”的服务器里特别合适。比如聊天服务、网关、长连接推送，这类系统的常态不是每个连接都忙，而是大部分连接长期挂着，偶尔才动一下。如果还用 select 的思路，每次都把全部连接检查一遍，就是把时间浪费在沉默的大多数上。

但别把 epoll 神化。很多坑都出在“边沿触发”也就是 ET 模式。LT，也就是 level-triggered，更像“只要你还没把数据读完，我就继续提醒你”；ET 更像“我只在状态从没数据变成有数据时提醒一次，后面你自己负责读干净”。ET 性能潜力更高，但代码要求更严。你如果没有把 socket 设成 non-blocking，或者一次事件来了只读一点就停，下次可能根本收不到提醒，看起来就像程序莫名其妙卡住了。不是 epoll 坏了，是你没把缓冲区读到 EAGAIN。

还有一个常见误解：epoll 并不是“任何场景都吊打 select”。如果你的 fd 很少，程序很简单，select 完全够用，代码还更直白。复杂度要和问题规模匹配，别为了“高级”把小程序写成事故现场。

🧪 如果一个 socket 使用 epoll 的 ET 模式，收到一次可读事件后只读取了一部分数据，缓冲区里还剩内容没读完，此时最可能出现什么问题？答案：

后续可能不再收到新的可读通知，程序以为没数据了，实际是自己没一次读到

EAGAIN

。

💡 易混淆点：epoll 快，不是因为它“检查得更快”，而是因为它尽量避免检查那些根本没发生事件的 fd，尤其别把 ET 和 LT 的通知语义混成一回事。

🔑 Shell 里的 pipefail：为什么前面的命令明明失败了，脚本还显示成功？很多人第一次写 Shell 管道时都会踩这个坑：cat missing.txt | grep hello | wc -l，明明最前面的 cat 已经报错了，整条命令最后却可能返回成功

Sat, 18 Jul 2026 03:01:39 GMT

🔑 Shell 里的 pipefail：为什么前面的命令明明失败了，脚本还显示成功？

很多人第一次写 Shell 管道时都会踩这个坑：cat missing.txt | grep hello | wc -l，明明最前面的 cat 已经报错了，整条命令最后却可能返回成功。原因不神秘，Shell 对管道的默认设计就是“看最后一个命令的退出状态”。这在交互式命令行里很实用，因为你常常真正关心的是最后产出的结果，比如 grep 有没有匹配到、wc 有没有算完；但一进脚本，这个设计就容易把错误吞掉，让 CI 绿灯、日志好看、结果却是错的。

pipefail 就是拿来修这个默认行为的。打开 set -o pipefail 之后，只要管道中有一个命令失败，整条管道就会被判定为失败。这样一来，上游读文件失败、网络请求失败、解压失败，不会再被下游命令“洗白”。很多自动化脚本都会把 set -euo pipefail 放在开头，核心不是仪式感，而是尽早把坏数据拦住，别让后面的命令在垃圾输入上继续跑。

但这里还有个常见误会：pipefail 不是“返回第一个失败”，而是“返回最后一个失败的非零状态”。这意味着它能告诉你这条管道出问题了，却不负责替你定位是哪一段坏了。真要查，就得看 PIPESTATUS，或者把长管道拆开。好代码不是往一条命令里塞五六段玄学管道，而是让每一步都能单独验证。否则你得到的不是简洁，是一条难以调试的黑盒。

🧪 课后一题：执行 false | true 时，默认情况下退出状态是多少？开启 set -o pipefail 之后又是多少？答案：

默认是 0，因为看最后一个命令

true

；开启 pipefail 后是 1，因为前面的

false

失败了。

💡 易混淆点：pipefail 只影响“管道”里的退出状态，不会自动让所有脚本更安全；像变量未定义、普通命令失败、子命令逻辑错误，还要分别靠 set -u、set -e 和清晰拆分步骤来处理。