个人收集的八股，简单地总结了一下，欢迎分享讨论。

为什么每个 Rust 新手都应该被所有权、借用与生命周期毒打一遍

其实我本来想写的是“为什么每个 Rust 新手都应该被所有权、借用与生命周期轮建一遍（bushi）

几乎每一个带着其他语言经验来学 Rust 的人，剧本大抵都是相似的：

看前三章的基础语法时，觉得这门语言还挺眉清目秀；直到翻开第四章，迎面撞上所有权（Ownership）、借用（Borrowing）与生命周期（Lifetimes），画风瞬间突变成“写代码五分钟，和编译器对线两小时”。

以前写 Java、Go，变量想赋给谁赋给谁，函数想怎么传参怎么传参，代码里面当土皇帝，主打一个随心所欲。结果一上手 Rust，直接寸步难行：

顺手写个 b = a，回头再去读一下 a，编译器反手就是一个报错，直接通知原变量已经“当场去世”（value moved here）； 那我寻思加个 &“借”一下总行了吧？写业务时你明明得先读一下状态才知道怎么改数据，结果编译器直接给你拿下：“看导航的时候不准开车，开车的时候不准看导航”；等你千辛万苦把逻辑绕过去，以为终于能跑了，它又甩出一串带单引号的 'a 糊你脸上，告诉你“借来的东西活得太久了”（does not live long enough）。

被这三套组合拳轮流毒打一通下来，很少有人不在屏幕前破防的：不是，我就想传个变量而已，你这编译器怎么跟防贼一样防着我？

要搞懂 Rust 为什么非要定下这么“反人类”的规矩，我们不妨先把视线从满屏飘红的报错上移开，回到一个困扰了软件工程几十年的底层困局。

AI 我个人觉得本质上还是一类“补全工具”。可以将我们一个想法快速地通过预测 Next Token 的方式来实现补全。以比较具有“创造性”的工作编写设计文档来说：一般一个设计文档首先是来源于我们某个需求、需要实现某个功能，我们才开始去编写这个功能的代码实现、设计文档。

在面试或技术讨论中，"Redis 为什么这么快？" 往往是一个开场白。大多数人的回答通常局限于几个标准关键词：单线程、I/O 多路复用、基于内存。

这些答案没错，但往往缺乏深度。对于这个问题，我最想强调的一个核心观点是："脱离场景谈设计就是耍流氓"。

要真正理解 Redis 的高性能，我们不能只看它用了什么技术，更要看它是在什么背景下、为了解决什么问题而做出的架构取舍。本文将避开枯燥的参数罗列，从设计哲学的角度，为你层层剥开 Redis 高性能的真相。

一次简单的代码重构，却引发了架构涅槃

—— 为什么我们不能把 Kubernetes 当作大号 Docker 用？

第一部分：引言 —— 一语点醒梦中人