翻自己两年前的笔记，经常遇到这种段落：

这里要用 --cap-add=SYS_ADMIN，不然会报错。

然后就没有了。报什么错？为什么需要这个权限？换台机器还行不行？

我自己能看懂，因为写的时候我脑子里有完整上下文。但三个月后的我，已经变成了「别人」。

这两年我慢慢摸清楚，笔记变成能给别人看的教程，差的不是内容质量，是三样东西。

一、缺上下文 ​

笔记默认「我知道自己在说什么」。教程必须假设读者什么都不知道。

那行 --cap-add=SYS_ADMIN，补上上下文之后是这样：

容器默认以受限权限运行。如果容器内需要挂载文件系统（比如跑一个 FUSE 程序）， 内核会拒绝这个操作，报 operation not permitted。 --cap-add=SYS_ADMIN 把 CAP_SYS_ADMIN 这个 capability 加回给容器。 注意这是很大的权限，接近 root，只在你信任这个镜像时用。

多出来的这几句，才是别人真正需要的东西。

二、缺推导过程 ​

笔记只记结论，因为推导过程当时在脑子里。

但结论是最容易过时的东西 —— 版本一升级，--cap-add 可能就换成别的写法了。 推导过程不会过时，它告诉你这个结论是为什么成立的，因此结论失效时你知道该往哪找替代方案。

所以教程里我尽量写「因为 A 所以 B」，而不是直接给 B。

三、缺可复现的步骤 ​

笔记里写「先装个依赖」，教程里必须写清楚是哪个版本、用什么命令装。

# 不是这样
apt install docker

# 而是这样
apt install -y docker.io
systemctl enable --now docker
docker --version   # 期望输出：Docker version 24.x

给出期望输出特别重要。读者跑到这一步发现输出不一样，就知道自己走岔了， 而不是带着错误继续往下跑。

那笔记还有价值吗 ​

有，但价值不一样。

笔记的价值是当时的我写给当时的我，它的作用是记录「我做过这件事、结论是什么」。 它的读者只有一个，而且那个读者当时就在现场。

教程的价值是跨越时间的传递。它必须能在没有我在场的情况下独立成立。

所以现在我的做法是分开：

• 随手记的东西放本地笔记软件，不打算给别人看，怎么省事怎么写
• 一个主题想清楚了、验证过两遍以上，才整理成教程发布

判断标准很简单：如果我不能在半年后只看这篇文字就把它重做一遍，那它就还只是笔记。

一个副作用 ​

把笔记整理成教程之后，我发现自己对技术的理解变了。

写笔记时我是在记录「怎么用」，整理教程时被迫回答「为什么是这样」。 好几个我以为自己懂的地方，在试图向别人解释的时候才发现是空的。

这可能才是整理教程最大的收益 —— 不是为了读者，是为了确认自己真的懂了。

为什么是 Caddy 而不是 Nginx ​

Nginx 很强，但配 HTTPS 要额外装 certbot、写续期定时任务、还得记得 nginx -s reload。 Caddy 把这三件事合成了一件：写个域名，它自己去申请证书、自己去续、自己重载。

对一个个人博客来说，这就是全部的理由。

第一步：域名解析 ​

在你的域名商后台加一条 A 记录：

等几分钟让解析生效，用 dig blog.example.com +short 确认能查到 IP。

第二步：Caddyfile ​

blog.example.com {
    root * /srv/blog
    encode zstd gzip

    try_files {path} {path}.html {path}/index.html /404.html
    file_server

    @assets path /assets/*
    header @assets Cache-Control "public, max-age=31536000, immutable"
}

几个容易踩的点：

• try_files 那行是必须的。VitePress 开了 cleanUrls 之后，/posts/hello 实际对应的是 posts/hello.html，不加这行访问文章页会 404。
• 带 hash 的静态资源（/assets/xxx.abc123.js）可以放心设一年缓存，因为文件名变了内容才变。
• encode zstd gzip 能让 HTML 传输体积再小一截。

第三步：docker-compose ​

services:
  web:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./dist:/srv/blog:ro
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

caddy_data 这个卷一定要持久化，证书就存在里面。丢了的话重启后会重新申请， Let's Encrypt 有频率限制，短时间内反复申请会被限流。

第四步：验证 ​

docker compose up -d
docker compose logs -f web

看到类似 certificate obtained successfully 就说明证书签下来了。

如果一直卡在申请证书，先检查 80 端口有没有被占用 —— Caddy 申请证书要用 80 端口做 HTTP 校验。

自动化部署 ​

手动 rsync 传文件能跑通之后，就该交给 CI 了。我的做法是：

1. 本地写完 git push
2. GitHub Actions 自动构建
3. rsync 把 dist/ 同步到服务器

服务器上只跑 Caddy，不需要 Node，也不需要构建环境。这样即使 CI 挂了， 站点本身也完全不受影响。

一开始它真的很好 ​

2019 年我在 Medium 上写第一篇文章，体验是惊艳的：干净的编辑器、不用管排版、 点一下就能发出去，还有一堆人给你鼓掌。

那时候我觉得「专注写作」这件事终于被解决了。

然后它慢慢变了 ​

先是阅读量开始往下掉。后来发现是付费墙 —— 我的文章被圈进了会员内容， 读者点进来只能看到两段。我从来没同意过这件事。

再后来是推荐流。首页推的东西和我关注的人越来越没关系，写文章的动力变成了 「怎么才能被算法喜欢」。

最要命的是链接 ​

我做过一次统计：三年里发的 47 篇文章，有 6 篇因为平台改版或者账号问题打不开了。

六年之后呢？十年之后呢？

Medium 不是第一个消失的内容平台，也不会是最后一个。每一次平台消失， 都会带走一批本来可以留下来的文字。

现在我的做法 ​

• 文章以 Markdown 存在自己的 git 仓库里
• 构建成一个纯静态站点，跑在自己的 VPS 上
• 域名是我自己的，换服务器只要改一条 A 记录

成本是一年几十块钱的服务器，加上一个下午的配置时间。

换来的是：只要我还愿意付这个钱，这些字就一直在。

一些实际的收益 ​

写完上面那些「情怀」的部分，说说很实际的东西：

1. 想改就改。 三年前的文章发现写错了，直接改，改完立刻生效。
2. 没有编辑器绑架。 用 Vim、VS Code、Typora 都行，就是普通文本文件。
3. 数据是自己的。 想看访问统计就自己装一个，不想装就什么都没有，没人追踪读者。
4. 能玩。 想加个交互式的图表、想在文章里跑一段代码，都没人拦着你。

如果你也在犹豫，我的建议是：不用急着搬。先在自建站点上发新文章， 老文章慢慢搬。半年之后你自然会知道哪个更舒服。

三条规则，一句话 ​

Rust 所有权的规则只有三条：

1. 每个值都有一个所有者
2. 同一时刻只能有一个所有者
3. 所有者离开作用域时，值被丢弃

看起来简单，真正让人卡住的是「借用」和「生命周期」这两层。

移动（move）到底发生了什么 ​

let s1 = String::from("hello");
let s2 = s1;

println!("{}", s1); // 编译错误：borrow of moved value

很多人第一反应是「这不是浅拷贝吗」。不完全是。

String 在栈上存的是「指针 + 长度 + 容量」，真实字符数据在堆上。 赋值时 Rust 把栈上那三个字段复制过去，同时把 s1 标记为失效。

所以它不是浅拷贝（那样会导致双重释放），也不是深拷贝（那样有运行时开销）， 而是移动：所有权转移，旧变量作废。

想保留原来的变量，用 s1.clone()，但要清楚这是显式付出了一次堆分配的成本。

借用：把「读」和「写」分开 ​

借用规则可以概括成一句话：

要么有任意多个不可变借用，要么有恰好一个可变借用，两者不能同时存在。

let mut v = vec![1, 2, 3];

let a = &v;      // 不可变借用
let b = &v;      // 再来一个，没问题
println!("{a:?} {b:?}");   // a、b 在这里之后就不再使用

let c = &mut v;  // 现在可以可变借用了
c.push(4);

关键在最后一段：a 和 b 在 println! 之后就再也没有被使用， 所以它们的借用生命周期在那一行结束了。这就是所谓的 NLL（非词法生命周期）。

初学者最常犯的错是以为「借用会持续到作用域结束」，实际上编译器看的是 最后一次使用的位置。

什么时候该用 Rc 和 RefCell ​

如果你发现自己在跟借用检查器较劲，先别急着上 Rc<RefCell<T>>，问自己三个问题：

我的经验是：大部分时候答案是「不需要」。把数据拆开、把所有权理清楚， 代码往往比堆一层 RefCell 更清楚。

一点感想 ​

写了几个月 Rust 之后，最大的收获不是学会了一门语言， 而是被迫把「这块内存归谁管」这件事想清楚了。

以前写 C++ 或者 Go，这些决定是隐式的，靠习惯和约定。 Rust 把它们摆到台面上，编译不过的时候你就得想明白。

想明白了，代码通常也就变简单了。

第一天：到达 ​

落地的时候在下雨。成田到市区坐了一个多小时的 Skyliner， 窗外的房子一栋接一栋地贴在一起，招牌都是竖着的。

酒店房间小得有点好笑 —— 行李箱打开之后就没法走路了。 但窗户正对着一栋居民楼，晚上能看到对面阳台晾着的衣服和几盆绿植。

那一刻忽然觉得，比起景点，我好像更喜欢看别人怎么过日子。

第二天：神保町 ​

本来只打算逛两小时，结果待了一整个下午。

神保町的书店密度高得离谱，一条街走过去能看到十几家。 大部分是旧书店，门口堆着 100 日元一本的文库本，店主坐在里面看报纸。

在三省堂二楼找到一本 1970 年代的摄影集，讲的是当时的下町。 纸张已经泛黄，但照片的层次感很好。翻了很久，最后没买 —— 太重了。

后来有点后悔。下次去大概会买。

第三天：雨停了 ​

去了清澄白河。那边有几家咖啡烘焙坊，都是仓库改的，层高很高。

在一家店里坐了三个小时，看完了半本书。 旁边桌是个在写论文的女生，桌上摊着两台电脑和一堆打印出来的资料。

出门的时候天晴了，路面还是湿的，反着光。

第四天：回程 ​

早上五点半起床，赶第一班地铁去机场。

地铁上空荡荡的，只有几个穿西装的人和两个拖着箱子的旅客。 车厢里的广告还没换，是昨天那批。

在机场买了两个饭团，坐在登机口旁边的椅子上吃完。 飞机起飞的时候，从窗户往下看，整个城市是一格一格的灰。

记一些细节 ​

• 便利店的饭团比想象中好吃，尤其是明太子的
• 自动贩卖机真的到处都是，而且真的什么都有
• 下雨天没带伞也不用慌，便利店 500 日元一把
• 大部分店只收现金，别像我一样到了才发现

下次想去的季节是秋天，听说银杏会黄。

换过的那些 ​

印象笔记、Notion、Obsidian、语雀、飞书文档、Apple Notes、以及一个自己写的 纯文本 + grep 的方案。

每一个都用了至少三个月。每一个都在某个时刻让我觉得「这次对了」。

真正的问题 ​

去年整理硬盘的时候，我导出了所有笔记平台的备份，放在一起看：

• 印象笔记 400 多篇，最后修改时间集中在 2018 年
• Notion 200 多篇，一半是各种模板和看板
• Obsidian 100 多篇，双链画得挺漂亮

加起来 700 多篇。我真正回头读过的大概不到 20 篇。

问题从来不是「哪个软件更好」，而是「我写完就不看了」。

现在的做法 ​

规则很简单：

1. 所有笔记是 .md 文件，放在一个 git 仓库里
2. 目录就是分类，不搞标签体系
3. 每次要查东西，先 grep -r "关键词" .
4. 每周五花二十分钟，随便翻翻这周改过什么

第 4 条是关键。以前我也定过「每周回顾」的计划，但那时候笔记散在云上， 回顾的成本是「打开 App、等同步、翻列表」。现在是 cd notes && git log --since=1.week， 一条命令。

一些副作用 ​

• 开始写得更短了。反正要复读，写得啰嗦自己受罪
• 开始删东西了。看到三年前的废话，顺手就删了
• 搜索变快了。grep 比任何笔记软件的搜索都快

工具确实重要，但它解决的问题是「查找」，不是「回顾」。 回顾得靠一个能坚持下去的习惯 —— 而习惯需要摩擦足够小。

那件事 ​

每年总有那么一两次，我会在某个早上收到浏览器的大红警告， 然后想起来：哦，证书过期了。

原因每次都差不多 —— certbot 的续期任务失败了，但我没看邮件。 失败的原因也五花八门：DNS 临时解析不了、webroot 路径被改了、 某个服务占了 80 端口、或者单纯是 systemd timer 没触发。

六年里大概发生过四五次。每次修好要二十分钟， 但那种「随时可能挂」的感觉一直在。

换过来之后 ​

Caddyfile 里写的就一行：

example.com {
    root * /srv
    file_server
}

第一次启动它会去申请证书，之后每 60 天自动续期， 续完自己 reload，不需要任何定时任务。

我已经跑了一年多，没有收到过一次证书警告。

性能上有区别吗 ​

我的场景下没有可测量的区别。都是静态文件服务， Caddy 的 HTTP/2 和 HTTP/3 是默认开的，Nginx 需要额外配置。

如果做反向代理扛高并发，Nginx 的调优空间确实更大。 但个人站点的瓶颈从来不在 Web 服务器上。

什么时候我还是会用 Nginx ​

• 需要非常精细的 location 匹配和 rewrite 规则
• 团队里所有人都熟悉 Nginx，换掉的学习成本不划算
• 需要一些只有 Nginx 模块才有的功能（比如某些 WAF 集成）

一句话总结 ​

Caddy 用一点灵活性，换掉了整整一类运维事故。 对我这种一个人维护几个小站点的人来说，这笔交易很划算。

《置身事内》 ​

讲中国地方政府的经济逻辑。最大的收获不是某个具体结论， 而是终于理解了「土地财政」这套东西是怎么转起来的。

书里有一句话印象很深：「钱的流向，比任何口号都更能说明问题。」

读完之后再看新闻里那些基建、招商、债务的报道，感觉完全不一样了。

《我们仨》 ​

杨绛写钱锺书和钱瑗。

一开始以为是本温暖的家庭回忆录，读到中间才发现是写失去的。 三个人走散了，只剩下一个人在原地等。

语言极其克制，几乎没有一句直接写「我很难过」， 但每一段都在写这件事。看完之后我坐了很久没动。

《Designing Data-Intensive Applications》 ​

这本是技术书，但读起来像在读一部长篇论证。

它不讲「怎么用某个数据库」，而是讲为什么会有这些数据库： 分布式系统里那些根本性的权衡 —— 一致性、可用性、分区容忍， 以及它们各自要付出什么代价。

读完最大的变化是：以前选技术栈靠「大家都用这个」， 现在会先问「我的场景里哪个代价是可以接受的」。

没读完的 ​

• 《尤利西斯》—— 第三次失败，可能真的不适合我
• 《人类简史》—— 读了三分之一，觉得论述有点跳跃
• 一本讲 Kubernetes 内部原理的，太厚了，当作工具书在查

下半年想读的 ​

1. 《贫穷的本质》
2. 《The Staff Engineer's Path》
3. 《置身事内》作者的另一本

如果有什么推荐，欢迎写信告诉我。