信也のブログ

一个 TREK 引发的二十个 stack

Mon, 11 May 2026 14:43:00 GMT

引

前几天刷 GitHub trending 看到一个项目叫 TREK，是个让一群人在地图上排路线、订住宿、列预算的项目，做完还能分享给别人继续改。点进 demo 站玩了一圈，挺顺手。

跟 npy 出去玩的行程一直是用 Obsidian 拼出来的，几个 daily note 来回链着写，越写越乱，往往到出门那天还是只有粗糙的"早上去哪下午去哪"。看到 TREK 我立刻就想自己跑一台。可以直接用作者的 demo，但旅行计划这种东西放别人服务器上多少有点不爽，早晚要自己部署。

既然要自己部署，索性顺手开一台新 VPS。

Netcup ARM

挑 VPS 比想象中纠结。DigitalOcean / Linode 同等配置直接贵一倍以上；国内小厂便宜，但 25 端口出站和备案是两个潜在雷，能不碰就不碰；Hetzner 性价比好，可惜 ARM 节点选址不灵活。兜回来还是 Netcup 顺手。

具体型号选了 VPS 2000 ARM G11，10 vCore、16G 内存、512G NVMe、2.5 Gbps 网络，月价 €13.41 含税，配置放到 x86 那边怎么也得贵一倍。流量是 flatrate，24 小时滑动平均超 2 TB 才会限速到 200 Mbps，我这种小破站根本碰不到。

下单前我去 Google 了一圈，捞到一张 -50% coupon，首付直接砍到 €6.7 出头，续费时回到原价。我对这种"首期半价"的玩法没什么意见，反正首年这一刀已经够香了。

机房可选 Nuremberg、Wien、Amsterdam 和美东 Manassas 四个。最后挑了 Manassas，国内常见路由走过去 ping 比另外三个欧洲点都低一截。至于邮件 IP 信誉这事，反正我出站邮件都走 Resend HTTPS 桥接（后面会讲），不依赖本地 IP 落地，没必要为这个守在欧洲机房。

从零到 TREK 跑起来

下单到收到登录信息大概 5 分钟。第一件事不是装东西，先收 SSH：禁 root、禁密码登录、改端口、ufw 默认 deny in。fail2ban 跑两天看日志，22 端口换之前一天 5000+ 次暴力尝试，换之后掉到个位数。刚装的机器，外面的人比你急。

ARM64 镜像生态这两年好了很多，后面陆陆续续装的二十来个 stack 里，Caddy、Postgres、Stalwart、SnappyMail、Open WebUI、Vaultwarden、Dagu、Glance、Karakeep、Paperless 全都有官方多架构镜像，docker pull 直接 work。唯一稍微费点事的是 Forgejo runner，base 镜像是 ARM64 没问题，但我需要在 runner 里跑 docker compose 当 deploy 工具，得自己加 docker-cli 和 docker-compose-plugin。最后是 buildx 推了一份 ARM64 镜像到自己的 Forgejo registry，runner 起来直接拉。

终于轮到 TREK 本身。仓库 mauriceboe/TREK 有官方 docker-compose.yml，照抄过来改了几行：

端口收成只对 web 这个 docker 网络可见
ENCRYPTION_KEY 用 openssl rand -base64 32 新生成一把
数据库 DATABASE_URL 走 SQLite，自己用够了
加 web 这个 external network，跟 Caddy 接通

Caddyfile 那边一行 reverse_proxy trek

收尾。从 docker compose up -d 到 trek.shinya.click 出现登录页，前后不到 15 分钟。看着空荡荡的 dashboard 我注册了第一个账号，下意识琢磨的下一件事不是"行程从哪开始拉"，而是"还能塞点啥进这台机器"。这毛病我自己也知道。

装着装着就停不下来

后半夜的折腾大致就是从这种心思开始的。反正配置富裕，闲着也是闲着，索性把之前一直想自托管的东西都搬上来。

第二天起床顺手装了 Forgejo 把代码托管收回来，博客也借着这波翻新了一遍，下面单独说。邮件用 Stalwart + SnappyMail + 自己写的 Resend bridge 三件套。AI 那条线挂 CLIProxyAPI 把 OpenAI / Claude / Gemini 几家订阅统一起来，前面再罩一层 Open WebUI 自己用。再后面是密码、网盘、图床、笔记、稍后读、RSS、PDF 工具集，能自托管的几乎都过了一遍。SSO 用 Authelia 把这一票服务统起来，登录一次到处通用。备份用 Dagu 起一个 DAG 每天加密快照到 R2。

陆陆续续装完，整套结构大概就是这张图：

架构图，不过还缺了博客部分

入口侧全部走 Cloudflare SaaS 智能解析回源；Caddy 是唯一一台外向 TLS 终点，按 Host 头反代到对应容器；需要登录的服务统一走 Authelia forward_auth；出站邮件走 Resend HTTPS API 桥接绕开 Netcup 的封禁；备份每日全量加密快照到 Cloudflare R2。

回头看 Dockge 面板里二十来个 stack 全绿色亮着挺有满足感的，但我也承认这中间有相当一部分是部署成瘾型上头：本来只想要一个 TREK，最后是一整套自托管基础设施。TREK 在这张图里只占其中一个小格子。

顺手把博客也迁了

之前博客是 Astro + retypeset，markdown 文件 push 上去走 CI 构建发布。用了一年多没什么大问题，但有几个一直让我膈应的点：发个错别字 fix 也要 commit、push、等 build；想加个"友链"或者"独立页面"这种轻量页面，要重新折腾文件树；游记里照片多了构建慢得离谱。

正好新机器铺好了，索性把博客也一起翻了一遍。

新栈是 SvelteKit 2 + adapter-node SSR + UnoCSS，视觉沿用 retypeset 但样式按 UnoCSS 重写了一份。内容后端换成 PocketBase，建了 7 个 collection 把文章、标签、游记、游记天数、游记照片、独立页面、友链全收进 SQLite。i18n 改成 zh / en / ja 三语并存。原 Astro 那边导出来的 markdown 写了个 migration 脚本一锅倒进 PB，123 篇文章、4 篇游记、148 张游记照片记录加上 pages、friends 全部落库。

部署改成蓝绿：blog-blue 和 blog-green 两个容器都常驻，活色由 /opt/app/blog/active 标记，Caddy 反代上游从 /opt/app/caddy-blog/upstream.caddy 这个文件 import。CI 推新镜像后跑 switch.sh，起 target 色、等 healthcheck、改 import 文件、caddy reload 切流，失败自动回滚。这套做完整个发布流程从"push 等三分钟"变成"PB 后台改一下、保存即生效"。

后台是 SvelteKit 内部的 SPA 挂在 /admin 路径下，走 Authelia forward_auth。admin → PB 的写请求经 Caddy 同源反代 /api/pb/*，token 由 Caddy 注入，浏览器和 git 仓库都摸不到这把 key。PB 写入会触发一个 JS 钩子 POST 到 blog 容器内部端点，做服务端缓存失效再调一次 Cloudflare API purge 边缘缓存，公开页平均还是 CDN 命中。

整个迁移前后两个晚上搞定，意外地顺。

收尾

折腾了好几天，trek 到现在一篇规划也还没做 = =

微软模拟飞行 2024 折腾记录

Sun, 14 Dec 2025 06:31:00 GMT

前言

模拟类游戏（SLG）一直是一个相对小众的游戏类型，极高的上手难度和较为“无趣”的体验劝退着玩家（毕竟谁还想在下班后继续体验现实世界呢）。我个人其实一直比较喜欢现实模拟，或者说对这个概念十分沉迷，总让我联想到本科时期接触到的“数字孪生”的概念，但实际上也一直没有去尝试体验过。

契机其实是 K 君提到他近期在玩欧卡，过上了“上班时上班，下班后继续上班”的生活。受此启发，也恰逢电子阳痿，我便决心找一款模拟游戏玩一玩。恰好，同事提到了他一直很想玩微软模拟飞行 2024。去网上简单了解了一下后，决定入手。

网图

MSFS2024 初体验

当天午休时，就从 steam 上下单了 msfs 2024 标准版，港区 498 hkd，属实是不坑穷人的钱。与直觉相悖，游戏本体只有 8gb 左右。游戏的地图、地景、天气、建筑模型等数据都是在游戏过程中实时下载（串流）的，这对网络要求比较高，红迪上提到连接到微软的相关服务器至少需要 80mbps 的速度，尤其是这些服务器是境外服务器。所以需要一个好的加速器或一些特殊的上网姿势才能有比较好的体验，否则连初始的启动游戏连接 xbox 账号都无法完成。

pc 端和 xbox 端账号是互通的，所以从 steam 上启动游戏后还要在游戏内再登录一次 xbox 账号以同步游戏的版本和购买记录。msfs 2024 内置的一个商店，可以用来购买机场和飞机。游戏提供了三个版本：标准版、豪华版和高级豪华版（中杯、大杯、超大杯），这三个版本除了解锁的机场和飞机之外没有任何区别。

msfs2024 新增了一个生涯模式（职业模式），类似于一些主线剧情，大概就是完成任务得到 money 再买飞机飞更大的任务之类的循环。但对于我这种初次体验的小白，肯定要找新手教程。有点反直觉的是，新手教程隐藏在“活动”板块，找了好半天。

新手教程包括一些简单的仪表盘辨认、基础操作和起飞降落，固定翼飞机以赛斯纳 172 这款飞机为例，飞机内景确实很逼真，确实有种身临其境的感觉。但说实话用键盘玩这款游戏是有点折磨的，尤其是方向舵的控制，在转弯等场景很难维持平稳，需要不断地点按微调，十分难受，油门也是。本质上还是通过键盘这种非线性操控方式来模拟一些需要线性调整的设备造成的不适配。

赛斯纳 172

图马思特 TCA 领航员空客版

那么怎么才能解决这种冲突呢？当然是找一些线性操控设备啦。最简单的自然是手柄，但手柄由于按键有限，有些使用场景下不得不配合键盘一起使用。

更加进阶/拟真的方式则是购买专用的飞行模拟摇杆，模拟了真实的飞行摇杆的手感和操作方式，在飞对应机型时提供更加优秀的拟真效果。飞行摇杆可以大致分为两种类型：空客式和波音式。空客式则是你想象中的摇杆，确实是一根杆；而波音式的则是方向盘形状的。

经过多轮淘宝和京东的比较，最终选择了图马思特家的 TCA 领航员空客版，小贵，1800 rmb。顺丰的效率很高，直接次日达。

摇杆+节流阀+襟翼

东西不大，箱子却很大。两件分开发货，两大箱子差点把门都堵住了，管他是不是过度包装，反正保护效果是拉满了。

安装也很简单，摇杆是插上即用，节流阀+襟翼组装完成插到电脑上后，需要在图马思特的官网上再下载一个驱动，安装完成后启动游戏即可识别。

各种键位需要在游戏设置中检查，一个小技巧是先根据键盘键位找到设置项，再到摇杆设置中找到对应的摇杆键位。大部分键位比较符合直觉。我目前只调整了配平轮的键位。默认配平轮的调整需要按住摇杆的 button7 + 顶部的小摇杆，就需要两只手操作，不太友好。默认的顶部小摇杆只用来移动视角，在通过鼠标或 VR 移动视角时这样的键位其实不是很有必要，于是将顶部小摇杆直接改为了调整配平轮。

PICO 你这家伙

无论是赛车、卡车还是飞行模拟，一个很难绕开的话题就是 VR。恰好我有一个 pico4pro，于是寻思着折腾一下。

最开始使用的是 pico 自带的 pico connect，pico 互联，效果不尽如人意，启动也比较麻烦，体验上也存在各种 bug。一个比较明显的 bug 是，在连接 pico connect 后，如果此时 msfs2024 还没进入 vr 模式，vr 手柄点击无响应，即使退出 vr，msfs2024 也不再响应鼠标点击，必须退出游戏重新开启。一个简单的解决办法就是在不连接 vr 的情况下用鼠标控制 msfs2024 进入 vr 模式，而后再连接 pico connect 和 steamvr。

总之很麻烦～

google 了一番，解决方案是使用 virtual desktop。好消息是，virtual desktop 可以在 pico 上使用，直接在 pico 商店即可下载。坏消息是，virtual desktop 没有上国区商店，而我的 pico 恰好是国区的。

于是又是一番网上冲浪，尝试了各种完整的不完整的解决方案后，终极解决方案：刷外版系统。外版系统 ROM 可以在这里下载。下载完成后在 internal storage 下新建一个 dload 文件夹存放 ROM 压缩包，随后即可在通用设置中选择本地升级了，升级完成后系统就变成了外版系统。

外版系统当然需要外版账号，建议直接在手机上注册，pico 中直接登录就好。pico 国际版 app 可以在 apkpure下载安装。virtual desktop 亲测在 pico 中的商店也无法搜索到，可以直接在手机 app 上购买后，在 pico 设备的商店购买记录中即可下载安装。

virtual desktop 的 openXR 建议直接选择 vd 的 environment，绕过 steamvr，以获得更好的体验。

后记

这一套配置下来花了我一个周末的时间，飞了两个短途航线后，就不知道为啥发烧躺着了～

MoonTV —— 一次 Vibe Coding 尝试

Sun, 20 Jul 2025 15:32:00 GMT

大概半年前，就一直在关注一个项目 LibreTV，这是一个影视聚合项目，聚合各种采集站的资源做统一搜索和播放。当时想着给 npy 部署一个追剧平台，就关注了一下这个项目，后面还给这个项目贡献了不少代码，包括更换 html5 播放器，对这个项目的运行逻辑也愈发熟稔。后面用着用着，这个项目的弊端也不断展现出来：这是一个纯前端项目，播放记录等信息都存储在浏览器的 localstorage 中，更换浏览器就会丢失；代码都是纯 JS 写就的，经过不同人手，代码也比较混乱，由于没有静态检查，很多代码都不太敢动，也很难进行大改。

大概过了几个月，同事告诉我 cursor 支持支付宝付款了，精神为之一振。此前一直使用 Trae，模型能力较差不说，高峰期还需要排队，后面又开始收费，免费版问答动辄排队三四百人，几乎到了不可用的状态。于是火速入了一个月 Cursor Pro，准备体验一波，正好拿来重写 LibreTV。

完全没有任何前端经验的我，开始了 Vibe Coding，大部分代码都是和 Cursor 对话后直接完成。最终，MoonTV 应运而生：

MoonTechLabLunaTV

Loading repository data...

-- -- --

目前只过去了一个月，就已经有了 4.6K Star 和 5.4K Fork（出现不 star 的白嫖党），Star 趋势如下，足以见得国内对于 D 版视频的需求还是很大（全拜爱优腾的各种不做人的操作和那一堵高高的墙所赐）。

项目基于 NextJS 和 React，支持 Vercel、Cloudflare Pages 和 Docker 部署，支持 localstorage、Redis 和 Cloudflare D1 三种存储方式，Redis 和 Cloudflare D1 存储时支持多账户信息隔离和跨浏览器信息同步，以及方便快捷的管理面板，后续还计划支持对接 Upstash。

这也是我第一次 Vibe Coding 尝试、第一次前端/全栈（全栈这个词似乎只有 node/JS 生态在使用）项目尝试和第一次（比较正经的）开源项目尝试。由于 Cursor 的加持，MoonTV 的大部分开发工作从 Code 变成了 Code Review。有什么需求只需要和 Cursor 聊一聊，就可以完成。当然这个聊一聊也是有一些技巧的。

本次 Vibe Coding 体验遇到的第一个困难就出现在体验的最开头。由于对前端一窍不通，对很多流行技术栈也只是有“只知其名不知其意”的了解程度。为了追新，我决定使用对 Serverless 友好的 NextJS 和 Tailwind CSS 作为项目的主体框架。于是，新建文件夹，我要求 AI 帮我初始化一个 NextJS 和 Tailwind 项目。然后反复折腾了半个下午，AI 初始化的项目都无法成功运行，基本都是样式丢失，页面看起来像是纯文本堆出来了，百思不得其解之下，最终放弃，在 github 上找了个脚手架项目作为基座，后续开发才得以正常进行。

正式的开发过程都挺顺利，AI 模型我是基本使用这两个：Claude Sonnet 4.0 和 GPT O3。整体使用下来，这两个模型偏好也很明显：Sonnet 4.0 适合对整体项目做大修改，有时候即使是修一点小问题，AI 也会尝试重构整个项目，更适合用来实现新功能。GPT O3 则更适合对项目做小修小补，它会控制修改在一个很小的范围内，不会无序地去修改整个项目的文件，更适合用来修补一些已有功能的 bug。

当然也有一些 AI 力所未逮的情况。在实现播放页时，由于状态转移复杂，很多数据之间存在依赖和关联，AI 实现的版本中，数据依赖几乎成了一个网状结构，一旦有一个数据变更，如切换集数或更换播放源，最终传递到播放器的就可能是重复的五六次初始化，导致播放器闪烁。试了很多模型都无法解决这个问题，最终亲自上手，梳理了数据依赖传播路径，才最终解决了重复初始化的问题。

另外一些 AI 无法解决的情况就比较小众了，比如 m3u8 的视频大部分播放器不会开启 airplay 或 chromecast 投屏功能，但实际上是可以通过一些小 trick 强制开启的。这个需求直接问 AI，要么直接告诉你不可能，要么就是给出一些错误的解决方案，甚至可能会告诉你 xxx 播放器可以要不我们换 xxx 播放器吧。最终搜遍全网，在 hls.js 的一个角落发现了这个 issue，最终成功开启了 airplay。以 AI 目前的能力只能解决一些比较大众化的问题，过于小众或者甚至人类都无法解决的问题，暂时就不要指望 AI 了。

更大的困难其实来自于多平台多环境的适配，项目立项时的计划就是支持 vercel、CloudFlare pages 和 docker 部署，nextjs 原生就可以在 Vercel 上运行，只在 vercel 上倒是没有遇到什么困难。项目使用了一个 next-on-pages 依赖将代码翻译为 Cloudflare pages 代码，所以时常会出现一些兼容性问题。而对于 docker 的适配就更加复杂了，docker 下如接口处理只能跑在 node 环境下，但 nextjs 又保留了一个 edge 环境用于中间件处理（如鉴权等），这两个环境的内存也不是共享的，开发时需要严格地区分不同环境的依赖和可使用的 api。除此之外，客户端环境也是很复杂的一个情况，困难点主要来自于 webkit 内核，在 iOS 和 iPadOS 下，所有浏览器都只能使用 webkit 内核，而 webkit 内核的很多接口或 css 样式和 chromium 内核都有很大的差异，需要进行特殊的适配。

MoonTV 由于脱胎于 LibreTV，项目最初的宣传都是直接在 LibreTV 的交流群中进行的，项目专用的讨论群也是直接使用的 LibreTV 的讨论群。在主动宣传上基本只在 linux.do 论坛上进行，实际上也只是在有一些大更新的时候发一篇 changelog。到项目中后期发现很多科技博主也开始自发宣传起了 MoonTV：X 上关注的一些博主、TG 关注的科技频道，甚至 Youtube 和 Bilibili 以至于小红书上的很多 up 都开始主动教授起了 MoonTV 的搭建方式。

项目使用的人一多，各种 issue 就纷至沓来。issue 大概能分为如下两类：Bug report，这类 issue 会占大多数，写代码谁能不出点 bug 呢，更何况都是 AI 写的（转移矛盾）；Feature Request：FR 又可以分为两种，合理的需求 Request 是为了项目可以发展的更好，多是一些布局上、交互逻辑上或对接数据上的需求；最不受欢迎的就是商业化功能的 Request，这类人大概只是想着搭建这个项目后拿出去运营收费，但由于项目本身没有商业化功能，自己又没有能力实现，就跑去提 FR。这种人好逸恶劳只想着白嫖，自然是希望越少越好的。曾有个哥们一口气提了好多个类似的 issue，被 ban 了后还跑到 tg 群里继续纠缠，属实是讨厌可恶。还有一类：无效 bug，多是因为没有自己阅读 Readme 导致的部署失败，或者自身网络问题无法搜索，于是在 issue 中大呼小叫，遇到这类 issue，连讨论群群友路过都会吐口唾沫再走。

当然一个项目名声起来后，围绕这个项目产生的周边项目也会开始出现。MoonTV 就有一个 OrionTV 的客户端实现，专供 Android TV，可以直接使用 MoonTV 作为其后端，同步播放记录。交流群群友们也有各自实现的 Android 版和 iOS 版，当然由于各种限制 iOS 版是无法上架的。

zimplexingoriontv

Loading repository data...

-- -- --

以上。这篇文章本来计划是 7 月处写完，那时 star 也仅有 2k，但一直拖延，毕竟写文章肯定没有写代码有趣。我这个人的特点就是如此，一旦手头有什么事情，就无时无刻不去想着，无论是吃饭还是睡觉。两三点想到一个 bug 爬起来修都是常有的事情，连续两周每天只睡了六个多小时，也算是夜以继日日以继夜了。

macOS 26 / iPadOS 26 尝鲜

Tue, 10 Jun 2025 12:18:00 GMT

又是一年科技春晚 WWDC 25 在今日凌晨召开，众所周知科技以换皮为本，除了重点介绍了~~国行用不到~~国人不屑于使用的 Apple Intelligence 之外，最大的更新就是各平台系统发布了最新版并统一以年份命名，以及随之而来的 Liquid Glass 设计语言了。

原本我是不关心 WWDC 的，通常都是保守地等待正式版更新。但是今天早上铺天盖地的科技博主测评和新闻，和各种群嘲梗图，让我很难不关注，简单了解过后，决定更新下尝鲜。

据说 Liquid Glass 的灵感来自于此

由于我的 iPhone 已经卖掉了（见上一篇），所以这次体验范围为 macOS 和 iPadOS —— 这两个系统的吐槽似乎相对少一些。

首先最直观的感受当然也就是 UI 上的变化，本次多平台统一使用的设计语言 Liquid Glass，据说最早来自于 Vision OS。当然我的 Vision OS 也卖掉了，所以没法直接比较，不过直观感受上确实有一种 Vision OS 的风味，窗口都使用了毛玻璃效果，图标也统一改成了拟物（毛玻璃切片？姑且叫这个名字）风格。

说实话有一点山寨感，有点上古山寨机的风味了

iPad 上图标统一倒是效果不错，第三方应用的图标也有做效果转换，看起来风格很统一。

iPad 图标

窗口也更换为了统一风格，另外还统一了 Apple Music 的视觉效果，看起来也更有科技感，不像之前 iTunes 风格，看起来就卡卡的（当然实际体验两说）。

统一窗口算得上赏心悦目

macOS 上被人喷得最多的，倒不是 Liquid Glass（UI 负反馈主要来自于 iPhone），而是启动台 LaunchPad 下线了，功能融合进了 SpotLight，直接点击 Dock 上的 App 按钮，和 Cmd + Space 效果相同，弹出 SpotLight 搜索框。

SpotLight

需要再次按 Cmd + 1 才会展示出全部 App。

全部 App 页面

这个设计就有点有病了，尤其是对于我这种老年痴呆症患者来说，App 的名字根本记不住，勉强看到图标才能想起来功能。不知道 LaunchPad 和 Apple 有什么仇。说不定过几天就有独立开发者开发出一个 LaunchPad 替代品，然后收我 99。

Quiz：相册 app 叫什么，相册还是图库？

答案：照片（搜了好几个都不对）

另外一个小更新就是点击键盘上调整音量按键和调整亮度按键时，不再会弹出全屏的提示，而是会在状态栏上展示一个小弹框，有点像触摸屏的逻辑。

因为没有 iPhone，最经典的 Liquid Glass 我只能在 iPad 上体验了。我的 iPad 是 iPad Pro 11 英寸，第四代，使用的是 M2 芯片。

一些浮夸的锁屏时钟可以拉长之类的功能就不体验了，聚焦点主要在通知栏和控制中心。通知栏下拉的时候有实时的玻璃特效，仿佛是真的在拖动一个玻璃一般，效果很惊艳，就是不知道是否有性能要求，老 iPad 能不能轻松跑起来。

注意边界效果

下面就是被人吐槽最多的控制中心了，透明度太高导致辨识度很低，估计后续版本可能会调整，或者允许用户自定义。

是有些看不清楚的

当然，除了一无是处，这次更新还是有一些可取之处的。最大的亮点就是 iPadOS 更新的窗口化 App 模式。老版本的 iPad App 只能全屏幕或台前调度，屏幕上只能保留一个 App，或者使用分屏进行一些简单的多任务操作。窗口化 App 的操作逻辑则完全和 macOS 一致了，可以随意调整窗口大小、最大化、最小化，窗口互相覆盖等等。如果外接大屏，完全可以当作电脑使用，算是 iPad 成为真正的生产力工具的重要一步。

不黑不吹，这是真的 Legendary

这些就是我对本次更新的一些直观感受了，说实话我还是很看好这个设计语言的，Windows Vista 受限于当时的机能未能实现的未来，终于被 Apple 实现了。一些比较严重的问题和吐槽，在后续的更新中应该会得到解决。当前只是 macOS 26 / iPadOS 26 的第一个开发者预览版，未来可期。

迁移安卓一月谈

Thu, 05 Jun 2025 15:26:00 GMT

前言

我是一个换机很频繁的人，尤其是工作有了一些积蓄后，更是养成了一点“喜新厌旧”的坏毛病，一部手机在我手上很难待过一年。一旦有新机发售，就开始盘算着买一部做主力机如何如何，现有的软件/工具链如何迁移过去，想着想着就开始手痒，于是下单换机，旧机或是退给家人使用，或是卖二手，或是留在身边当备用机，然后被慢慢遗忘。

毕业后这四年起，仅仅主力机就有这些：一加 8T、一加 9Pro、Pixel 5、Oppo Find X6 Pro、Vivo X Fold3 Pro、iPhone 14 Pro、iPhone 16 Pro，另外还有一部一加 7Pro 作为备用机。

从换机历程，大概能看出我玩机心态的变化 —— 最初的一加系、pixel，早年刚毕业的时候喜欢折腾，类原生、root、解 bootloader，怎么自由怎么来；到 oppo、vivo，逐渐放弃了折腾，但还是保留了一些玩机的心态，如 vivo 的折叠屏；再到 iPhone，彻底投入 Apple 阵营，和 Apple 生态的深度融合。

正沉溺 Apple 构筑的生态链中不愿自拔时，npy 给了我当头一棒：“你这拍照也太垃圾了”。也是，早年玩机，主要关注跑分性能之类的纸面参数，摄像头嘛，能扫码就行。现在，我要向她证明：

一切手法上的不足，都可以通过软硬件不足！

当然这又是我换机的一个借口罢了，事实是，在上次关西行中，K 君的相机确实引起了我很大的兴趣，尤其是那大长焦。但我天生惫懒，不愿后期修图，那就不如买一部镜头和调色稍微好些的手机，来满足一下我的拍照瘾吧。

恰好上半年御三家都发布了各自的 Ultra 超大杯：Vivo X200 Ultra、Oppo Find X8 Ultra、小米 15 Ultra。首先排除小米（~~雷军！金凡！~~），vivo 的长焦增距确实很吸引我，简直演唱会神器，但鉴于我抢不到演唱会的门票，最终还是入手了主摄有一英寸大底的 Oppo Find X8 Ultra。截止目前已经换机有一个月了，迁移最主要的麻烦就是从 Apple 生态链中迁移过来，尤其是很多 App 开发者只开发 iOS 版，Android 版的 App 生态又是良莠不齐，寻找平替花了不少时间。由于无法解锁 BootLoader，root 就成了奢望，很多功能只能委屈一下了。

去广告

更换到国产安卓生态的最大问题，就是无处不在的广告。上手第一步，去广告：

完成后，就只剩下天气应用的二级页面下方的推荐广告去不掉了，和牛皮癣一样。

照片备份

此前由于使用的完整的苹果生态，所有的照片都在 iCloud 上，为此也开了 iCloud 200G 扩容，专用于存储照片，目前使用了 50G，包含了从本科开始的所有照片。前些日子把 NAS 更换为了飞牛系统，这些照片又同步备份了一份到飞牛自带的相册。

这次切换到安卓，品牌方自带的云肯定是不用的（说的就是你，欢太云），更换到 Google 相册的话，有比较麻烦。去年花了不少时间把相册从 Google Photos 导出到 iCloud，现在又导回去算个什么事情？另外 Google 云空间不开会员只有 15GB，虽然用校友邮箱薅了 Google AI Pro 的 2T 羊毛，但心里总是不踏实。

由于我的其他设备还是苹果，最终决定还是继续使用 iCloud 存储。Mac 上安装一个 O+ 互联，每天打开电脑是自动连接，就是需要手动导出再导入到 Apple 相册。说实话 O+ 互联的体验比 V 家的办公套件要差很多，不仅 Bug 多，功能还不完善：剪贴板无法同步、不支持 Mac 控制手机、无法自动同步照片，看 Oppo 那边也摆烂了，更新也不怎么勤快，凑活着用吧。

代理/回家

我的手机和电脑上都安装了代理软件，主要就是用于回家，即访问家里的网络环境，原因有二：

访问家里部署的服务，比如上面提到的相册和笔记服务
家中部署了 DNS 去广告和基于规则的透明代理，只要能连接回家，就无须再配置复杂的规则，享受和在家里一样的网络环境

之前使用 iPhone 时，Surge 我是 24 小时挂在后台的，全局回家。但如果人在家中时，还挂着全局连接家中的代理，会导致上不了网 Surge 有个很重要的功能，叫子网覆盖，可以根据当前连接的 WIFI SSID，执行一些动作，比如 SUSPEND 全局绕过代理。这样就完美解决了家中挂代理无法上网的问题，Surge 可以全程保持在后台了。

切换到安卓阵营，首先面临的问题就是选择太多，不同于 iOS 大部分都是自己实现的代理核心，安卓大都是直接复用开源的核心，如 mihomo（clash）、v2ray、xray 或比较新的 singbox，基于这些核心封装 UI 界面进而封装客户端，因此~~大部分~~几乎所有客户端都无法在 UI 上直接调整规则配置，只能通过上传或订阅配置文件。这倒是件小事，基于我的需求，配置文件一旦写成便几乎不会再变动。比较麻烦的是，很难找到一个客户端支持类似于 Surge 的子网覆盖功能，我可不想离家回家都得手动开关一次代理。

最终找到了一个比较小众的 SurfBoard，支持 SSID 规则，直接在规则最顶端增加一条 SSID 规则走 DIRECT，也算曲线救国实现了功能。更神奇的是，这个 App 兼容 Surge 格式的配置文件。

getsurfboardsurfboard

Loading repository data...

-- -- --

虽然 SurfBoard 默认是 FakeIP 无法修改，即使走 SSID 规则请求也会首先解析成 FakeIP，不如全局绕过来得更加彻底，但是聊胜于无吧。

记账

换机之前恰好养成了记账的习惯，至今记账也两月有余了，除了日常用钱时的记账之外，还会每天对账记录理财收益。iOS 上有个记账软件很推荐，叫 iCost，界面简洁但功能丰富，支持将快捷记账添加为系统捷径，可以通过敲击两下背板或者 iPhone 16 的快捷按钮唤醒，自动 AI 识屏并填写主要信息，全程只需要填一个分类即可。iCost 也有开发安卓端的规划，但是规划了两年多，进度缓慢。

小红书上搞记账软件的也很多，国人独立开发三大件：笔记、TODO 和记账。最终找到了一个比较老牌的记账软件：钱迹，开发时间似乎比 iCost 还长，并且支持多平台同步：iOS、MacOS、Android 甚至 Windows、鸿蒙 Next 都有支持，历史账单也可以很快捷地从 iCost 导入。该有的功能也一个不拉：资产管理、信用卡还款、退款、、多币种、多账本（虽然这个我用不到）。放个主页。

钱迹的自动记账感觉比 iCost 要好，不过或许是平台不同带来的差异。钱迹的自动记账基于的是系统的无障碍功能，在识别到当前打开的窗口是账单页面（支付宝或者微信）时，就会自动识别并弹出小窗快速记账。不过界面识别的准确度有待提升，有时从其他软件跳转支付宝付款完成的界面识别会失败，只能手动打开支付宝的支付记录中再识别一次，不过小瑕疵，能接受。

日历/TODO

iOS 18 最大的更新，就是打通了日历和提醒事项，在日历上可以直观查看和操作所有提醒事项，得益于 iOS 优秀的通知推送能力，提醒也十分及时，几乎算得上是 iOS 上最提升生产力的小工具了，比不少付费软件做的都好。切换到安卓后，首先排除的就是系统自带日历，完全不具备可迁移性，下一次换机一旦换一个品牌，数据就要全丢失了。

找来找去，中途微软的 Outlook 比较符合要求。作为一个邮件 app，日历功能做的出奇得好用。就是无法显示农历，只能通过订阅一些农历日历来展示，这样每天都会显示一些日程，由于 Outlook 本地化做的也不咋的，传统节日、节假日调休一概没有，又得多订阅一些日程，再加上农历生日、纪念日，整个日历一眼望去满满当当，眼花缭乱，哪一天真的有事情要做都没法直观看到。另外 Todo 功能薄弱，只能达到凑活用的水平。

无意中想到一个老牌的 Todo 软件：滴答清单，于是下载下来体验了一番，没想到就给我找到了 iOS 日历 + Todo 的最佳平替。上面提到的所有功能都直接支持：农历显示、农历日程、节假日调休、倒数日/纪念日、Todo 展示。不仅如此，我在 iOS Todo 上还得手动划分列表支持的四象限法，滴答清单直接原生支持，意外之喜啊。就是 139 元一年的会员价格有些不美了，不过这是我的问题。

Watch

切换到安卓生态后，终于摆脱了美丽废物 —— Apple Watch，终于不用一天充一次电了。用了 Oppo 的手机，自然要用 Oppo 的手表。购入了 Oppo Watch X2，几乎和一部全新的 Apple Watch 差不多贵了。

Oppo Watch X2 采用了现在智能手表比较少的圆形表盘，表盘样式也多是拟物主题，令人眼前一亮。我对手表的要求很低，能看时间、同步手机通知、同步手机闹钟、记录睡眠数据和其他健康数据即可。这款手表都能完美地解决，另外比较惊喜的是 HRV，这个在 Apple Watch 上基本被忽略掉、大部分情况下只能通过第三方 app 来展示提示的数据，在 Oppo 上得到了空前的重视，有一个专门的身心状态页面，还请来了孙颖莎代言。

尾声

折腾了那么多，终于是有一部用着舒服的手机了，拍照也得到了 npy 的认可，完美~

Astro 接入 Google Analytics (Tag Manager)

Wed, 28 May 2025 14:09:00 GMT

前言

不想看废话可直接跳转解决方案一节

此前一直在 Google Analytics 上看博客的访问量，分析各种 referer 等信息。使用 hexo 和 hugo 等静态博客框架，都可以很容易的接入 Google Analytics，直接在 head 标签中添加 js 代码即可。前些日子将博客迁移到了 Astro 框架，诚然可以用老办法，直接在 head 执行 js 代码上报事件，但是就会造成性能下降。众所周知，Astro 追求极致前端性能、尽量 0 JS 执行。一旦使用 js 上报事件，就会造成性能损失

性能满昏！

于是网上冲浪了一番，搜到的大部分教程是使用 partytown 来将脚本剥离主线程执行，不阻塞主线程加载，以保证性能，并都给出了 demo 代码。于是在给出的 demo 基础上，我将其嵌入了我的博客。于是就得到了以下结果：

上报直接掉零了

很难绷，于是开始了漫长的排查，始终没能找到问题所在。网上找到的所有相关例子都和我的方式相同。都有些奇怪，这些人写完教程都不自己测试一下吗，完全不可用啊

只得将其搁置了俩月，期间临时改用了 umami 统计数据

这两天又想了起来，如芒在背如鲠在喉，于是又开始了漫长的搜索。最终在 GitHub 的一个角落中找到了解决方案

解决方案

安装 @astrojs/partytown，直接使用你的包管理器安装即可

<head> 标签中添加以下代码

<script is:inline src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXX" type="text/partytown"></script>
<script is:inline type="text/partytown">
  window.dataLayer = window.dataLayer || [];
  window.gtag = function () {
        dataLayer.push(arguments);
    };
  window.gtag('js', new Date());
  window.gtag('config', 'G-XXXXXXXXX');
</script>

有以下几个注意点：

is:inline 指示脚本在客户端执行
type="text/partytown" 指示脚本由 partytown 执行，而不在主线程执行
gtag 函数必须定义为 window 对象的一个函数变量，不能定义为一个函数声明（很奇怪）

在 astro 的配置文件（形如是 astro.config.ts 或 astro.config.mjs）中添加以下配置

import partytown from '@astrojs/partytown'

export default defineConfig({
  // ...
  integrations: [partytown({ config: { forward: ['dataLayer.push', 'gtag'] } })],
});

大部分教程都没有提到还需要将 gtag 加入 forward 数组

完成！提交部署后，Google Analytics 的统计数据就可以正常上报了

上海杭州异地组网记录

Fri, 18 Apr 2025 08:43:12 GMT

前言

这个月 npy 因为工作原因，从北京搬到了上海

帮忙搬家之外，还帮着开了一条宽带，电信 500M

顺便吐槽下上海电信，500M 的宽带比杭州电信 1000M 宽带还贵

~~你这光纤是金子做的还是光猫是金子做的？~~

作为一名 Geek（自封），不折腾是不可能的，合计了一下，预期要达成以下成果

上海透明代理越墙
上海部分流量从杭州出口
两地局域网互访

第二条的原因是目前 Netflix 等流媒体解锁是走的机场（此处可插入 aff），这个机场限制了使用用户，多地同时使用可能会导致封号，这种情况下就只能将流量转发到杭州，从杭州统一出口

前置准备

目前杭州的网络拓扑很简单，光猫拖一个软路由拨号，软路由接一个 TP-Link 做无线 AP。同时有个小主机直连软路由，开了一个 shadowsocks server 用于日常流量回家。软路由是倍控的 G30S（此处可插入广告），N5100 也是够用的，系统是 ImmortalWRT。装了以下插件

AdguardHome：DNS 去广告
Nikki：Mihomo 内核，做透明代理
Tailscale：虚拟局域网组网，此前一直用作流量回家的备案
DDNS-Go：如你所见，就是个 DDNS

LAN 网段为 192.168.7.0/24

为了保持设备一致，降低一点复杂度，于是又购置了一台相同配置的 G30S，也安装了 ImmortalWRT。同时上海的网络拓扑计划与杭州保持一致。光猫 - 软路由 - AP

安装

ImmortalWRT 的安装得提一嘴，最初以为它的安装和 windows 或者其他 linux 发行版类似，镜像是个 livecd 或者安装器之类的，写入 u 盘启动后执行安装。没想到 u 盘启动后竟然就这么启动了……

启动了……

合着那个 img 直接就是系统镜像啊

于是麻溜改刷 winpe，用 physdiskwrite 把镜像写到硬盘，成功启动，简单配置完成了上网和 dhcp。上海的 LAN 网段为 192.168.10.0/24

接着就是扩容，直接写盘安装的 openwrt，可用空间只有不到 1G，硬盘的其他剩余空间完全浪费掉了。这时候第二个困难就出现了：我找不到何时的扩容教程。简中的教程错综复杂、错误百出、一个抄一个，但实际上，要么就是 squashfs 的扩容，要么就是用剩余空间新建一个分区，将根分区改挂到新分区上这样的教程，几乎找不到真正的“扩容”分区

最后在 OpenWRT 的官方文档中找到了……以后还是不用中文搜索了，Google 都搜不出啥有用的

先解决越墙和流量出口的问题，这个直接 clash 就能解决

Nikki 是一个 OpenWRT 插件，基于 Mihomo 内核进行透明代理。相对于其他类似功能的插件如 Passwall 或者 clash，Nikki 的可定制化更强。注意安装要根据 Readme 中的 Instruction 安装，直接从 Releases 下载 ipk 是无法安装的（很奇怪）

nikkinikki-orgOpenWrt-nikki

Loading repository data...

-- -- --

安装完成后导入配置文件，就可以启动了。有几个注意点：

可以直接开启 tun 模式，会自动配置路由器的路由表做透明代理，基本没什么问题
mihomo 的域名分流需要 dns 请求通过 mihomo 发起，这时有两个选择：mihomo 的 dns 直接 hijack 53 端口，openwrt 自带的 dnsmasq 可以改为监听其他端口；或者 dnsmasq 设置一个转发，将 dns 请求都转发到 mihomo 的 dns 端口
如果使用 FakeIP 模式，注意仔细设置 FakeIP Filter

其他就是一些老生长谈，和其他平台使用 mihomo 基本一致，不再赘述

配置完成后开启 Nikki，在 Dashboard 中就能看到 mihomo 开始接管路由器的所有出口流量了

配置文件基本是直接从我这儿粘过去的，大部分越墙流量都是向搬瓦工🪜直接发起连接，一些需要流量从杭州出口的规则，outbound 都改为了杭州的 shadowsocks server，试了下延迟还可以，就当是走了一道国内中转

到这一步，其实通过域名的话已经可以实现上海访问杭州的内网，由于是 FakeIP 模式，dns 解析后返回的 fakeip 请求也会被 mihomo 内核处理，再通过域名规则将流量转到杭州即可。但是这样的话，直接的 ip 请求，不通过 dns，就无法通过 mihomo 转发（tun 默认不接管局域网请求），且杭州也没法访问到上海

于是，TailScale 堂堂登场！

OpenWRT 使用 TailScale 可以用 luci-app-tailscale 插件，可以比较直观地管理和配置 tailscale

asvowluci-app-tailscale

Loading repository data...

-- -- --

安装完成后首先启动一下，完成登录认证，再进行配置，最好在 tailscale 关闭这个设备的密钥过期

高级设置中

勾选启用路由：tailscale 自动帮我们配置到其他子网的路由规则
不勾选允许 dns：只需要路由 ip 请求即可
公开网段填写 192.168.10.0/24：告诉 tailscale 这台设备可以进行这个网段的路由
勾选子网互通：字面意思
子网路由选择 192.168.7.0/24：表示这个子网范围的路由由 tailscale 接管

注意，杭州的 tailscale 也要做对应的设置，注意公开网段和子网路由要用对应的网段

设置完成后重启一下 tailscale，就可以完成子网互通了。在上海和杭州都可以直接通过对方网段的 IP 直接访问对方网段的主机

后记

上海的宽带安装的是一个什么云宽带，关闭云宽带并且开启桥接的流程非常麻烦（至今没走完）

所以以上配置都是在上海的软路由没有公网 IP 的情况下进行的

好在由于杭州这边有公网 IP，tailscale 也是可以直接打洞成功，延时只有十几毫秒。如果两边都没有公网 IP，那就只能自求多福了，要么就自建 derp 转发，要么就只能顶着大几百的延时凑活着用了

还是想吐槽下上海电信，开个桥接又要签协议又要拍照又要审核的，和防贼似的

My heart beats for U —— 心率同步 Grafana 展示

Mon, 31 Mar 2025 15:51:00 GMT

整了个小活：把苹果健康的心率定时同步到服务器上，并由 Grafana 绘制展示，效果大概如下：

~~可以点击博客右上角的 ♥️ 标志查看，因为套了 Cloudflare Tunnel，国内访问速度不佳，尽量挂🪜访问。~~已下线，由于更换了 Oppo 手机，心率无法同步上传了

大概的思路就是使用这个 app Health Auto Export - JSON+CSV 的 Restful API 的功能，设置定时将心率数据发送到部署的 http 接口以写入 InfluxDB，再由 Grafana 连接 InfluxDB 绘制看板

Health Auto Export - JSON+CSV 这个 app 如果想要定时同步，需要开通 Premium，Lifetime 美区是 24.99 USD，有点小贵，但似乎也没有什么平替方案

订阅后新建一个 Automation：

Automation Type 为 REST API
URL 就是你下面要部署的服务的地址，API 路径为 /push/heart_rate
Data Type 选择 Health Metrics
Select Health Metrics 勾选 Heart Rate
Export Format 选择 JSON
Sync Cadence 可以选择 1 分钟也可以选择 5 分钟，Apple Watch 并不会一直监测心率

勾上 Enable 即可，为了保证在程序退出后还能同步，可以添加一个桌面小组件

接着就是部署服务开放 Restful API 端口，接收数据并写入 InfluxDB 了。部署 InfluxDB 可以自行 Google 不再赘述，注意服务用的是 InfluxDB 2

服务的源码在 reekystive/healthkit-collector，是个 node 项目，可以直接用 pnpm 启动监听 3000 端口。我写了个 Dockerfile 将其打包成 docker 镜像，部署在家里的服务器上

FROM node:20-alpine AS builder

# Install pnpm
RUN corepack enable && corepack prepare pnpm@9.14.2 --activate

# Set working directory
WORKDIR /app

# Copy package.json and pnpm-lock.yaml
COPY package.json pnpm-lock.yaml* ./

# Install dependencies
RUN pnpm install --frozen-lockfile

# Copy source code
COPY . .

# Build the application
RUN pnpm build

# Stage 2: Production stage
FROM node:20-alpine AS production

# Install pnpm
RUN corepack enable && corepack prepare pnpm@9.14.2 --activate

FROM node:20-alpine AS builder

# Install pnpm
RUN corepack enable && corepack prepare pnpm@9.14.2 --activate

# Set working directory
WORKDIR /app

# Copy package.json and pnpm-lock.yaml
COPY package.json pnpm-lock.yaml* ./

# Install dependencies
RUN pnpm install --frozen-lockfile

# Copy source code
COPY . .

# Build the application
RUN pnpm build

# Stage 2: Production stage
FROM node:20-alpine AS production

# Install pnpm
RUN corepack enable && corepack prepare pnpm@9.14.2 --activate

# Set working directory
WORKDIR /app

# Copy package.json and pnpm-lock.yaml
COPY package.json pnpm-lock.yaml* ./

# Install production dependencies only
RUN pnpm install --prod --frozen-lockfile

# Copy built application from builder stage
COPY --from=builder /app/dist ./dist

# Set environment variables
# These are default values that can be overridden when running the container
ENV NODE_ENV=production
ENV PORT=3000

# Expose the port your app runs on (using the PORT environment variable)
EXPOSE ${PORT}

# Command to run the application
CMD ["node", "dist/index.js"]

启动时需要设置四个连接 InfluxDB 使用的环境变量

INFLUXDB_TOKEN='your_influxdb_token'
INFLUXDB_URL='your_influxdb_url'
INFLUXDB_ORG='your_influxdb_org'
INFLUXDB_BUCKET='your_influxdb_bucket'

部署完成后可以尝试进行一次同步，服务会输出写入 DB 成功的 log

最后就是部署个 Grafana 绘制仪表盘了，添加好 Data Source，新建仪表盘，查询语句如下

from(bucket: "bpm")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "heart_rate")
  |> filter(fn: (r) => r["_field"] == "avg" or r["_field"] == "max" or r["_field"] == "min")

Enjoy！

语法分析中类型名-变量名歧义消除

Sat, 15 Mar 2025 12:35:00 GMT

引

由于语法分析阶段不维护符号表，用户自定义类型名（typedef）和普通变量名难以区分。对于函数体中的 a*b; 语句，既可以解释为 a 乘 b，忽略表达式结果，也可以解释为声明一个类型为 a* 的变量 b

同时，由于存在如下语法规则

declaration := declaration_specifiers SEMICOLON
declaration_specifiers := type_specifier declaration_specifiers
type_specifier := INT
type_specifier := typedef_name
typedef_name := IDENTIFIER

规则 1 多用于无需指定标识符的结构体前向声明。如 struct Node; 表示前向声明一个 struct Node 类型。由于该规则的存在，譬如 int a; 也可能会使用规则 1 规约，符号 a 会被识别为一个用户自定义类型名而非变量名。由于类似的无初始化变量的定义语句容易在源码中大量出现，会导致一份源码会对应较多满足语法规则的 AST。这个问题可以在语义分析阶段通过维护符号表解决，但是在语法分析阶段也可以以较小的代价提前处理，减少语义分析需要处理的 AST 个数

思路

对于这种类型名 - 变量名的歧义，可以在 GLR 的执行过程中或执行后通过维护代价较小的简易符号表的方式对错误的分支进行剪枝。这个符号表至少要维护变量名和用户自定义类型名，同时由于存在深层作用域变量/类型名对浅层作用域符号的遮蔽，这个符号表还需要跟踪符号的作用域

那么需要做的事情就很简单了：

维护符号表，收集类型定义和变量声明
添加符号时校验同级作用域是否有同名变量声明和类型定义
对所有使用 primary_expression := IDENTIFIER 规约的节点检查 IDENTIFIER 是否是一个已经定义且未被遮蔽的变量名
对所有使用 typedef_name := IDENTIFIER 规约的节点检查 IDENTIFIER 是否是一个已经定义过且未被遮蔽的用户自定义类型名

以经典 a*b; 为例：

// 例 1
typedef int a;
func test_func()
{
	a*b;
}

// 例 2
typedef int a;
func test_func()
{
	int a;
	a*b;
}

例 1：解析到 a*b; 时，符号表的 1 级作用域（最外层）中有一个自定义类型 a，2 级作用域（函数）中无符号。对于将 a*b; 解析为声明一个类型为 a* 的变量 b 的 AST，a 会使用 typedef_name := IDENTIFIER 进行规约，检查符号表发现 a 确实是一个声明在 1 级作用域的自定义类型名，于是该 AST 会被保留；对于将其解析为变量 a 乘以变量 b 的 AST，a 会使用 primary_expression := IDENTIFIER 进行规约，检查符号表发现表中并没有变量 a，于是该 AST 会被抛弃

例 2：解析到 a*b; 时，符号表的 1 级作用域（最外层）中有一个自定义类型 a，，2 级作用域（函数）中有一个变量 a，此时变量 a 会遮蔽自定义类型 a。对于将 a*b; 解析为声明一个类型为 a* 的变量 b 的 AST，a 会使用 typedef_name := IDENTIFIER 进行规约，检查符号表发现在该作用域下 a 是一个变量而非自定义类型（遮蔽），于是该 AST 会被抛弃；对于将其解析为变量 a 乘以变量 b 的 AST，a 会使用 primary_expression := IDENTIFIER 进行规约，检查符号表发现 a 确实是一个变量名，于是该 AST 会被保留

相对于完整的符号表，简易符号表不会检查作用域内同类变量的同名问题（可以检查用户自定义类型名的同名），由于存在前向声明，对相同变量的多次声明是合法的，而包含初始化的声明只可以有一次，在语法分析阶段区分声明是否包含初始化成本还是比较高的，建议延后到语义分析阶段；同时由于成本问题类型检查也不会在这个阶段进行

在 GLR 执行过程维护简易符号表，难以处理函数参数和 for 循环中的变量声明，这些变量的作用域实际在更深层，且作用域的开始和结束并不完全和大括号的范围重合，由于对于函数定义的规约，一定是首先移入左右大括号，之后才能规约为函数定义，这就导致没法简单地在移入左右大括号时处理作用域，只有综合看当前符号栈中的多个符号才能判断。究其原因，是因为 GLR 构建 AST 是自底向下构建的——从叶子节点一步步构建出根节点，底层节点会被优先处理，从而缺乏对节点上下文的感知

在 GLR 执行完成后通过遍历 AST 森林对单棵 AST 进行检查排除的方法就相对简单了很多，尽管无法在执行中剪枝，导致了相对较高的时间和空间复杂度，但是其优点在于实现简单、实现简单和实现简单。在实际实现过程中，可以综合使用执行中剪枝和执行后排除：执行中剪枝代价较小，且一旦剪枝成功，就能够减少执行后排除需要处理的 AST 数量。由于执行后排除一定可以解决该歧义，执行中剪枝需要保证“宁可放过不可错杀”

AST 构建中

AST 构建中可以在移入一些符号或发生规约时，在节点中存储一些信息并向上传递，方便后续再自顶向下处理时可以快速获取信息，对于处理这个歧义，我的处理是增加两个标记

type GLRLabel struct {
	// Declaration 使用，规约出 Declaration 后消除
	TypeDef      bool     // 是否是 TypeDef
	DeclaratorID []*Token // 包含的 Identifier
}

typedef 用于标识这个声明是否是一个类型定义，如果最终规约出 declaration 时没有这个标识，说明这个声明只是一个普通的变量声明。DeclaratorID 为这个 declaration 定义的符号，如果这个声明是一个类型定义，那么 DeclaratorID 中为自定义类型的名称。同样，由于 function_definition 中的函数名称也使用了和 declaration 类似的 declarator 处理（function_definition := declaration_specifiers declarator compound_statement），所以 DeclaratorID 中也会包含函数名称

这两个符号在构建 AST 树时，从下层向上层节点传递

gslice.ForEach(children, func(child *AstNode) {
    if child.TypeDef {
        parent.TypeDef = true
    }
    parent.DeclaratorID = append(parent.DeclaratorID, child.DeclaratorID...)
})

那么在哪些场景设置这两个符号呢？

typedef 很明显，当使用 storage_class_specifier := TYPEDEF进行规约时设置当前节点的 typedef 为 true

DeclaratorID 就比较复杂了，比较基础的如 direct_declarator := IDENTIFIER。另外，考虑枚举常量的场景，还需要处理 enumeration_constant := IDENTIFIER

当然，不能允许这两个符号无限向上传播，构建后自顶向下处理某一节点时应当只期望处理该级节点的信息，而非混杂着下层节点的信息（由于 C 语言中作用域的限制，信息只能从上级向下级传递，下级信息无法影响上级）。这时就需要在规约出某些节点时清空标记，阻断标记的向上传播

阻断向上传播的时机，除了规约出 declaration 和 function_definition 外，规约出 direct_declarator时，对于通过形如 direct_declarator := direct_declarator LEFT_PARENTHESES parameter_type_list RIGHT_PARENTHESES 规约出的节点，应当只取右侧 direct_declarator中的 DeclaratorID 继续传播，以避免 parameter_type_list 包含函数参数声明的影响

在 AST 构建中，可以进行的、确定无误的检查，有以下两个：

使用用户自定义类型时，检查是否是先前声明过的类型（无法检查变量声明遮蔽）
declaration_specifiers中如果包含自定义类型的 type_specifier，那么只可以包含这一个 type_specifier（自定义类型已是完整类型，不应和其他类型符号一起使用）

第一个检查在构建时维护一个自定义类型符号栈，在移入 { 时压入新作用域，在移入 } 时弹出顶栈作用域。在规约出 Declaration 时，检查节点的 typedef 符号，如果是一个 typedef，就将这个节点的所有 DeclaratorID 加入顶栈作用域。在遇到通过 typedef_name := IDENTIFIER 规约的节点时，说明这个 IDENTIFIER 是一个此前定义的自定义类型，从栈顶开始向栈底检查即可

第二个检查比较简单，在规约出 declaration、function_definition 和 parameter_declaration 时，检查 declaration_specifiers 即可

AST 构建后

在通过上述方式完成构建后，由于构建中的检查只处理了自定义类型，没有处理变量名，所以依然会有一些错误和歧义无法解决，如

typedef int a;
int main() {
	int a;
	a c;	// 类型 a 已经被变量 a 遮蔽，此处声明不合法
}

所以在构建后需要维护一个相对更全面一些的符号表，在每个作用域中同时记录类型名和变量名

type ScopeSymbols struct {
	TypeNames map[string]*entity.Token
	VarNames  map[string]*entity.Token
}

和构建中检查类似，在移入 { 时压入新作用域，在移入 } 时弹出栈顶作用域，遇到 declaration 节点，如果包含 typedef 符号，则将 DeclaratorID 加入栈顶作用域的类型名处，否则加入栈顶作用域的变量名中。在加入变量名时，需要检查栈顶作用域是否包含同名的类型名，若包含则需要返回错误；反之加入类型名时亦然

除此以外，函数定义中的函数名也需要作为变量符号加入符号表，函数变量的定义都形如function_definition := declaration_specifiers declarator...，declarator 中的 DeclaratorID 即为函数名

接着就是检查自定义类型名和变量名的使用点了。自定义类型仅在 typedef_name := IDENTIFIER 处使用，在 AST 构建中已经检查过这个自定义类型是否已经定义过。在构建后检查中，需要额外检查这个类型名是否被变量名遮蔽，如果在更深层作用域中被遮蔽时仍然需要返回错误。变量名则是在 primary_expression := IDENTIFIER 处，其检查和类型名的检查类似

一个简单的变量名检查的例子

func (s *symbolStack) CheckVar(token *entity.Token, depth int) error {
	for i := depth; i >= 0; i-- {
		if previous, ok := s.stack[i].TypeNames[token.Lexeme]; ok {
			return InvalidSymbolKind(token.SourceStart, previous.SourceStart, token.Lexeme)
		}
		if _, ok := s.stack[i].VarNames[token.Lexeme]; ok {
			return nil
		}
	}
	return UndeclaredIdentifier(token.SourceStart, token.Lexeme)
}

在函数定义和 for 循环中，需要特殊处理作用域。函数定义中的函数参数和 for 循环条件（括号中的内容），并不在函数/循环所在的作用域中，而在其内层作用域，在函数体/循环体作用域中，以 for 循环为例

currentSymbolStackDepth := s.symbolStack.currentSymbolStackDepth
s.symbolStack.SwitchScope(currentSymbolStackDepth + 1)	// 切换到深层作用域
for i := 0; i < len(node.Children)-1; i++ {
	if err := s.Chop(node.Children[i]); err != nil {
		return err
	}
}
s.symbolStack.SwitchScope(currentSymbolStackDepth)		// 切换回当前作用域
if err := s.Chop(node.Children[len(node.Children)-1]); err != nil {
	// 如果循环体中包含 {，则会自然进入
	return err
}
s.symbolStack.EnterScope(currentSymbolStackDepth)		// 若不存在循环体，则会导致深层作用域无法弹出，这里强行重置一下

VPS 套 Warp 分流指定出口 IPv6

Sat, 15 Mar 2025 08:24:00 GMT

上周一个普通的下午，一直挂在后台沉寂许久的 Telegram 收到了一条推送：

定睛一看，电信 CN2 直连，2.5G 带宽，1T 流量，券后 36 刀一年，合 3 刀一个月

新的传家宝已经出现！

火速付款之余，立即呼朋唤友，忽悠了周围三四个同事都入手了

这个套餐是自带 IPv6 的，对于各种流媒体解锁都有好处。当然依然有很多 VPS 没有 IPv6 地址，并且中国有句古话叫狡兔三窟，出门在外还是得套个马甲的。这时候就需要用到大善人 Cloudflare 家的 Warp 了

此前使用的 warp 脚本是 scarmen/warp，直接启动全局模式，就会将整个 VPS 的全局出口都重定位到 warp。但是有两点问题：

warp 降速，并非所有的出口流量都需要走 warp。通常只有一些如 Netflix、OpenAI 之类的对 IP 要求比较高的服务需要走 warp
warp 接管全局流量后，即使是双栈出口，但是有时出口会优先走 IPv4。由于 DNS 解析发生在 warp 内部（远程 DNS 解析），无法做干预

对于问题 1，warp 脚本可以开启非全局模式，并在本地开放一个 socks 代理，可以使用代理软件分流。对于问题 2，则可以通过代理软件让 DNS 解析发生在本地，完成解析后再将流量通过 warp 出口

非全局的 warp，可以在安装脚本时直接选择

wget -N https://gitlab.com/fscarmen/warp/-/raw/main/menu.sh && bash menu.sh c

也可以安装完成后在菜单中选择，WARP Linux Client 或 wireproxy 都可以

开启后 socks 默认会开放在本机 40000 端口

有了这个 socks 服务，添加 socks 出口，再根据需要分流即可。以 xray 为例，clash 和 sing-box 类似

{
  "outbounds": [
    {
      "tag": "warp",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 40000
          }
        ]
      }
    }
  ]
}

直接设置代理软件的出口为 socks5 服务，就会触发远程 DNS 解析，导致出口 IPv4/IPv6 不稳定，这里可以通过本地 DNS 的方式解决

本地 dns 就需要代理软件开启 dns 模块

{
  "dns": {
    "servers": [
      "2606:4700:4700::1111",
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP",
    "tag": "dns_inbound"
  }
}

出口添加为一个链式代理

{
  "outbounds": [
    {
      "tag": "warp",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIPv6v4"
      },
      "proxySettings": {
        "tag": "warp-inner"
      }
    },
    {
      "tag": "warp-inner",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 40000
          }
        ]
      }
    }
  ]

{
  "outbounds": [
    {
      "tag": "warp",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIPv6v4"
      },
      "proxySettings": {
        "tag": "warp-inner"
      }
    },
    {
      "tag": "warp-inner",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 40000
          }
        ]
      }
    }
  ]
}

先通过一个 freedom 出口解析域名，UseIPv6v4 表示优先使用解析出的 IPv6 地址，如果没有 IPv6 再使用 IPv4，再通过 proxySettings 将流量导入 warp-inner 出口，也就是之前设置的 socks，即 warp

这样如果访问的网站支持 IPv6，那么通过 warp tag 访问该网站就必然通过 IPv6 访问

在 VitePress 中实现一个动态说说功能

Wed, 29 Jan 2025 13:58:00 GMT

前言

很多动态博客中都有一个说说的功能，本质就是一种特殊的博文，借助动态博客的实时性，可以做到随写随发

静态博客由于是在本地或服务器上静态编译成 html 后再部署，实时性比较差。写一篇博文长篇大论自然可以在电脑前，走 git 推送部署也不算麻烦，但是发一篇说说还要打开电脑，心智负担就有些重了，手机上操作 git 也比较麻烦，不是很优雅，干脆一想就不发算了

于是实现了一套说说系统的前后端，效果就是本博客的碎碎念。后端使用 CloudFlare Workers 实现，存储当然也就近存储在大善人的 KV 里，简单写了个管理页面。博客框架是 VitePress，前端也就做成了个 Vue 组件，直接嵌入一个页面作为说说页

前端效果不再多说，后端管理页面效果

后端 CloudFlare Workers + KV

基本概述

后端包含以下功能：

支持说说的增删改（基本功能）
页面和所有写接口都有鉴权，足够安全
Markdown 格式实时预览（by marked）

KV 中存储一个 index key，value 是一个 uid 的数组，作为全部说说的索引。其他所有说说都存储在以 uid 为 key 的条目中，value 格式如

{
    "uid":"唯一 id",
    "createTime":"发布时间",
    "content":"说说内容",
}

实现

首先要创建一个 CloudFlare 的 KV Space，专门存储说说相关的 KV 对。位置在账户首页 - 存储和数据库 - KV，点击创建，名字不太重要，记住就行了，我这里简单命名为 memos

接着就是创建 CloudFlare Workers，用于逻辑处理。位置在账户首页 - 计算（Workers）- Workers 和 Pages，点击创建，名字依然不太重要，我简单命名为 memos-api。创建完成后，点击 Workers 名称进入 Workers 详情，在设置 - 绑定中添加一个绑定关系，选择绑定 KV 命名空间，变量名称为 KV，KV 命名空间选择刚刚创建的 KV Space 名称，我的是 memos。这样绑定完成后，就可以在代码中直接使用 env.KV 操作 memos 这个 KV 空间了。最后点击顶栏右侧的 编辑代码 按钮

下面就是 Code Time！

首先创建一个 index.html，用来存放管理页面的 html、css 和 js

<!DOCTYPE html>
<html>

<head>
    <title>Memos 管理</title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.0.0/css/all.min.css">
    <style>
        :root {
            --primary-color: #2c3e50;
            --secondary-color: #34495e;
            --accent-color: #3498db;
            --background-color: #f5f6fa;
            --text-color: #2c3e50;
            --border-color: #dcdde1;
            --hover-color: #f1f2f6;
        }

        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }

<!DOCTYPE html>
<html>

<head>
    <title>Memos 管理</title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.0.0/css/all.min.css">
    <style>
        :root {
            --primary-color: #2c3e50;
            --secondary-color: #34495e;
            --accent-color: #3498db;
            --background-color: #f5f6fa;
            --text-color: #2c3e50;
            --border-color: #dcdde1;
            --hover-color: #f1f2f6;
        }

        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }

        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, sans-serif;
            background-color: var(--background-color);
            color: var(--text-color);
            line-height: 1.6;
        }

        #auth-panel {
            position: fixed;
            top: 0;
            left: 0;
            width: 100%;
            height: 100%;
            background: rgba(255, 255, 255, 0.95);
            display: flex;
            justify-content: center;
            align-items: center;
            z-index: 1000;
            backdrop-filter: blur(5px);
        }

        #auth-form {
            background: white;
            padding: 2rem;
            border-radius: 10px;
            box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
            width: 300px;
        }

        #auth-form input {
            width: 100%;
            padding: 0.8rem;
            margin-bottom: 1rem;
            border: 1px solid var(--border-color);
            border-radius: 5px;
            font-size: 1rem;
        }

        .container {
            max-width: 1400px;
            margin: 2rem auto;
            padding: 0 1rem;
            display: flex;
            gap: 2rem;
            height: calc(100vh - 4rem);
        }

        .memo-list {
            width: 350px;
            background: white;
            border-radius: 10px;
            box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
            display: flex;
            flex-direction: column;
        }

        .memo-list-header {
            padding: 1rem;
            border-bottom: 1px solid var(--border-color);
            font-weight: 600;
            display: flex;
            justify-content: space-between;
            align-items: center;
        }

        .memo-items {
            flex: 1;
            overflow-y: auto;
            padding: 0.5rem;
        }

        .memo-item {
            padding: 1rem;
            border-radius: 8px;
            margin-bottom: 0.5rem;
            cursor: pointer;
            transition: all 0.2s ease;
            border: 1px solid var(--border-color);
            height: auto;
            /* 移除固定高度 */
            overflow: hidden;
            position: relative;
            display: flex;
            flex-direction: column;
            gap: 0.5rem;
        }

        .memo-item:hover {
            background-color: var(--hover-color);
            transform: translateY(-2px);
        }

        .memo-item.active {
            border-color: var(--accent-color);
            background-color: var(--hover-color);
        }

        .memo-detail {
            flex: 1;
            background: white;
            border-radius: 10px;
            box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
            display: flex;
            flex-direction: column;
        }

        .memo-detail-header {
            display: flex;
            justify-content: space-between;
            align-items: center;
        }

        .memo-item-header {
            display: flex;
            justify-content: space-between;
            font-size: 0.8rem;
            color: #666;
            border-bottom: 1px solid var(--border-color);
            padding-bottom: 0.5rem;
        }

        .memo-item-content {
            font-size: 0.9rem;
            line-height: 1.4;
            max-height: 4.2em;
            /* 显示 3 行文本 */
            overflow: hidden;
            display: -webkit-box;
            -webkit-line-clamp: 3;
            -webkit-box-orient: vertical;
        }

        .memo-uid {
            font-family: monospace;
            color: var(--accent-color);
        }

        .memo-info {
            font-size: 0.9rem;
            color: #666;
            margin-left: 10px;
            margin-top: 10px;
        }

        .memo-content {
            flex: 1;
            display: flex;
            flex-direction: column;
            padding: 1rem;
            gap: 1rem;
        }

        .memo-edit {
            flex: 1;
        }

        .memo-edit textarea {
            width: 100%;
            height: 100%;
            border: 1px solid var(--border-color);
            border-radius: 5px;
            padding: 1rem;
            font-size: 1rem;
            resize: vertical;
            font-family: inherit;
        }

        .memo-preview {
            flex: 1;
            padding: 1rem;
            border: 1px solid var(--border-color);
            border-radius: 5px;
            overflow-y: auto;
            overflow-x: hidden;
            background-color: var(--background-color);
        }

        .memo-preview img {
            max-width: 100%;
            max-height: 150px;
            object-fit: contain;
            display: block;
            /* 避免图片底部空隙 */
            margin: 5px 0;
        }

        .memo-preview blockquote {
            border-left: 2px solid #e2e2e3;
            padding-left: 16px;
            color: rgba(60, 60, 67, .78);
        }

        .memo-actions {
            padding: 1rem;
            border-top: 1px solid var(--border-color);
            display: flex;
            justify-content: flex-end;
            gap: 1rem;
        }

        .pagination {
            padding: 1rem;
            display: flex;
            justify-content: center;
            align-items: center;
            gap: 1rem;
            border-top: 1px solid var(--border-color);
        }

        button {
            padding: 0.5rem 1rem;
            border: none;
            border-radius: 5px;
            cursor: pointer;
            transition: all 0.2s ease;
            font-size: 0.9rem;
            background-color: var(--primary-color);
            color: white;
        }

        button:hover {
            opacity: 0.9;
        }

        button.secondary {
            background-color: var(--secondary-color);
        }

        button.danger {
            background-color: #e74c3c;
        }

        .create-btn {
            padding: 0.5rem 1rem;
            display: flex;
            align-items: center;
            gap: 0.5rem;
            margin-right: 10px;
            margin-top: 10px;
        }

        /* Responsive Design */
        @media (max-width: 768px) {
            .container {
                flex-direction: column;
                height: auto;
            }

            .memo-list {
                width: 100%;
                height: 300px;
            }

            .memo-detail {
                height: calc(100vh - 400px);
            }

            .memo-preview img {
                max-height: 100px;
            }
        }

        /* Markdown Preview Styles */
        .memo-preview h1,
        .memo-preview h2,
        .memo-preview h3 {
            margin-top: 1rem;
            margin-bottom: 0.5rem;
        }

        .memo-preview p {
            margin-bottom: 1rem;
        }

        .memo-preview code {
            background-color: #f8f9fa;
            padding: 0.2rem 0.4rem;
            border-radius: 3px;
            font-family: monospace;
        }

        .memo-preview pre {
            background-color: #f8f9fa;
            padding: 1rem;
            border-radius: 5px;
            overflow-x: auto;
        }

        /* Loading Spinner */
        .loading {
            display: inline-block;
            width: 20px;
            height: 20px;
            border: 2px solid rgba(0, 0, 0, 0.1);
            border-radius: 50%;
            border-top-color: var(--accent-color);
            animation: spin 1s ease-in-out infinite;
        }

        @keyframes spin {
            to {
                transform: rotate(360deg);
            }
        }
    </style>
</head>

<body>
    <div id="auth-panel">
        <form id="auth-form">
            <h2 style="margin-bottom: 1rem;">Memos 管理</h2>
            <input type="password" id="password" placeholder="Enter password" required>
            <button type="submit" style="width: 100%">登录</button>
        </form>
    </div>

    <div class="container">
        <div class="memo-list">
            <div class="memo-list-header">
                <span>已发布</span>
                <span id="memo-count"></span>
            </div>
            <div class="memo-items" id="memo-items"></div>
            <div class="pagination">
                <button onclick="prevPage()" class="secondary">
                    <i class="fas fa-chevron-left"></i>
                </button>
                <span id="page-info"></span>
                <button onclick="nextPage()" class="secondary">
                    <i class="fas fa-chevron-right"></i>
                </button>
            </div>
        </div>

        <div class="memo-detail">
            <div class="memo-detail-header">
                <div class="memo-info" id="memo-info">新 Memo</div>
                <button class="create-btn" onclick="createMemo()">
                    <i class="fas fa-plus"></i> 发布新 Memo
                </button>
            </div>
            <div class="memo-content">
                <div class="memo-edit">
                    <textarea id="memo-content" placeholder="Write your memo here..."></textarea>
                </div>
                <div class="memo-preview" id="memo-preview"></div>
            </div>
            <div class="memo-actions">
                <button onclick="saveMemo()" id="save-btn">
                    <i class="fas fa-save"></i> 保存
                </button>
                <button onclick="deleteMemo()" class="danger" id="delete-btn">
                    <i class="fas fa-trash"></i> 删除
                </button>
            </div>
        </div>
    </div>

    <script src="https://cdnjs.cloudflare.com/ajax/libs/marked/2.0.3/marked.min.js"></script>
    <!-- JavaScript 代码与之前相同，但需要添加以下功能增强 -->
    <script>
        let password = '';
        let currentMemo = null;
        let offset = 0;
        const limit = 10;
        let total = 0;
        let currentPageMap = {};

        // Authentication
        document.getElementById('auth-form').addEventListener('submit', async (e) => {
            e.preventDefault();
            password = document.getElementById('password').value;
            try {
                const response = await fetch('/api/auth', {
                    method: 'POST',
                    headers: {
                        'Content-Type': 'application/json',
                    },
                    body: JSON.stringify({ password }),
                });
                if (response.ok) {
                    document.getElementById('auth-panel').style.display = 'none';
                    loadMemos();
                } else {
                    showNotification('密码错误', 'error');
                }
            } catch (error) {
                showNotification('密码错误', 'error');
            }
        });

        // Load memos
        async function loadMemos() {
            try {
                const response = await fetch(`/api/memos?offset=${offset}&limit=${limit}`);
                const data = await response.json();
                displayMemos(data.data);
                currentPageMap = data.data.reduce((acc, item) => {
                    acc[item.uid] = item;
                    return acc;
                }, {})
                total = data.total;
                updatePagination();
                document.getElementById('memo-count').textContent = `${total} memos`;
            } catch (error) {
                showNotification('加载列表错误', 'error');
            }
        }

        function displayMemos(memos) {
            const container = document.getElementById('memo-items');
            container.innerHTML = memos.map(memo => `
        <div class="memo-item" data-id="${memo.uid}" onclick="selectMemo('${memo.uid}')">
            <div class="memo-item-header">
                <span class="memo-uid">${memo.uid.slice(0, 8)}...</span>
                <span>${new Date(memo.createTime).toLocaleString()}</span>
            </div>
            <div class="memo-item-content">
                ${escapeHtml(memo.content)}
            </div>
        </div>
    `).join('');
        }

        async function selectMemo(uid) {
            try {
                const memo = currentPageMap[uid];
                currentMemo = memo;
                displayMemoDetail(memo);

                // Update selected state
                document.querySelectorAll('.memo-item').forEach(item => {
                    item.classList.remove('active');
                });
                document.querySelector(`.memo-item[data-id="${uid}"]`)?.classList.add('active');
            } catch (error) {
                showNotification('加载 Memo 错误', 'error');
            }
        }

        function displayMemoDetail(memo) {
            document.getElementById('memo-info').innerHTML = memo.uid;
            document.getElementById('memo-content').value = memo.content;
            updatePreview();
        }

        function updatePreview() {
            const content = document.getElementById('memo-content').value;
            document.getElementById('memo-preview').innerHTML = marked(content);
        }

        document.getElementById('memo-content').addEventListener('input', updatePreview);

        async function saveMemo() {
            const content = document.getElementById('memo-content').value;
            if (!content.trim()) {
                showNotification('Memo 内容不得为空', 'error');
                return;
            }

            try {
                showLoading(true);

                if (currentMemo) {
                    // Update existing memo
                    await fetch(`/api/memos/${currentMemo.uid}`, {
                        method: 'PUT',
                        headers: {
                            'Authorization': password,
                            'Content-Type': 'application/json'
                        },
                        body: JSON.stringify({ content })
                    });
                } else {
                    // Create new memo
                    await fetch('/api/memos', {
                        method: 'POST',
                        headers: {
                            'Authorization': password,
                            'Content-Type': 'application/json'
                        },
                        body: JSON.stringify({ content })
                    });
                }

                showNotification('保存 Memo 成功');
                loadMemos();
            } catch (error) {
                showNotification('保存 Memo 失败', 'error');
            } finally {
                showLoading(false);
            }
        }

        async function deleteMemo() {
            if (!currentMemo) return;

            if (confirm('确定要删除这条 Memo 吗？')) {
                try {
                    showLoading(true);
                    await fetch(`/api/memos/${currentMemo.uid}`, {
                        method: 'DELETE',
                        headers: {
                            'Authorization': password
                        }
                    });
                    showNotification('删除 Memo 成功');
                    loadMemos();
                    clearMemoDetail();
                } catch (error) {
                    showNotification('删除 Memo 失败', 'error');
                } finally {
                    showLoading(false);
                }
            }
        }

        function createMemo() {
            currentMemo = null;
            clearMemoDetail();
        }

        function clearMemoDetail() {
            document.getElementById('memo-info').innerHTML = '新 Memo';
            document.getElementById('memo-content').value = '';
            document.getElementById('memo-preview').innerHTML = '';
        }

        function prevPage() {
            if (offset - limit >= 0) {
                offset -= limit;
                loadMemos();
            }
        }

        function nextPage() {
            if (offset + limit < total) {
                offset += limit;
                loadMemos();
            }
        }

        function updatePagination() {
            const currentPage = Math.floor(offset / limit) + 1;
            const totalPages = Math.ceil(total / limit);
            document.getElementById('page-info').textContent =
                `Page ${currentPage} of ${totalPages}`;
        }

        function showLoading(show) {
            const saveBtn = document.getElementById('save-btn');
            if (show) {
                saveBtn.innerHTML = '<div class="loading"></div> 保存中...';
                saveBtn.disabled = true;
            } else {
                saveBtn.innerHTML = '<i class="fas fa-save"></i> 保存';
                saveBtn.disabled = false;
            }
        }

        function showNotification(message, type = 'success') {
            const notification = document.createElement('div');
            notification.className = `notification ${type}`;
            notification.textContent = message;
            notification.style.position = 'fixed';
            notification.style.top = '20px';
            notification.style.right = '20px';
            notification.style.padding = '1rem';
            notification.style.borderRadius = '5px';
            notification.style.backgroundColor = type === 'success' ? '#2ecc71' : '#e74c3c';
            notification.style.color = 'white';
            notification.style.zIndex = '1000';
            document.body.appendChild(notification);
            setTimeout(() => notification.remove(), 3000);
        }

        // 用于防止 XSS 攻击的辅助函数
        function escapeHtml(html) {
            const div = document.createElement('div');
            div.textContent = html;
            return div.innerHTML;
        }

        // 初始化 marked 配置
        marked.setOptions({
            breaks: true,
            gfm: true,
            headerIds: false
        });
    </script>
</body>

</html>

从 JS 代码中即可看出，后端包含如下两个端点

POST /api/auth：页面鉴权
GET /api/memos：获取说说详情，支持分页
POST /api/memos: 发布新说说
PUT /api/memos/{uid}: 更新说说
DELETE /api/memos/{uid}：删除说说

随后编辑 worker.js 实现这些端点即可

import html from './index.html';

const CORRECT_PASSWORD = 'CORRECT_PASSWORD';        // 设置你的密码    // [!code highlight]
const CALLBACK_URL = 'https://CALLBACK_URL';        // 设置回调 URL   // [!code highlight]
const ALLOWED_ORIGINS = ['https://example.com'];    // 允许请求的域名  // [!code highlight]

// 生成随机 UID
function generateUID() {
  const chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
  let result = '';
  for (let i = 0; i < 22; i++) {
    const randomIndex = Math.floor(Math.random() * chars.length);
    result += chars[randomIndex];
  }
  return result;
}
// CORS 处理
function handleCORS(request) {
  const origin = request.headers.get('Origin');
  const allowedOrigin = ALLOWED_ORIGINS.includes(origin) ? origin : ALLOWED_ORIGINS[0];

  const corsHeaders = {
    'Access-Control-Allow-Origin': allowedOrigin,
    'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
    'Access-Control-Allow-Headers': 'Content-Type, Authorization',

import html from './index.html';

const CORRECT_PASSWORD = 'CORRECT_PASSWORD';        // 设置你的密码    // [!code highlight]
const CALLBACK_URL = 'https://CALLBACK_URL';        // 设置回调 URL   // [!code highlight]
const ALLOWED_ORIGINS = ['https://example.com'];    // 允许请求的域名  // [!code highlight]

// 生成随机 UID
function generateUID() {
  const chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
  let result = '';
  for (let i = 0; i < 22; i++) {
    const randomIndex = Math.floor(Math.random() * chars.length);
    result += chars[randomIndex];
  }
  return result;
}
// CORS 处理
function handleCORS(request) {
  const origin = request.headers.get('Origin');
  const allowedOrigin = ALLOWED_ORIGINS.includes(origin) ? origin : ALLOWED_ORIGINS[0];

  const corsHeaders = {
    'Access-Control-Allow-Origin': allowedOrigin,
    'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
    'Access-Control-Allow-Headers': 'Content-Type, Authorization',
    'Access-Control-Max-Age': '86400',
  };
  return corsHeaders;
}
function getCurrentTimeInISOFormat() {
  const now = new Date();
  // 获取各个部分
  const year = now.getUTCFullYear();
  const month = String(now.getUTCMonth() + 1).padStart(2, '0'); // 月份从零开始
  const day = String(now.getUTCDate()).padStart(2, '0');
  const hours = String(now.getUTCHours()).padStart(2, '0');
  const minutes = String(now.getUTCMinutes()).padStart(2, '0');
  const seconds = String(now.getUTCSeconds()).padStart(2, '0');
  // 组装成 ISO 8601 格式字符串
  return `${year}-${month}-${day}T${hours}:${minutes}:${seconds}Z`;
}
async function handleRequest(request, env) {
  const url = new URL(request.url);
  function validateAuth(request) {
    const auth = request.headers.get('Authorization');
    return auth === CORRECT_PASSWORD;
  }
  async function shouldNotify(uid) {
    const indexStr = await env.KV.get('index');
    if (!indexStr) return false;
    const index = JSON.parse(indexStr);
    return index.indexOf(uid) < 10;
  }
  async function executeCallback() {
    try {
      await fetch(CALLBACK_URL);
    } catch (error) {
      console.error('Callback failed:', error);
    }
  }
  const corsHeaders = handleCORS(request);
  
  // 处理 CORS 预检请求
  if (request.method === 'OPTIONS') {
    return new Response(null, {
      headers: handleCORS(request),
    });
  }
  // 管理页面
  if (url.pathname === '/manage') {
    return new Response(html, {
      headers: { 'Content-Type': 'text/html' },
    });
  }
  // 验证密码
  if (url.pathname === '/api/auth' && request.method === 'POST') {
    const { password } = await request.json();
    return new Response(
      JSON.stringify({ success: password === CORRECT_PASSWORD }),
      {
        headers: {
          'Content-Type': 'application/json',
          ...corsHeaders
        },
      }
    );
  }
  // API 路由处理
  if (url.pathname.startsWith('/api/memos')) {
    // 获取说说列表
    if (request.method === 'GET') {
      const offset = parseInt(url.searchParams.get('offset')) || 0;
      const limit = parseInt(url.searchParams.get('limit')) || 10;
      const indexStr = await env.KV.get('index');
      const index = indexStr ? JSON.parse(indexStr) : [];
      const pageUids = index.slice(offset, offset + limit);
      const posts = await Promise.all(
        pageUids.map(uid => env.KV.get(uid).then(JSON.parse))
      );
      return new Response(JSON.stringify({
        offset,
        limit,
        data: posts,
        total: index.length,
        hasMore: (offset + limit) < index.length,
      }), {
        headers: {
          'Content-Type': 'application/json',
          ...corsHeaders
        },
      });
    }
    // 需要验证的操作
    if (!validateAuth(request)) {
      return new Response('Unauthorized', {
        status: 401,
        headers: corsHeaders
      });
    }
    // 发布新说说
    if (request.method === 'POST') {
      const { content } = await request.json();
      if (!content || !content.trim()) {
        return new Response('Content cannot be empty', {
          status: 400,
          headers: corsHeaders
        });
      }
      const indexStr = await env.KV.get('index');
      const index = indexStr ? JSON.parse(indexStr) : [];
      let uid = generateUID();
      while (true) {
        if (!index.includes(uid)) {
          break;
        }
        uid = generateUID();
      }
      const post = {
        uid,
        createTime: getCurrentTimeInISOFormat(),
        content: content.trim()
      };
      index.unshift(uid);
      await Promise.all([
        env.KV.put('index', JSON.stringify(index)),
        env.KV.put(uid, JSON.stringify(post))
      ]);
      await executeCallback();
      return new Response(JSON.stringify(post), {
        headers: {
          'Content-Type': 'application/json',
          ...corsHeaders
        },
      });
    }
    // 编辑说说
    if (request.method === 'PUT') {
      const uid = url.pathname.split('/').pop();
      const { content } = await request.json();
      if (!content || !content.trim()) {
        return new Response('Content cannot be empty', {
          status: 400,
          headers: corsHeaders
        });
      }
      const postStr = await env.KV.get(uid);
      if (!postStr) {
        return new Response('Post not found', {
          status: 404,
          headers: corsHeaders
        });
      }
      const post = JSON.parse(postStr);
      post.content = content.trim();
      await env.KV.put(uid, JSON.stringify(post));
      // 检查是否需要回调
      if (await shouldNotify(uid)) {
        await executeCallback();
      }
      return new Response(JSON.stringify(post), {
        headers: {
          'Content-Type': 'application/json',
          ...corsHeaders
        },
      });
    }
    // 删除说说
    if (request.method === 'DELETE') {
      const uid = url.pathname.split('/').pop();
      const indexStr = await env.KV.get('index');
      if (!indexStr) {
        return new Response('Post not found', {
          status: 404,
          headers: corsHeaders
        });
      }
      const needCallback = await shouldNotify(uid);
      const index = JSON.parse(indexStr);
      const newIndex = index.filter(id => id !== uid);
      await Promise.all([
        env.KV.put('index', JSON.stringify(newIndex)),
        env.KV.delete(uid)
      ]);
      if (needCallback) {
        await executeCallback();
      }
      return new Response(JSON.stringify({ success: true }), {
        headers: {
          'Content-Type': 'application/json',
          ...corsHeaders
        },
      });
    }
  }
  return new Response('Not Found', {
    status: 404,
    headers: corsHeaders
  });
}
export default {
  async fetch(request, env) {
    try {
      return handleRequest(request, env);
    } catch (error) {
      return new Response(`Internal Server Error: ${error.message}`, {
        status: 500,
        headers: handleCORS(request)
      });
    }
  },
};

最顶上三个常量需要配置：

CORRECT_PASSWORD，页面密码
CALLBACK_URL，发布新说说或更新/删除说说后触发的回调地址
ALLOWED_ORIGINS，跨域处理，允许访问的域名列表，至少两个：你的博客域名和管理页面域名

配置完成后点击发布

由于墙的原因，默认的 workers.dev 域名很难访问，最好为 worker 配置一个新的域名。在 memos 详情页面 - 设置 - 域和路由，添加一个自定义域，填入一个在 Cloudflare 上托管的域名即可。注意这个域名也要添加到 worker.js 的 ALLOWED_ORIGINS 中

完成后就可以使用这个管理页面了，管理页面的 URL 为 https://{你的域名}/manage，进入页面需要输入密码，then enjoy！

前端

Thanks to VitePress，我们可以很方便地通过 Vue 组件的方式，编写说说前端并嵌入博客

首先安装 markedjs 依赖，pnpm 可使用如下命令：

pnpm add marked

在你的博客的主题配置文件（通常为 docs/.vitepress/theme/index.ts，文件路径和拓展名也许会有区别）的同级目录下，新建一个 components 文件夹（已有则无需新建），在其中新建 memos.vue

<template>
    <div class="memos-container">
        <div v-for="memo of memoList" :key="memo.uid">
            <div class="card">
                <div class="header">
                    <span class="time-text">{{ memo.createTime }}</span>
                </div>

                <div class="memo-content" v-html="memo.content" />
            </div>
        </div>
        <div v-if="hasMore" class="load-more">
            <button @click="loadMoreMemos" :disabled="isLoading" class="load-more-button">
                <span v-if="!isLoading">加载更多</span>
                <span v-else class="loading-spinner"></span>
            </button>
        </div>
    </div>
</template>

<script setup lang="ts">
import { marked, Tokens } from "marked"
import { reactive, toRefs, onMounted } from "vue"
import memosRaw from '../../../../memos.json'       // [!code highlight]

<template>
    <div class="memos-container">
        <div v-for="memo of memoList" :key="memo.uid">
            <div class="card">
                <div class="header">
                    <span class="time-text">{{ memo.createTime }}</span>
                </div>

                <div class="memo-content" v-html="memo.content" />
            </div>
        </div>
        <div v-if="hasMore" class="load-more">
            <button @click="loadMoreMemos" :disabled="isLoading" class="load-more-button">
                <span v-if="!isLoading">加载更多</span>
                <span v-else class="loading-spinner"></span>
            </button>
        </div>
    </div>
</template>

<script setup lang="ts">
import { marked, Tokens } from "marked"
import { reactive, toRefs, onMounted } from "vue"
import memosRaw from '../../../../memos.json'       // [!code highlight]

interface memosRes {
    data: memo[]
    hasMore: boolean
}

interface image {
    name: string
    filename: string
    url: string
}

interface memo {
    uid: string
    createTime: string
    content: string
}

function convertToLocalTime(dateString: string, timeZone: string = 'Asia/Shanghai'): string {
    // 创建 Date 对象
    const date = new Date(dateString);

    // 提取所需的时间组件
    const options: Intl.DateTimeFormatOptions = {
        timeZone: timeZone,
        year: 'numeric',
        month: '2-digit',
        day: '2-digit',
        hour: '2-digit',
        minute: '2-digit',
        second: '2-digit',
        hour12: false // 使用 24 小时制
    };

    const formatter = new Intl.DateTimeFormat('zh-CN', options);
    const parts = formatter.formatToParts(date);

    // 构建最终输出格式
    const year = parts.find(part => part.type === 'year')?.value;
    const month = parts.find(part => part.type === 'month')?.value;
    const day = parts.find(part => part.type === 'day')?.value;
    const hour = parts.find(part => part.type === 'hour')?.value;
    const minute = parts.find(part => part.type === 'minute')?.value;
    const second = parts.find(part => part.type === 'second')?.value;

    // 拼接成目标格式
    return `${year}-${month}-${day} ${hour}:${minute}:${second}`;
}

const PAGE_SIZE = 10;
const data = reactive({
    memoList: [] as memo[],
    offset: 10, // 从文件加载了 10 条，所以初始 offset 为 10
    hasMore: true,
    isLoading: false
})
const { memoList, hasMore, isLoading } = toRefs(data);

const renderer = new marked.Renderer();
renderer.image = function({href, title, text}: Tokens.Image):string {
  return `
    <div class="img-container">
        <img class="imgwrp" loading="lazy" src="${href}" />
    </div>
  `
};
marked.use({
    renderer: renderer,
    breaks: true,
    gfm: true,
})

function processMemos(memos: memo[]) {
  return memos.map(memo => ({
    ...memo,
    content: marked.parse(memo.content) as string,
    createTime: convertToLocalTime(memo.createTime)
  }));
}

// 初始化数据
onMounted(() => {
  const initialMemos = memosRaw.data as memo[];
  data.memoList = processMemos(initialMemos);
});

async function loadMoreMemos() {
  if (!data.hasMore || data.isLoading) return;
  
  data.isLoading = true;
  try {
    const url = `https://{你的域名}/api/memos?limit=${PAGE_SIZE}&offset=${data.offset}`;   // [!code highlight]
    const response = await fetch(url);
    const result: memosRes = await response.json();
    
    const processedMemos = processMemos(result.data);
    data.memoList.push(...processedMemos);
    data.offset += result.data.length;
    data.hasMore = result.hasMore;
  } catch (error) {
    console.error('Failed to load memos:', error);
  } finally {
    data.isLoading = false;
  }
}
</script>

<style lang="scss">
.card {
    border-style: solid;
    margin-bottom: .5rem;
    border-width: 1px; 
    position: relative;
    border-radius: .5rem;
    border-color: var(--vp-c-bg);
    padding-top: .75rem;
    padding-bottom: .75rem;
    padding-left: 1rem;
    padding-right: 1rem;
    background-color: var(--memo-bg);
    font-family: ui-sans-serif, system-ui, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", Segoe UI Symbol, "Noto Color Emoji";

    .header {
        display: flex;
        justify-content: space-between;
        align-items: center;

        .time-text {
            display: inline-block;
            font-size: .875rem;
            text-decoration: none;
            color: var(--memo-time)
        }
    }

    .memo-content {
        margin-top: 5px;
        font-size: 1rem;
        word-break: break-word;
        color: var(--memo-content);

        * {
            margin: 0;
        }

        *:not(:first-child):not([hidden]) {
            margin-top: .5rem;
        }

        .img-container {
            width: 40%;

            .imgwrp {
                width:100%;
                height: 100%;
            }
        }
    
    }
    
}

.card:hover {
    border-color: var(--memo-card-border);
}

.load-more {
  text-align: center;
  margin-top: 40px;
  margin-bottom: 40px;

  .load-more-button {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    width: 120px; // 固定宽度
    height: 40px; // 固定高度
    background-color: transparent;
    color: var(--vp-c-text-2);
    border: 1px solid var(--vp-c-divider);
    border-radius: 4px;
    font-size: 14px;
    font-weight: 500;
    cursor: pointer;
    transition: all 0.2s ease;
    outline: none;

    &:hover:not(:disabled) {
      background-color: var(--vp-c-bg-soft);
      color: var(--vp-c-text-1);
      border-color: var(--vp-c-text-2);
    }

    &:active:not(:disabled) {
      transform: translateY(1px);
    }

    &:disabled {
      opacity: 0.5;
      cursor: not-allowed;
    }

    .loading-spinner {
      width: 14px;
      height: 14px;
      border: 2px solid var(--vp-c-text-3);
      border-radius: 50%;
      border-top-color: var(--vp-c-text-1);
      animation: spin 0.8s linear infinite;
    }
  }
}

@keyframes spin {
  to { transform: rotate(360deg); }
}
</style>

注意将 {你的域名} 替换为 CloudFlare Worker 的域名

眼尖的同学可能注意到了，这个组件初始化加载的内容不是通过请求 Worker 接口获取到的，而是从一个 json 文件获取的（import memosRaw from '../../../../memos.json'）。只有点击加载更多，才会通过 Worker 接口获取更多内容。这是为什么呢？

从体验上来说，进入说说页面时，如果初始数据从接口获取，那么这时页面在获取到数据之前会空白一会儿，体验不佳
从省钱的角度上来说，CloudFlare Worker 免费版是限制请求次数的，初始化数据静态获取可以极大地降低请求次数

这个 memos.json，则是在项目编译时，从接口获取到的前十条说说。这也就是为什么，Worker 代码中会添加一个 CALLBACK_URL，这个 URL 是在你发布新说说，或者删改前十条说说时重新触发编译使用的，具体 URL 可以根据你的部署平台自行搜索。如果完全动态获取说说内容的话，这里可以不用设置这么一个回调

下面的代码用于在编译时生成 memos.json，在主题配置文件（通常为 docs/.vitepress/theme/index.ts，文件路径和拓展名也许会有区别）的同级目录下，新建一个 utils 文件夹（已有则无需新建），在其中新建 memos.js

import https from 'https';
import { promises as fs } from 'fs';

const url = 'https://{你的域名}/api/memos?limit=10';// [!code highlight]

const requestOptions = {
    headers: {
      'Accept-Encoding': '',
    }
};

// 发出 GET 请求
https.get(url, requestOptions, (resp) => {
  let data = [];

  // 逐步接收数据
  resp.on('data', (chunk) => {
    data.push(chunk);
  });

  // 完成接收数据
  resp.on('end', async () => {
    try {
      // 将 Buffer 数组合并为一个 Buffer
      const buffer = Buffer.concat(data);

import https from 'https';
import { promises as fs } from 'fs';

const url = 'https://{你的域名}/api/memos?limit=10';// [!code highlight]

const requestOptions = {
    headers: {
      'Accept-Encoding': '',
    }
};

// 发出 GET 请求
https.get(url, requestOptions, (resp) => {
  let data = [];

  // 逐步接收数据
  resp.on('data', (chunk) => {
    data.push(chunk);
  });

  // 完成接收数据
  resp.on('end', async () => {
    try {
      // 将 Buffer 数组合并为一个 Buffer
      const buffer = Buffer.concat(data);
      const decodedData = buffer.toString('utf-8'); // 假设返回的数据是 UTF-8 编码

      // 保存 JSON 数据到文件
      await fs.writeFile('memos.json', decodedData);
      console.log('JSON 数据已保存到 data.json');
    } catch (e) {
      console.error('解析 JSON 时出错:', e);
    }
  });

}).on('error', (err) => {
  console.error('获取数据时出错:', err);
});

接着编辑博客根目录下的 package.json，在 dev 和 build 的命令前都添加 node docs/.vitepress/theme/utils/memos.js。这里的添加位置可能因人而异，以我为例：

{
  ...
  "scripts": {
    "dev": "node docs/.vitepress/theme/utils/memos.js && vitepress dev docs",
    "build": "node docs/.vitepress/theme/utils/memos.js && vitepress build docs",
    "serve": "vitepress serve docs"
  },
  ...
}

这样在 dev 阶段和 build 阶段都会首先调用 memos.js，在博客根目录下生成 memos.json。注意根据目录层级调整 memos.vue 中 import 的路径

这样组件和数据都准备好了，下面这个组件注册为全局组件

在主题配置文件（通常为 docs/.vitepress/theme/index.ts，文件路径和拓展名也许会有区别）中引入这个组件，并注册

...
import Memos from './components/memos.vue'
...
export default {
    ...
    enhanceApp({ app }) {
        ...
        app.component('Memos', Memos);// [!code highlight]
    }
} satisfies Theme

这样在博客的任何地方，都可以通过 <Memos /> 直接引入这个组件了

最后就是创建一个单页，专门用于放置这个组件

什么？你说你从来没有在 vitepress 中使用过单页？

这样，你先在根目录下新建一个 pages 文件夹，再在 VitePress 核心配置文件中（注意不是主题配置文件，通常为 docs/.vitepress/config.ts，文件路径和拓展名也许会有区别）中新增一个 rewrites 规则 'pages/:file.md': ':file.md'，这样 pages 下的内容都可以直接通过 /文件名 访问了。关于 rewrites，见官方文档

pages 文件夹下新建 balabala.md，内容为

---
title: 碎碎念
hidden: true
comment: false
sidebar: false
aside: false
readingTime: false
showMeta: false
---

<Memos />

完事收工

实现 OPNsense 透明代理+分流

Thu, 16 Jan 2025 15:09:00 GMT

前言

早先透明代理 + 分流一直使用的是 ikuai 作为主路由，OpenWRT 作为旁路由的方案，这也是网上大部分教程的主流方案。后面冲浪的时候了解到 ikuai 可能会有偷跑流量与上报信息的情况出现，另外作为国产闭源系统，安全性也比较成问题

后续更换了主路由 OpenWRT，旁路由 Debian 的方案，后面又不使用旁路由方案，先后尝试了基于 FakeIP 的分流转发方案和基于 BGP 的分流转发方案，最终稳定在了基于 BGP 的分流转发方案上

最近又了解到了 OPNsense 这个防火墙/路由系统。简直是梦中情路由系统，开源免费，UI 美观，功能完善，同时还提供了 gui 界面支持自动更新 ip list 以用于分流。所以计划将现有的分流转发方案迁移到该系统上，同时不在单独使用一个软路由用于科学，而是直接将 clash 集成进主路由中

网上冲浪了下，相关的教程并不多，有部分教程也由于年久失修，不再有效。踩了一些坑后，决定整理一下详细的方案

梳理了下需要实现的功能：

DNS 转发到 clash 统一解析
请求流量进入 OPNsense 后，可以根据某个 list 进行分流，将部分流量导入 clash

OPNsense 的基础安装过程就不再赘述，网络上相关的内容很多

clash 安装

二进制下载和配置文件

DNS 解析和流量处理都依赖了 clash 的功能，所以第一步先安装 clash

ssh 进 OPNsense（怎么开启 ssh？STFW）后，新建文件夹 /usr/local/clash 作为 clash 二进制、配置文件和其他相关文件的存放点。clash 二进制建议 scp 过去（毕竟主路由现在还没科学，直接下载速度很慢）。这里需要先把 clash 二进制和配置文件上传到该目录下。clash 二进制重命名为 clash，配置文件命名为 config.yaml

在 mihomo 的 releases 页面下载最新的内核版本。注意下载 freebsd 版本，根据你的机器架构选择 386、amd64 或者 arm64。如果你是 amd64 且后续运行 clash 时阶段出现以下报错，请下载 amd64-compatible 版

This PROGRAM can only be run on _AMD64 processors with v3 microarchitecture_ support.

配置文件就不多说了，直接用一份你一直在用的就可以。但注意改动下面的配置

mixed-port: 7890

dns:
  listen: 127.0.0.1:5353

tun:
  enable: false

dns 监听 5353 端口，作为 OPNsense 自带的 DNS 上游。同时关闭 tun，不主动劫持流量，而是由 OPNsense 进行流量筛选后导入。这里 mixed-port 同时兼具 socks-port、http-port 和 https-port 的功能

运行 pw user add clash -c "Clash" -s /usr/sbin/nologin 创建一个无登录的 clash 用户，并通过 chown clash:clash /usr/local/clash 赋予文件夹权限。完成后可以通过 /usr/local/clash/clash -d /usr/local/clash 执行一次，观察下是否可以成功运行

注册 clash 服务

新建文件 /usr/local/etc/rc.d/clash 和 /usr/local/opnsense/service/conf/actions.d/actions_clash.conf 将 clash 注册成一个系统服务

#!/bin/sh
# $FreeBSD$

# PROVIDE: clash
# REQUIRE: LOGIN cleanvar
# KEYWORD: shutdown

# Add the following lines to /etc/rc.conf to enable clash:
# clash_enable (bool): Set to "NO" by default.
# Set to "YES" to enable clash.
# clash_config (path): Clash config dir.
# Defaults to "/usr/local/etc/clash"

. /etc/rc.subr

name="clash"
rcvar=clash_enable

load_rc_config $name

: ${clash_enable:="NO"}
: ${clash_config="/usr/local/clash"}

command="/usr/local/clash/clash"
#pidfile="/var/run/clash.pid"

#!/bin/sh
# $FreeBSD$

# PROVIDE: clash
# REQUIRE: LOGIN cleanvar
# KEYWORD: shutdown

# Add the following lines to /etc/rc.conf to enable clash:
# clash_enable (bool): Set to "NO" by default.
# Set to "YES" to enable clash.
# clash_config (path): Clash config dir.
# Defaults to "/usr/local/etc/clash"

. /etc/rc.subr

name="clash"
rcvar=clash_enable

load_rc_config $name

: ${clash_enable:="NO"}
: ${clash_config="/usr/local/clash"}

command="/usr/local/clash/clash"
#pidfile="/var/run/clash.pid"
required_files="${clash_config}"
clash_group="clash"
clash_user="clash"

command_args="-d $clash_config"

run_rc_command "$1"

[start]
command:/usr/local/etc/rc.d/clash onestart
type:script
message:starting clash

[stop]
command:/usr/local/etc/rc.d/clash stop
type:script
message:stoping clash

[status]
command:/usr/local/etc/rc.d/clash statusexit 0
type:script_output
message:get clash status

[restart]
command:/usr/local/etc/rc.d/clash onerestart
type:script
message:restarting clash

赋予运行权限 chmod +x /usr/local/etc/rc.d/clash 后启用 service configd restart

clash 开机自启

接下来设置 clash 开机自启就可以了，但这里有个坑：

clash 作为系统服务启动后，并没有完成启动后就保持后台运行的功能，这样每次系统重启后会启动到 clash 之后就不会往后走，因该 clash 一直会保持在前台，导致排在 clash 后面的待启动服务就没法启动了

有一个曲折的办法就是通过 OPNsense 自带的一个服务监控功能 Monit 来拉起和监控 clash 的状态。Monit 功能可在 服务-Monit 中开启

在 Service Test Settings 中添加两个 Service Test，第一个负责拉起 clash

| Setting | Value | | --------- | ---------------------------------------- | | Name | Clash | | Condition | failed host 127.0.0.1 port 7890 type tcp | | Action | Restart |

第二个避免重启死循环

| Setting | Value | | --------- | -------------------------- | | Name | RestartLimit4 | | Condition | 5 restarts within 5 cycles | | Action | Unmonitor |

最后在 Service Settings 里添加

| Setting | Value | | ------- | ------------------------------------- | | Name | Clash | | Match | clash | | Start | /usr/local/sbin/configctl clash start | | Stop | /usr/local/sbin/configctl clash stop | | Tests | Clash,RestartLimit4 |

保存后等待一段时间，在 Monit - Status 里查看 clash 是否正常运行

DNS 解析

使用 OPNsense 自带的 Unbound DNS 设置上游 DNS 为 clash 的 127.0.0.1

，一直解析出错，非常奇怪

百思不得其解，最终决定关闭 Unbound DNS，用回了 AdGuard Home 作为默认 DNS，劫持 53 端口

AdGuard Home 没有被包含在 OPNsense 的默认插件源中，需要手动添加社区源

ssh 进 OPNsense 后执行命令

$ fetch -o /usr/local/etc/pkg/repos/mimugmail.conf https://www.routerperformance.net/mimugmail.conf
$ pkg update

接着在 web-gui 中的系统 - 固件 - 插件中搜索 adguard，安装 os-adguardhome-maxit 即可。安装完成后即可在服务-Adguardhome 中开启 Adguard Home。web 管理开放在 3000 端口，初始化设置过程不表，注意 DNS 监听端口设置为 53，即以 Adguard Home 作为 OPNsense 所在机器的默认 DNS server

安装完成后在 Adguard Home 的设置-DNS 设置中将上游 DNS 服务器设置为 127.0.0.1

，即 Clash 的 DNS 监听地址即可

国内外 IP 分流

二进制下载和配置文件

OPNsense 默认是内置了一个 Squid 代理程序用于提供流量代理，但是该程序只能用于代理 http/https 流量，无法代理常规的 tcp 和 udp 流量，作为一个代理是很不完美的。于是采用了曲线救国的方案，通过 tun2socks 项目将 tcp/udp 流量导入 clash 完成代理

新建文件夹 /usr/local/tun2socks 作为 tun2socks 的二进制和配置文件的安放处。在 Github Releases 中下载最新的 freebsd 二进制到文件夹下，并将其重命名为 tun2socks。新建配置文件 /usr/local/tun2socks/config.yaml

# debug / info / warning / error / silent
loglevel: info

# URL format: [protocol://]host[:port]
proxy: socks5://127.0.0.1:7890

# URL format: [driver://]name
# TUN 设备名称，避免使用 tun0
device: tun://proxytun2socks0

# Maximum transmission unit for each packet
mtu: 1500

# Timeout for each UDP session, default value: 60 seconds
udp-timeout: 120s

proxy 处填写到 clash 的 socks5 端口的地址

可在文件夹 /usr/local/tun2socks/ 内运行 ./tun2socks -config ./config.yaml，测试配置文件是否正确

注册服务

新建文件 /usr/local/etc/rc.d/tun2socks 和 /usr/local/opnsense/service/conf/actions.d/actions_tun2socks.conf

#!/bin/sh

# PROVIDE: tun2socks
# REQUIRE: LOGIN
# KEYWORD: shutdown

. /etc/rc.subr

name="tun2socks"
rcvar="tun2socks_enable"

load_rc_config $name

: ${tun2socks_enable:=no}
: ${tun2socks_config:="/usr/local/tun2socks/config.yaml"}

pidfile="/var/run/${name}.pid"
command="/usr/local/tun2socks/tun2socks"
command_args="-config ${tun2socks_config} > /dev/null 2>&1 & echo \$! > ${pidfile}"

start_cmd="${name}_start"

tun2socks_start()
{
    if [ ! -f ${tun2socks_config} ]; then

#!/bin/sh

# PROVIDE: tun2socks
# REQUIRE: LOGIN
# KEYWORD: shutdown

. /etc/rc.subr

name="tun2socks"
rcvar="tun2socks_enable"

load_rc_config $name

: ${tun2socks_enable:=no}
: ${tun2socks_config:="/usr/local/tun2socks/config.yaml"}

pidfile="/var/run/${name}.pid"
command="/usr/local/tun2socks/tun2socks"
command_args="-config ${tun2socks_config} > /dev/null 2>&1 & echo \$! > ${pidfile}"

start_cmd="${name}_start"

tun2socks_start()
{
    if [ ! -f ${tun2socks_config} ]; then
        echo "${tun2socks_config} not found."
        exit 1
    fi
    echo "Starting ${name}."
    /bin/sh -c "${command} ${command_args}"
}

run_rc_command "$1"

[start]
command:/usr/local/etc/rc.d/tun2socks start
parameters:
type:script
message:starting tun2socks

[stop]
command:/usr/local/etc/rc.d/tun2socks stop
parameters:
type:script
message:stopping tun2socks

[restart]
command:/usr/local/etc/rc.d/tun2socks restart
parameters:
type:script
message:restarting tun2socks

[status]
command:/usr/local/etc/rc.d/tun2socks status; exit 0
parameters:
type:script_output
message:request tun2socks status

创建 /etc/rc.conf 并添加以下内容：

tun2socks_enable="YES"

给予运行权限 chmod +x /usr/local/etc/rc.d/tun2socks 后启用 service configd restart

并手动启动 tun2socks

/usr/local/etc/rc.d/tun2socks start

开机启动

创建文件 /usr/local/etc/rc.syshook.d/early/60-tun2socks

#!/bin/sh

# Start tun2socks service
/usr/local/etc/rc.d/tun2socks start

给予文件可执行权限 chmod +x /usr/local/etc/rc.syshook.d/early/60-tun2socks 即可

新建端口、配置网关

在 OPNsense 的接口 - 分配中，添加一个新接口，设备即为我们在配置文件中写的 proxytun2socks0，保存即可

随后在添加的接口的配置页面启用接口，描述填写 TUN2SOCKS，IPv4 配置类型选择静态 IPv4，IPv4 地址为 10.0.3.1/24，保存

在系统 - 网关 - 配置中，新建一个网关，名称为 TUN2SOCKS_MIHOMO，接口选择我们刚添加的接口 TUN2SOCKS，IP 地址填写 10.0.3.2，其他默认保存

这样我们就新建了一个网关，只要流量进入这个网关，就会被转发到 127.0.0.1

，也就是 clash 进行代理

设置国内外 IP 分流

OPNsense 对于我来说最有用的功能，就是防火墙 - 别名。这里可以设置一个 ip list，并在后续的规则配置中直接使用这个 ip list。这个 list 不仅可以手动填写，还可以直接订阅一个地址，动态获取

进入防火墙 - 别名，这里需要新建两个别名

第一个是 InternalAddress，表示局域网地址范围，类型选择 Network(s)，内容为

0.0.0.0/8
127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
224.0.0.0/4
240.0.0.0/4

第二个是 CN_V4，表示国内的 IP 地址范围，类型选择 URL Table (IPs)，内容填写一个包含国内所有网段范围的列表地址即可，如 https://raw.githubusercontent.com/gaoyifan/china-operator-ip/refs/heads/ip-lists/china.txt

随后在防火墙 - 规则-LAN 中新建两个规则，排在规则列表的最前面，注意规则顺序从上到下

第一个规则目标为 InternalAddress，其余默认，表示目标地址为局域网时，按照默认规则路由

第二个规则目标为 CN_V4，并勾上目标/反转，网关选择上文新建的 TUN2SOCKS_MIHOMO，表示当目标地址为非中国 IP 时，将流量转发到 TUN2SOCKS_MIHOMO 网关

下面应该就是剩下的默认规则了，其他所有流量仍然按照默认规则路由，也就是国内 IP 直接走直连

当尝试访问 google 时，DNS 请求由 Adguard Home 获取转发到 clash，解析出 google 的真实地址。随后再向这个地址请求数据时，命中防火墙规则的第二条，转发到 TUN2SOCKS_MIHOMO 网关，通过 socks5 端口进入 clash 处理，最终实现出墙

更精确的基于 BGP 的国内外 IP 分流

Mon, 07 Oct 2024 08:51:00 GMT

此前折腾过两节的透明代理方案：debian 旁路由方案和基于 FakeIP 的透明代理分流，家里的透明代理基本已经可用了。基于 FakeIP 的方案使用 FakeIP 标记国外 IP，并在主路由识别并进行分流。sing-box 的 dns 模块配置为

{
  "dns": {
    "servers": [
      ...
    ],
    "rules": [
      ...
      {
        "server": "local",
        "rewrite_ttl": 10,
        "type": "logical",
        "mode": "and",
        "rules": [
          {
            "rule_set": [
              "geosite-geolocation-!cn" // [!code highlight]
            ],
            "invert": true
          },
          {
            "rule_set": [
              "geosite-cn", // [!code highlight]
              "geosite-category-companies@cn", // [!code highlight]
              "geoip-cn" // [!code highlight]
            ]

{
  "dns": {
    "servers": [
      ...
    ],
    "rules": [
      ...
      {
        "server": "local",
        "rewrite_ttl": 10,
        "type": "logical",
        "mode": "and",
        "rules": [
          {
            "rule_set": [
              "geosite-geolocation-!cn" // [!code highlight]
            ],
            "invert": true
          },
          {
            "rule_set": [
              "geosite-cn", // [!code highlight]
              "geosite-category-companies@cn", // [!code highlight]
              "geoip-cn" // [!code highlight]
            ]
          }
        ]
      },
      {
        "server": "dns-fakeip",
        "rewrite_ttl": 1,
        "query_type": [
          "A",
          "AAAA"
        ]
      }
    ],
    "strategy": "ipv4_only",
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15"
    }
  }
}

这个 dns 分流规则基于规则集：当域名不在 geosite-geolocation-!cn 中，且域名在 geosite-cn 或者 geosite-category-companies@cn，或域名解析出的 ip 在 geoip-cn 中时，认为是国内流量，返回 RealIP，否则返回 FakeIP

这种判断方式十分粗糙，且不说这几个域名规则集只能囊括一些常见域名，ip 规则集 geoip-cn 是基于 MaxMind 的 GeoLite2 数据库，来自于 WHOIS 数据库，大部分情况只代表这个 IP 被哪个机构注册使用，但无从知晓该 IP 被用在何处，尤其是 CN-IP，十分不准确

正好，最近了解到了 BGP。抄一点科普如下

边界网关协议（Border Gateway Protocol，BGP）是一种用来在路由选择域之间交换网络层可达性信息（Network Layer Reachability Information，NLRI）的路由选择协议。由于不同的管理机构分别控制着他们各自的路由选择域，因此，路由选择域经常被称为自治系统 AS（Autonomous System）。现在的 Internet 是一个由多个自治系统相互连接构成的大网络，BGP 作为事实上的 Internet 外部路由协议标准，被广泛应用于 ISP（Internet Service Provider）之间。

基于 BGP，所有路由到中国的流量都会由国内 AS 声明，那么只要收集到国内全部 AS 声明的 IP list，就是一份更加准确的 CN-IP 了

根据中国具体国情、维基百科，能够直接与国际互联网建立 BGP Session 只有三大运营商、教育网和科技网

网上有很多教程教你如何自己运营一个 AS，由此拉到一张完整的 BGP 表。但是作为懒狗（拿来主义），我找到 Github 上其实已经有一些基于 BGP 的 CN-IP list。本篇基于这个项目：https://github.com/gaoyifan/china-operator-ip/blob/ip-lists/china.txt

有了 list，下面就是 code time！

#!/bin/bash

# 定义变量
URL="https://raw.githubusercontent.com/gaoyifan/china-operator-ip/refs/heads/ip-lists/china.txt"
IPSET_NAME="allowed_ips"

# 下载新的 IP 列表
curl -o /tmp/ip-list.txt "$URL" || { echo "下载 IP 列表失败"; exit 1; }

# 清空现有的 ipset 集合
ipset flush $IPSET_NAME

# 重新创建 ipset 集合（如果不存在则创建）
ipset create $IPSET_NAME hash:net -exist

# 添加局域网地址到集合
ipset add $IPSET_NAME 0.0.0.0/8
ipset add $IPSET_NAME 127.0.0.0/8
ipset add $IPSET_NAME 10.0.0.0/8
ipset add $IPSET_NAME 172.16.0.0/12
ipset add $IPSET_NAME 192.168.0.0/16
ipset add $IPSET_NAME 169.254.0.0/16
ipset add $IPSET_NAME 224.0.0.0/4
ipset add $IPSET_NAME 240.0.0.0/4

#!/bin/bash

# 定义变量
URL="https://raw.githubusercontent.com/gaoyifan/china-operator-ip/refs/heads/ip-lists/china.txt"
IPSET_NAME="allowed_ips"

# 下载新的 IP 列表
curl -o /tmp/ip-list.txt "$URL" || { echo "下载 IP 列表失败"; exit 1; }

# 清空现有的 ipset 集合
ipset flush $IPSET_NAME

# 重新创建 ipset 集合（如果不存在则创建）
ipset create $IPSET_NAME hash:net -exist

# 添加局域网地址到集合
ipset add $IPSET_NAME 0.0.0.0/8
ipset add $IPSET_NAME 127.0.0.0/8
ipset add $IPSET_NAME 10.0.0.0/8
ipset add $IPSET_NAME 172.16.0.0/12
ipset add $IPSET_NAME 192.168.0.0/16
ipset add $IPSET_NAME 169.254.0.0/16
ipset add $IPSET_NAME 224.0.0.0/4
ipset add $IPSET_NAME 240.0.0.0/4

# 读取 IP 列表并添加到 ipset 集合
while IFS= read -r ip
do
    # 如果行为空或注释行，则跳过
    if [ -z "$ip" ] || [[ $ip == \#* ]]; then
        continue
    fi
    ipset add $IPSET_NAME $ip
done < /tmp/ip-list.txt

# 清理临时文件
rm /tmp/ip-list.txt

# 创建自定义链
iptables -t mangle -N NO_FORWARD

# 配置 iptables：将流量引导到自定义链，并基于逻辑规则返回或标记
iptables -t mangle -A PREROUTING -j NO_FORWARD

# 在自定义链中配置规则
iptables -t mangle -A NO_FORWARD -s 192.168.7.2 -j RETURN
iptables -t mangle -A NO_FORWARD -m set --match-set $IPSET_NAME dst -j RETURN
iptables -t mangle -A NO_FORWARD -j MARK --set-mark 1

# 设置路由以标记的流量转发到 192.168.7.2
ip rule add fwmark 1 table 100
ip route add default via 192.168.7.2 table 100

代码注释很完全，不做过多解释

如果你的路由系统是 OpenWRT，需要额外安装 bash、ipset、iptables 等，OpenWRT 的默认 shell 是 ash，无法运行此脚本

opkg update
opkg install bash
opkg install curl
opkg install ipset
opkg install iptables

这份 CN-IP 一天更新一次，可以设置一个定时任务一天执行一次这个脚本，并把这个脚本添加到启动项中

在字节工作三年的同时仍保持一定程度的心理健康其实也并非完全不可能

Sat, 28 Sep 2024 08:26:00 GMT

标题源

晚饭时间，同事聊起了他买的车，忽然感叹了一句：“感觉工作之后时间变得特别快”

我：“不好说，今天（周五）下午的时间就挺难熬”

虽然很不愿承认，总把自己当学生来看（暂时是组里年龄最小的），但是距我离开校园，满打满算也有三年多。这三年时间算得动荡，但也相对安稳

字节内有句老话：“字节一年，人间三年”，这“九年”时光，也尽在这里了

懵懂

如果不算上实习，我是在 21 年 6 月底入职了杭州字节

请看 VCR：入职一周小记

杭州字节租下了八方城的两栋楼，却不是整栋，两幢楼基本都只租了最顶上的五六层，风景倒是不错，每天趴在阳台上可以远眺远处的 EFC（余杭最像城里的地方）和更远处的余杭南部的山区，山雨欲来和雨过天晴时的风景算得一绝

我入职的是抖音直播部门下面的某个 ToC 的组，由于提前实习了两个月，帮助建设过新人文档，对组里的人员业务还算了解。但由于实习结束，回校办理毕业适宜耽搁一个月，再入职时，忽然没有需求分配给我了。于是度过了快乐的摸鱼时间，享受了最后一个月的大小周双倍工资

忽然有一天 leader 和 mentor 找到我，问我是否愿意去志愿下北京的一个业务。原来是一个 ToB 平台，和我们同属一个 +2，发展迅速，人手短缺，向 +2 四处要人，摊派到我们组就是一个名额。彼时我刚刚毕业，浑身有使不完的冲劲儿，又恰好闲着，自然满嘴答应

于是就一直跟着北京的那个组做需求，这算是一个向上管理的平台，平台 QPS 很低，但是主要用来产出数据向上汇报，和 ToC 业务的关注点完全不同，重业务轻性能，更早期甚至对一致性也没很高的要求，调用失败了，加个报警，人工看看，影响不大甚至可以不修，再加上平台用户操作频率也不高，日常维护也算的上清闲

我加入时期，恰逢平台大版本迭代，北京组里派了一个研发远程带着我做需求，最初都是写小需求，边边角角，修修改改，主要是熟悉熟悉流程

TIP
需求初评 —— 需求详评 —— （研发开始介入）技术评审 —— 开发 —— （测试开始介入）showcase —— 测试 —— Launch Review —— 上线

有条不紊，一个需求接着一个需求，没有多余的事情。我从最开始的，技术评审都不知道说些什么，甚至专门找个会议室正襟危坐，到后来……

但其实并没有什么后来的进步，只是习惯或者麻木了而已，也逐渐看轻了这些事情。一个线下 bug 也并不会怎么样，就算是线上 bug，大不了修数据

本身用 Golang 写业务就相当 Freelance，再加上需求的快速迭代，没什么时间对代码进行重构，能跑起来就是成功，仓库代码愈发狂乱。许多奇奇怪怪的复杂需求，再加上四处借调导致技术风格不统一，让这个平台逐渐成了一个“大泥球”

但和我又有什么关系呢，我只是一个写小需求的 noob 罢了

由于刚入职，干啥都是新奇的，我甚至周末会到公司主动加班 —— 反正一个人在家也没什么事做，何乐而不为呢。后期给自己找了点事情，完成了 MYDB 和相关的教程，虽说最后 BUG 不少，也没怎么充分测试，但确实令我干劲十足：八九点下班，能一直写到凌晨一两点，还能再洗个澡打打游戏喝点小酒，三四点睡觉

也结交了不少有趣的人，拉了个小群，每天不工作的时候就在群里吹吹水。这时的字节简直满足了我对互联网的一切想象：自由自在，管理扁平，请个假不用费尽心思编理由，工作电脑也想装啥装啥，甚至因为疫情还没有结束，隔三岔五就居家办公，没有打卡和强制工时，十一点多到公司，吃完晚饭就跑路……

发愤

就这么一路开开心心地干着，到了 22 年初。在这期间，我也由一些边角需求开始，逐渐能 cover 住整个领域

阿里有句古话，经常在安慰被裁人员或者被裁时自我安慰时使用：“拥抱变化”

唯一不变的，就是变化

平台发展迅猛，业务从直播扩展到了整个抖音，同时由于产品的调整，原本的北京开发团队把平台交接了出去，接盘的恰好是我原本的组

于是便是交接流程，每天的活动就是带着新人（新组的人）做需求，以及各种分享。我在那时已经负责预算模块，于是也组织了一次分享。虽然全程念文档毫无感情，但也确实是我在公司的第一次分享（转正不需要答辩）

随着北京的人逐渐撤出，人力猛然出现短缺。于是在预算模块外，整个项目领域又猛地塞到我手上。恰逢产品提出了一个大需求，我在项目领域的第一个需求，就是将整个项目领域近乎重写了一番

需求撞上春节假期，需求紧急，整个假期除了三十和初一，都在图书馆搓代码，前后由于理解误差等原因（还是太菜了），整个代码被来来回回实现了三四遍，最后终于勉强赶上了节后第一班上线

后续又有各种历史帐清算，各种重构评审，代码迁移到新服务（BTW，2022 年启动的新服务迁移，至今没有迁移完成），忙到脚不沾地

那段时间极其焦虑，加班非常猛。日常处理各种问题都够忙到十几点，基本没有十点之前下过班。对应的就是报复性熬夜和报复性娱乐。典型娱乐比如周五晚上到凌晨在公司找个会议室喝酒，喝到周六大清早回家睡觉 😅

非常神奇的是，每次加班时，都能遇到我组组长，每次十点十一点钟，不是我喊他下班就是他喊我下班。我图上下班方便，直接搬到了公司所在的小区，每天上下班走地下车库；他住的地方每天通勤要五十分钟一小时

可能这就是有家庭的代价吧

由于下班太晚，各种日常开发和学习也基本都停掉了，回到家只想喝酒和睡觉。喝的酒也逐渐从自己调制的鸡尾酒变为伏特加/威士忌直接喝，喝酒的目的也从好喝/微醺变成了助眠/去除焦虑

转变

有时候宁愿生活一成不变，因为熟悉的平淡胜过未知的风险

风险来的很快

22 年中，我们组换了一个新的 +2，气氛开始微妙变化。原本随意的非正式会议变得正式化，需求流程也变得复杂，简单的步骤被新增了无数的审查环节，每一个决策都需要经过层层把关

各种名词被生造了出来：bug 比人天、人效比、代码复杂度等等。指标的或高或低，通常意味着你在下次周会或者双周会上会被拎出来批斗。产研测的关系也不再和谐，各种会议上的唇枪舌剑、钩心斗角、推诿甩锅，让人精疲力竭，专心写代码成了一种奢望。做多错多，不做不错，能推则推，成了保命技巧。原本“线上 bug 大不了修数据”，到现在“一个回归 bug 就能宣判你的死刑”

也是从这段时间开始，hc 的收缩导致组里开始减员，很多我熟悉的人逐渐要么主动要么被动地离开了，原本每天一起吃饭一起摸鱼一起下班的同事，好些一周才能见到一次，工作的孤独感不断加剧

在这种情况下，不知是情绪躯体化，还是这几年熬夜 + 喝酒，或者兼具有之，身体开始报警，具体可见：慢性胃炎治疗之路

体重急剧减轻之下（一个月 12 斤），痛定思痛，决定~~开摆~~开启养生模式！

于是过上了每天八点半起床去公司吃早餐，晚上六点多吃完晚饭直接下班，下班后跑步半小时，十二点前睡觉（目前还在努力）的健康生活

CAUTION
奋斗？命都要没了还怎么奋斗！

好在，前面那段剧变也搞走了不少产品，需求量急剧减少。虽然上面也开启了“没法整活那就整人”模式，又增加了许多乱七八糟的卡点和规范，且现在的 +2 阿里味儿特别浓厚，很喜欢搞一些莫名其妙的团建和个人 show 表演（算是另一种的折磨人）。平台进入低频维护期，琐碎的事情也不再多

外面行情很差，先这么混着吧

后记

原本这篇三周年总结应该在 5、6 月份完成，但那时恰逢产品剧变 + 身体不适，这篇文档的标题就躺在我的备忘录三个月，直到最近身体状况稳定了下来，才又拾起了总结。然而就是这三个月，我的心态就从积极进取变成了“先这么混着”，不禁让人感叹世事多变

但是好在，一定程度的心理健康也确实保持住了。最近在研究心理状态检测 + 日程规划，尝试做一个自律的人，虽然暂时的成果是能直观的看到时间被浪费到哪了，后续会写篇文章介绍下这方面的成果

这些年出国留学的心思还是在蠢蠢欲动，尤其是遇到各种不如意时，就尤其上头。在无数忙碌了一天后的深夜，这个念头便犹如藤蔓，爬满心头。这三年距离我辞职最近的时刻，就是我在医院等待胃镜时，还在回复飞书消息处理 oncall 的时刻。我时常问自己：“为了这些工资，付出的这些代价真的值得吗”。但实际冷静下来，还是叹了口气，狠心摁下了这想法

不知道再过三年，我是否会后悔甚至痛恨现在的自己。但这也许就是选择的诅咒

无论你如何选择，甚至不做选择，你都必须承受代价

慢性胃炎治疗之路

Sun, 01 Sep 2024 14:03:10 GMT

我自幼便肠胃不佳，小学初中高中，看了无数医生，吃了无数的药，也没有把胃养好。一旦吃点冷的、辣的，便腹胀反酸、反胃想吐，甚至即使饮食健康，遇到什么考试面试紧张时也会反胃恶心。

神奇的是，这几乎所有的症状，在我本科期间，都奇迹般地消失了。冷的、辣的，啥都能吃，酒也猛猛喝，啥事没有，miracle！

工作后，生活习惯更加离谱。由于公司对早上上班时间要求较松，每日便熬夜，三年内几乎没有在三点前睡觉过。几乎每日喝酒，开始还会调一调酒，伏特加兑一兑橙汁等，十几度的样子。到后期酒量上来了，十几度已经难以满足，就直接干喝威士忌，每天 150ml 到 300ml 的样子，就这样又喝了两年。

~~不得不说，我的肝真的是 tough guy~~

结果肝先没出问题，胃先顶不住了。大概一个半月前，开始频繁恶心头晕反胃，尤其是吃饭后，吃了就吐，半月就瘦了快十斤😓再加上胡思乱想，网上看病更是吓人，实在顶不住了，连续做了两次胃镜（不得不吐槽下大城市的就医效率，浙一约胃肠镜，基本只能约半个月后，约周末更是别想，实在绷不住就先跑回家做了个胃镜，回来后又做了一个），最终诊断结果

好在没有幽门螺旋杆菌，但是就是这慢性胃炎伴糜烂，比我想象的要更是折磨。

医生给开了三种药：艾司奥美拉挫肠溶片、替普瑞酮胶囊和马来酸曲美布汀分散片，吃两周。

吃药的两周非常舒服，几乎完全感受不到任何难受，吃嘛嘛香，后面才知道是奥美拉挫抑制了胃酸，抑制住了所有症状。但是一旦开始停药，事情就坏起来了。

事实上没有遇到非常剧烈的反扑，但是胃部（左上腹）有一种存在感，不痛，但是能感受到，这种感觉时时刻刻提醒着我，时常令人心情烦躁，然而胃又是情绪器官，于是……

Time to make some changes!

暂时的措施如下

每天早起（八点半）吃早餐，公司的早餐比较丰富，一般一个煮鸡蛋一碗粥，再加一些当天的包子馒头什么的
一天三次康复新液（蟑螂水）修复胃糜烂，康复新液倒是没有我想象中的那么难喝，除了比较甜腻外，克服了心理恐惧后还是比较好喝的（
维生素 B 族和维生素 C，想起来就吃，佛系吃
午饭后一个小时左右喝酸奶。这个暂时没有验证是否有效，因为酸奶买错了……买成光明的酸牛奶饮品，我还买了一箱😭
早睡，基本能压缩到一点之前睡觉（似乎也不是那么早
戒酒

看看咋样吧，没有进行非常严格的节食，希望养个几个月能养好

基于 FakeIP 的透明代理分流

Fri, 16 Aug 2024 15:53:00 GMT

前言

上篇文章中介绍了使用旁路由做局域网内透明代理的方案，对于大部分用户已经基本可用，但是该方案的 cons 也比较明显：

存在单点故障的可能，由于 DHCP 下发的网关直接指向了旁路由，一旦旁路由的 clash 不可用，即使不需要科学的网站也无法访问
clash 包转发性能孱弱，远比不上硬件转发。而一旦网关设置为旁路由，由于 iptables 的设置，无论是否需要科学的流量都会走 clash 转发
由于存在旁路由网关，端口映射需要同时在主路由和旁路由配置

正好，最近看到了一个新兴的代理内核 sing-box（似乎也不新兴了，只是从 clash archive 后才火起来）。看了下 Wiki，支持的协议和功能十分全面，在性能优化上也比 clash 要好。新方案的代理核心就直接用 sing-box 了。

当然该方案也可以用 clash 实现就是了（

~~坏消息，sing-box 的 wiki 需要越墙才可访问~~

方案思路

sing-box 和 clash 都内置了 DNS 模块，实现了 DNS Server 了功能，且都有 FakeIP。关于 FakeIP，可以理解为当客户端进行 DNS 查询时，DNS 模块立刻响应一个假的 IP 地址，并在后台进行实际的 DNS 查询过程，并维护这个假 IP 地址和实际 IP 的映射关系。当后续客户端拿着这个 FakeIP 来建立连接发送数据时，网关即可根据这个映射关系向真实的 IP 发起请求。更具体的描述可见 RFC3089。由于后续进行流量路由时需要用到 DNS 应答时存储的 FakeIP 和真实 IP 映射，所以单纯的 DNS Server 无法单独实现 FakeIP 机制。

由于 FakeIP 通常位于一个保留网段（大部分配置为 198.18.0.0/15），分流特征及其明显，分流也十分简单。我们可以直接让软路由代理的 DNS 模块仅对需要代理的域名响应 FakeIP，在主路由中配置下一跳，仅让目标 IP 为 FakeIP 的流量通过软路由代理，非 FakeIP 的流量正常转发。具体如下

fakeIP 分流

1. 无须科学的域名
  1. 客户端发起 DNS 解析
  2. DNS 模块判断为无须科学，向国内 DNS 请求，返回 RealIP
  3. 客户端使用 RealIP 发起请求
  4. 主路由判断不是 FakeIP，走默认路由（直连）
  
2. 需要科学的域名
  1. 客户端发起 DNS 解析
  2. DNS 模块判断为需要科学，返回 FakeIP，并向国外 DNS 请求
  3. 客户端使用 FakeIP 发起请求
  4. 主路由判断是 FakeIP，路由流量到代理软件
  5. 代理软件根据 FakeIP 映射，通过出口节点向国外 IP 发起请求

这个方案解决了上篇文章的三个 cons：

单点故障问题，避免了 sing-box 失效导致无法联网。基于上篇文章的方案，sing-box 的 DNS 解析应当位于 AdGuard 后，当 sing-box 失效时，AdGuard 发现上游 DNS 异常，会启用后备 DNS，即国内 DNS。由于不返回 FakeIP，所有流量在主路由分流时都会走默认路由
该方案无须科学的流量不会走代理软件转发，而是直接走路由转发
由于转发是由主路由路由表进行，所有客户端网关都为主路由，不存在二层 NAT，主路由端口映射不会失效

具体实现

主路由配置

首先在主路由配置下一跳网关，ikuai 的配置位于流控分流 - 分流设置 - 端口分流，添加一条分流规则，分流方式选择下一跳网关，并填写你的软路由 IP，我的就是 192.168.7.2 了。并在目的地址中添加一条 198.18.0.0/15，其他配置保持默认即可

下一跳网关

这样所有目标地址为 198.18.0.0/15 的流量经过主路由时都会被转发到 192.168.7.2 了

sing-box 安装和配置

使用上篇文章的教程搭建好 AdGuard Home，上游 DNS 仍然设置为 127.0.0.1

。之后安装 sing-box，Debian 机器只需要一条命令：

bash <(curl -fsSL https://sing-box.app/deb-install.sh)

其他发行版的安装方法可在 https://sing-box.sagernet.org/installation/package-manager 中找到。

安装程序会自动创建 systemd service。sing-box 的 systemd service 比较不走寻常路，定义位于 /lib/systemd/system/sing-box.service，编辑这个文件，在 ExecStart 前加上这三行：

ExecStartPre  = +/usr/bin/bash /etc/sing-box/clean.sh
ExecStartPost = +/usr/bin/bash /etc/sing-box/iptables.sh
ExecStopPost  = +/usr/bin/bash /etc/sing-box/clean.sh

这其实和上个方案类似，也是在启动时设置路由表，并在 sing-box 关闭时清除。sing-box 的所有配置都位于 /etc/sing-box 下，默认读取的配置文件也是 /etc/sing-box/config.json，所以我们也保持统一。

新建 /etc/sing-box/iptables.sh 和 /etc/sing-box/clean.sh 如下：

#!/usr/bin/env bash

set -ex

# ENABLE ipv4 forward
sysctl -w net.ipv4.ip_forward=1
# ENABLE ipv6 forward
sysctl -w net.ipv6.conf.all.forwarding=1

### IPv4 Routing Rules ###
# ROUTE RULES
ip rule add fwmark 666 lookup 666
ip route add local 0.0.0.0/0 dev lo table 666

# clash 链负责处理转发流量
iptables -t mangle -N clash

# 跳过内网流量
iptables -t mangle -A clash -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A clash -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A clash -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A clash -d 224.0.0.0/4 -j RETURN

#!/usr/bin/env bash

set -ex

# ENABLE ipv4 forward
sysctl -w net.ipv4.ip_forward=1
# ENABLE ipv6 forward
sysctl -w net.ipv6.conf.all.forwarding=1

### IPv4 Routing Rules ###
# ROUTE RULES
ip rule add fwmark 666 lookup 666
ip route add local 0.0.0.0/0 dev lo table 666

# clash 链负责处理转发流量
iptables -t mangle -N clash

# 跳过内网流量
iptables -t mangle -A clash -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A clash -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A clash -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A clash -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A clash -d 240.0.0.0/4 -j RETURN

# 需代理的 IP 转向到 7893 端口，并打上 mark
iptables -t mangle -A clash -d 198.18.0.0/15 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 666
iptables -t mangle -A clash -d 198.18.0.0/15 -p udp -j TPROXY --on-port 7893 --tproxy-mark 666

# 剩余流量正常处理
iptables -t mangle -A clash -j RETURN

# 最后让所有流量通过 clash 链进行处理
iptables -t mangle -A PREROUTING -j clash

# clash_local 链负责处理网关本身发出的流量
iptables -t mangle -N clash_local

# 跳过内网流量
iptables -t mangle -A clash_local -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A clash_local -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A clash_local -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A clash_local -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A clash_local -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A clash_local -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A clash_local -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A clash_local -d 240.0.0.0/4 -j RETURN

# 为本机发出的流量打 mark
iptables -t mangle -A clash_local -p tcp -j MARK --set-mark 666
iptables -t mangle -A clash_local -p udp -j MARK --set-mark 666

# 让本机发出的流量跳转到 clash_local
# clash_local 链会为本机流量打 mark, 打过 mark 的流量会重新回到 PREROUTING 上
iptables -t mangle -A OUTPUT -j clash_local

# 修复 ICMP(ping)
# 这并不能保证 ping 结果有效 (clash 等不支持转发 ICMP), 只是让它有返回结果而已
# --to-destination 设置为一个可达的地址即可
sysctl -w net.ipv4.conf.all.route_localnet=1
iptables -t nat -A PREROUTING -p icmp -d 198.18.0.0/16 -j DNAT --to-destination 127.0.0.1

#!/usr/bin/env bash

set -ex

ip rule del fwmark 666 table 666 || true
ip route del local 0.0.0.0/0 dev lo table 666 || true

iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X clash || true
iptables -t mangle -X clash_local || true

iptables.sh 其实和上篇文章的 iptables.sh 高度相似，只是最终 clash 链的最终处理变为了：将目标地址为 198.18.0.0/15 的流量转发到 7893 的 tproxy 端口，其他流量则走默认规则。实际上就是将被主路由转发的 FakeIP 流量交给 sing-box 处理了。clean.sh 则完全没有变化。

这里两个处理链：clash 和 clash_local，我还是保留了 clash 的名称，因为实际上就是从 clash 方案简单修改来的。（偷懒）

接着就是 sing-box 的配置文件，我这里给出一份配置模板：

{
  "log": {
    "level": "info",
    "output": "box.log",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "tag": "cloudflare",
        "address": "tls://1.1.1.1",
        "detour": "🌍 外网" // 改为你的代理节点 tag
      },
      {
        "tag": "local",
        "address": "223.5.5.5",
        "detour": "DIRECT"
      },
      {
        "tag": "dns-fakeip",
        "address": "fakeip"
      },
      {
        "tag": "block",
        "address": "rcode://success"

{
  "log": {
    "level": "info",
    "output": "box.log",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "tag": "cloudflare",
        "address": "tls://1.1.1.1",
        "detour": "🌍 外网" // 改为你的代理节点 tag
      },
      {
        "tag": "local",
        "address": "223.5.5.5",
        "detour": "DIRECT"
      },
      {
        "tag": "dns-fakeip",
        "address": "fakeip"
      },
      {
        "tag": "block",
        "address": "rcode://success"
      }
    ],
    "rules": [
      {
        "server": "block",
        "query_type": [
          "HTTPS",
          "SVCB"
        ]
      },
      {
        "server": "local",
        "outbound": "any"
      },
      {
        "server": "local",
        "rewrite_ttl": 10,
        "type": "logical",
        "mode": "and",
        "rules": [
          {
            "rule_set": [
              "geosite-geolocation-!cn"
            ],
            "invert": true
          },
          {
            "rule_set": [
              "geosite-cn",
              "geosite-category-companies@cn",
              "geoip-cn"
            ]
          }
        ]
      },
      {
        "server": "dns-fakeip",
        "rewrite_ttl": 1,
        "query_type": [
          "A",
          "AAAA"
        ]
      }
    ],
    "strategy": "ipv4_only",
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15"
    }
  },
  "inbounds": [
    {
      "type": "tproxy",
      "tag": "tproxy-in",
      "listen": "::",
      "listen_port": 7893,
      "tcp_fast_open": true,
      "udp_fragment": true,
      "sniff": true
    },
    {
      "type": "mixed",
      "tag": "mixed-in",
      "listen": "::",
      "listen_port": 7890,
      "tcp_fast_open": true,
      "udp_fragment": true,
      "sniff": true
    },
    {
      "type": "direct",
      "tag": "dns-in",
      "listen": "::",
      "listen_port": 1053
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "DIRECT"
    },
    {
      "type": "block",
      "tag": "REJECT"
    },
    {
      "type": "dns",
      "tag": "dns-out"
    },
    // 此处填写你的代理节点
  ],
  "route": {
    "rules": [
      {
        "inbound": "dns-in",
        "outbound": "dns-out"
      },
      {
        "protocol": "dns",
        "outbound": "dns-out"
      },
      {
        "outbound": "DIRECT",
        "type": "logical",
        "mode": "and",
        "rules": [
          {
            "rule_set": [
              "geosite-geolocation-!cn"
            ],
            "invert": true
          },
          {
            "rule_set": [
              "geosite-cn",
              "geosite-category-companies@cn",
              "geoip-cn"
            ]
          }
        ]
      }
    ],
    "rule_set": [
      {
        "type": "remote",
        "tag": "geoip-cn",
        "format": "binary",
        "url": "https://cdn.jsdelivr.net/gh/SagerNet/sing-geoip@rule-set/geoip-cn.srs",
        "download_detour": "DIRECT"
      },
      {
        "type": "remote",
        "tag": "geosite-cn",
        "format": "binary",
        "url": "https://cdn.jsdelivr.net/gh/SagerNet/sing-geosite@rule-set/geosite-cn.srs",
        "download_detour": "DIRECT"
      },
      {
        "type": "remote",
        "tag": "geosite-geolocation-!cn",
        "format": "binary",
        "url": "https://cdn.jsdelivr.net/gh/SagerNet/sing-geosite@rule-set/geosite-geolocation-!cn.srs",
        "download_detour": "DIRECT"
      },
      {
        "type": "remote",
        "tag": "geosite-category-companies@cn",
        "format": "binary",
        "url": "https://cdn.jsdelivr.net/gh/SagerNet/sing-geosite@rule-set/geosite-category-companies@cn.srs",
        "download_detour": "DIRECT"
      }
    ],
    "final": "🌍 外网", // 改为你的代理节点 tag
    "auto_detect_interface": true
  },
  "experimental": {
    "clash_api": {
      "external_controller": "0.0.0.0:9090",
      "external_ui": "yacd",
      "external_ui_download_url": "https://github.com/MetaCubeX/Yacd-meta/archive/gh-pages.zip",
      "external_ui_download_detour": "🌍 外网", // 改为你的代理节点 tag
      "default_mode": "Rule"
    }
  }
}

注意几个注释的地方需要修改。默认配置中，会将中国域名的 DNS 解析直接通过 223.5.5.5 解析成 RealIP（见 DNS-rules[2]），其他域名解析为 FakeIP（见 DNS-rules[3]）。并在进行流量分流时，将所有中国 IP 和域名都走 DIRECT 直连（见 route-rules[2]），其他流量都走代理（见 route-final）。

完全配置好以后，我们可以设置 sing-box 为开启自动启动，并立即启动起来。

systemctl enable --now sing-box

后续如想查看日志，我们直接使用 Debian 自带的工具来查看：

journalctl -efu sing-box

由于 sing-box 提供了兼容 clash 的 api，所以也可以直接使用 clash 的 web ui 进行管理。在启动后稍等一会（sing-box 下载 ui），即可通过 9090 端口打开 yacd 界面了。

Telegram 问题

此方案的缺点也很明显，由于基于 DNS 分流，不走 DNS 的直接 IP 流量都会被主路由直接直连，导致像 Telegram 之类的直接使用 IP 的 APP 无法正确分流。解决方法也很简单，将这个 IP 加到主路由下一跳网关的 IP List，iptables.sh 的转发列表，和 sing-box 配置中的 rules 中，指定该 IP 走代理即可。

当前我是写了个脚本帮我自动处理规则集中的 IP，生成对应的 IP List、iptables.sh 和可直接用于 sing-box 的 config.json 配置文件。待我加工加工，脱敏后开源，敬请期待吧。

旁路由端口映射失效解决

Thu, 15 Aug 2024 15:50:00 GMT

前言

使用上篇文章的方案配置完成后，如果你在主路由上配置了端口映射，且被映射端口的机器网关配置的是旁路由，那此时端口映射应当是失效了。其实并不是 Clash 分流导致的问题，只要是配置了旁路由网关，主路由配置的端口映射都会失效。

原理（太长不看系列）

网关的作用其实就是 NAT 地址转换，用于将内部网络的流量转发到外部网络，内部流量只要传输到外部网络，就必须通过网关。所以每个内网机器都必须配置一个网关地址，以与外部通信。

网关在实现上，可以简单理解为一个自动的端口转发。网关对每一个活动连接（通过五元组唯一标识）都维护了一个端口对，一个端口对内一个端口对外。例如你的机器与 Google 服务器建立连接，网关维护的端口对是 (32384, 14122)，那么就表示你向 Google 发送的所有流量都要发送到网关的 32384 端口，网关转发流量包，通过 14122 端口送往 Google 的服务器，反之 Google 服务器向你发送数包也要经过这层转发。当然很多时候 NAT 不一定只有一层，如果你的宽带没有获取到公网 IP，那么你的家庭网关的上级网关也会做一次 NAT，最终与 Google 通信的网关一定是具有公网 IP 的网关（只有具有公网 IP 的机器才可以在互联网通信）

当我们配置了旁路由时，旁路由由于充当了网关，也会进行一次 NAT。那么在你的机器与外部通信时，实际上是经过两次 NAT 的：

你的机器 <——> 旁路由（NAT） <——> 主路由（NAT） <——> 外部机器

如果你在主路由配置端口映射，但是内部机器配置的网关却是旁路由，当你尝试通过公网 IP 访问内网时，入流量是这样的：

外部机器 ----> 主路由网关 ----> 你的机器

而出流量则是这样的：

你的机器 ----> 旁路由 ----> 主路由 ----> 外部机器

实际上，在外部机器发起连接的时候，你的机器只与主路由网关建立了连接，但是回程流量却被发到了旁路由网关，旁路由网关找不到连接对应的端口对就会直接将包丢弃，导致了端口映射失效

解决方案（直接看这个）

解决方案很简单，内网包含了两层 NAT，那也只需要将端口映射配置两次即可。

主路由配置端口映射，指向旁路由
旁路由配置端口映射，指向目标机器

这样，无论入程还是回程，流量都按如下模式路由，即可成功建立连接

你的机器 <——> 旁路由（NAT） <——> 主路由（NAT） <——> 外部机器

主路由和旁路由配置端口映射的方式因系统而异，iKuai 和 OpenWRT 都由图形化的方式配置，这里不再赘述了。上篇文章的方案中旁路由使用的是 Debian，实际上以下方法适用于所有使用 iptables 的系统。执行以下命令设置 iptables，以下为目标机器为"内部"，称呼网关机器为"外部"

iptables -t nat -I PREROUTING -p tcp -d <外部 IP> --dport <外部端口> -j DNAT --to-destination <内部 IP>:<内部端口>
iptables -t nat -I POSTROUTING -p tcp --dport <内部端口> -d <外部 IP> -j SNAT --to-source <内部 IP>

执行完后即可设置 iptables

注意上篇文章中 clean.sh 中的 iptables -t nat -F 命令会清除所有用户自定义的路由规则，导致转发失效。所以在执行完后需要补充执行下上述命令。

debian 旁路由方案

Sat, 13 Jul 2024 09:49:00 GMT

前言

大部分旁路由方案都是基于 OpenWRT 搭建 —— 这是一个单独的 Linux 发行版，拥有自己的软件包系统。再其中大部分方案又是基于 LuCI —— 专用于 OpenWRT 的 Web GUI，教程中使用的软件也是 luci-app-xxx，专为 LuCI 打造。这些方案很好，但不够好：

过于依赖 GUI 配置：LuCI 的软件包通常在 web 端只能进行有限的配置
LuCI 不够稳定：不是 OpenWRT 不稳定，而是 LuCI 不稳定。我的 LuCI 曾因为 OpenClash 崩溃过三次（也可能是我的问题）
尽管我们可以自编译 OpenWRT，但是大部分教程都直接使用了一些预编译好的固件，有些可能会过时
无法完全掌控系统（被 LuCI 架空啦

我也曾经折腾过一两年的 OpenWRT 透明代理方案，主路由方案旁路由方案，最终都因为其不够稳定而放弃。很长一段时间都直接使用各种客户端（Surge、loon、clash verge rev 等）勉强用着。大概一周前，绝区零上线。由于国服版号问题，PS5 仅上线了国际服。即使选择亚服，勉强可以直连，网速和延迟也让人绝望。本着不给网易 UU 送钱的态度，我又想起了透明代理。正好，我手头有一台闲置的零刻小主机。预先装好了 Debian，本来打算用来做开发机来着，结果因为我太懒，也一直吃灰。于是折腾了一个周末，最终完成了使用 Debian 作为旁路由进行透明代理的方案。

最终形态的网络拓扑如下：

topo

可以看到，整个内网被划分成了两个网段：192.168.6.0/24，192.168.7.0/24。其中 6.0/24 为默认网段，用于无需越墙的设备，而 7.0/24 为需要越墙的设备，其流量都会经过旁路由小主机转发。

主要方案为 AdguardHome + Clash，其中 AdguardHome 用于广告过滤等功能，Clash 用于 DNS 分流和流量代理。

主路由配置

在配置之前，内网 IP 段为 192.168.6.0/24，我们需要新开一个网段 192.168.7.0/24

我的主路由是 iKuai，下面是 iKuai 新开网段的方法，OpenWRT 或者其他路由系统可以自行 Google

iKuai 下网络设置 - 内外网设置 - lan1，高级设置中添加一个扩展 IP，IP 为 192.168.7.1，子网掩码 255.255.255.0

iKuai 配置

DHCP 设置中添加一个 192.168.7.0/24 网段的 DHCP 配置

DHCP 配置

网关设置为 192.168.7.2，即后面要配置的旁路由的地址，首选 DNS 和备选 DNS 也都设置为 192.168.7.2，因为该网段下的 DNS 都由旁路由处理。

Debian 配置

以下操作如果不做说明，都是在旁路由机器上进行。

配置 IP

编辑 Debian 的网络配置：输入 sudo nano /etc/network/interfaces，编辑为以下内容，并保存退出：

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
dns-nameservers 127.0.0.1

该配置中：

enp1s0 是我的网卡设备名，请将其改为你自己的设备名，可以通过 ip a 查看
IPV4 网络进行静态配置 inet static，并固定设备 IP 为 192.168.7.2/24，网关指向主路由 192.168.7.1，DNS 在配置完成前可以先设置为可用的 DNS Server，等待本机上的 AdguardHome 配置完成后再改为 127.0.0.1，以防在配置过程中无法上网

保存配置后可以通过如下命令重启网络

sudo systemctl restart networking.service

注意这个时候 SSH 连接可能会断开，因为设备 IP 已经改变了。应当通过新的 IP 192.168.7.2 重新 SSH 登陆。

ip a 查看配置结果：

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:70:fc:00:e3:36 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.2/24 brd 192.168.7.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 ■■■:■■■■:■■■■:■■■:■■■■:■■■■/64 scope global dynamic mngtmpaddr
       valid_lft 1741sec preferred_lft 1741sec
    inet6 fe80::7270:fcff:fe00:e336/64 scope link
       valid_lft forever preferred_lft forever

可以看到本机的内网 IP 已经变成了 192.168.7.2/24

配置转发

只有拥有流量转发功能的机器才可以作为路由和网关：

sudo echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sudo sysctl -p

AdguardHome 配置

以下说明下 DNS 思路

DNS 链路

当客户端需要解析 DNS 时，监听在 53 端口上的 AdguardHome 会转发给其上游 Clash，然后 Clash 根据设置来进行分流，中国大陆部分使用国内的公共 DNS 服务器进行解析，非中国大陆部分通过代理向国外公共 DNS 服务器进行解析

而当 Clash 出现异常时，AdguardHome 则直接向国内公共 DNS 服务器请求解析（实际上意义不大，即使解析出来的 IP，流量还是要通过 Clash）

安装 AdguardHome

以下命令以 root 身份运行

## 检查最新稳定版的版本号，如果获取不到请检查网络
remote_ver=$(curl -sS https://api.github.com/repos/AdguardTeam/AdGuardHome/releases/latest | jq -r .tag_name | sed 's|v||' | grep -v "null"); echo $remote_ver

## 下载最新稳定版（前一句有输出这一句才能正常执行）
cd /tmp
wget -q --progress=bar:dot --show-progress -O "AdGuardHome_linux_amd64.tar.gz" "https://github.com/AdguardTeam/AdGuardHome/releases/download/v${remote_ver}/AdGuardHome_linux_amd64.tar.gz"

## 解压
tar --no-same-owner -xf "AdGuardHome_linux_amd64.tar.gz" --strip-components 2 --directory=.

## 安装
install -ps AdGuardHome /usr/local/bin/adguardhome

创建服务

创建工作目录 /var/lib/adguardhome

mkdir -p /var/lib/adguardhome

创建 /etc/systemd/system/adguardhome.service 如下，这时配置文件为 /var/lib/adguardhome/AdGuardHome.yaml

[Unit]
Description = Network-wide ads & trackers blocking DNS server.
Wants       = network-online.target mosdns.service
After       = network-online.target mosdns.service

[Service]
Type               = simple
Restart            = always
StartLimitInterval = 5
StartLimitBurst    = 10
ExecStart          = /usr/local/bin/adguardhome -w /var/lib/adguardhome
RestartSec         = 10

[Install]
WantedBy = multi-user.target

保存后通过 systemctl enable --now adguardhome.service 设置开机启动并立刻启动。后续如想查看日志，我们直接使用 Debian 自带的工具来查看：

journalctl -efu adguardhome.service

如果想要重启：

systemctl restart adguardhome.service

初始化配置

打开 http://192.168.7.2:3000 进行初始化配置，网络管理界面端口可以保持 3000，DNS 服务器端口设置为 53

设置 - DNS 设置中，上游 DNS 设置为我们暂未配置的 Clash DNS 127.0.0.1:1053，后备 DNS 服务器可以填写几个国内的 DNS，如

223.5.5.5
119.29.29.29

记得点击应用

随后 DNS 服务配置 - 速度限制设置为 0 即可。

如果需要去广告的话，可以在过滤器 - DNS 黑名单中添加，这里推荐两个大陆使用效果较好的规则集：

easylist:  https://anti-ad.net/easylist.txt
half-life: https://adguard.yojigen.tech/HalfLifeList.txt

Clash 配置

Clash 在整个方案中负责国内外 DNS 解析分流，另外就是老本行穿墙了。由于 Clash 原仓库已删库跑路，衣钵由 mihomo 集成（米哈游你坏事做尽）

安装 Clash

以下命令以 root 身份运行：

## 检查最新稳定版的版本号，如果获取不到请检查网络
remote_ver=$(curl -sS https://api.github.com/repos/MetaCubeX/mihomo/releases/latest | jq -r .tag_name | sed 's|v||' | grep -v "null"); echo $remote_ver

## 下载最新稳定版（前一句有输出这一句才能正常执行）
cd /tmp
wget -q --progress=bar:dot --show-progress -O "mihomo-linux-amd64-v${remote_ver}.gz" "https://github.com/MetaCubeX/mihomo/releases/download/v${remote_ver}/mihomo-linux-amd64-v${remote_ver}.gz"

## 解压
gzip -d "mihomo-linux-amd64-v${remote_ver}.gz"

## 安装
install -ps mihomo-linux-amd64-v${remote_ver} /usr/local/bin/clash

创建服务

创建工作目录 /var/lib/clash

mkdir -p /var/lib/clash

创建用户 clash

useradd -M -s /usr/sbin/nologin clash

创建文件 /etc/systemd/system/clash.service，内容如下。这时 clash 的配置文件为 /var/lib/clash/config.yaml。

[Unit]
Description = Clash-Meta tproxy daemon.
Wants       = network-online.target
After       = network-online.target

[Service]
Environment   = PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/b>
Type          = simple
User          = clash
Group         = clash

CapabilityBoundingSet = CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
AmbientCapabilities   = CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW

Restart       = always
ExecStartPre  = +/usr/bin/bash /var/lib/clash/clean.sh
ExecStart     = clash -d /var/lib/clash
ExecStartPost = +/usr/bin/bash /var/lib/clash/iptables.sh

ExecStopPost  = +/usr/bin/bash /var/lib/clash/clean.sh

可以从这个文件中看到，clash 二进制文件是以 clash

用户身份运行的，这是为了方便区分 clash 自身程序发出来的流量，和 clash 转发的流量。

注意到 ExecStartPost 和 ExecStopPost 阶段我们执行了两个文件 iptables.sh 和 clean.sh，用来设置和清空路由表。

iptables.sh 和 clean.sh 内容如下：

#!/usr/bin/env bash

set -ex

# ENABLE ipv4 forward
sysctl -w net.ipv4.ip_forward=1

# ROUTE RULES
ip rule add fwmark 666 lookup 666
ip route add local 0.0.0.0/0 dev lo table 666

# clash 链负责处理转发流量
iptables -t mangle -N clash

# 目标地址为局域网或保留地址的流量跳过处理
# 保留地址参考：https://zh.wikipedia.org/wiki/%E5%B7%B2%E5%88%86%E9%85%8D%E7%9A%84/8_IPv4%E5%9C%B0%E5%9D%80%E5%9D%97%E5%88%97%E8%A1%A8
iptables -t mangle -A clash -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A clash -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A clash -d 169.254.0.0/16 -j RETURN

iptables -t mangle -A clash -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A clash -d 240.0.0.0/4 -j RETURN

#!/usr/bin/env bash

set -ex

# ENABLE ipv4 forward
sysctl -w net.ipv4.ip_forward=1

# ROUTE RULES
ip rule add fwmark 666 lookup 666
ip route add local 0.0.0.0/0 dev lo table 666

# clash 链负责处理转发流量
iptables -t mangle -N clash

# 目标地址为局域网或保留地址的流量跳过处理
# 保留地址参考：https://zh.wikipedia.org/wiki/%E5%B7%B2%E5%88%86%E9%85%8D%E7%9A%84/8_IPv4%E5%9C%B0%E5%9D%80%E5%9D%97%E5%88%97%E8%A1%A8
iptables -t mangle -A clash -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A clash -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A clash -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A clash -d 169.254.0.0/16 -j RETURN

iptables -t mangle -A clash -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A clash -d 240.0.0.0/4 -j RETURN

# 其他所有流量转向到 7893 端口，并打上 mark
iptables -t mangle -A clash -p tcp -j TPROXY --on-port 7893 --tproxy-mark 666
iptables -t mangle -A clash -p udp -j TPROXY --on-port 7893 --tproxy-mark 666

# 最后让所有流量通过 clash 链进行处理
iptables -t mangle -A PREROUTING -j clash

# clash_local 链负责处理网关本身发出的流量
iptables -t mangle -N clash_local

# 跳过内网流量
iptables -t mangle -A clash_local -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A clash_local -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A clash_local -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A clash_local -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A clash_local -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A clash_local -d 169.254.0.0/16 -j RETURN

iptables -t mangle -A clash_local -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A clash_local -d 240.0.0.0/4 -j RETURN

# 为本机发出的流量打 mark
iptables -t mangle -A clash_local -p tcp -j MARK --set-mark 666
iptables -t mangle -A clash_local -p udp -j MARK --set-mark 666

# 跳过 clash 程序本身发出的流量，防止死循环 (clash 程序需要使用 "clash" 用户启动)
iptables -t mangle -A OUTPUT -p tcp -m owner --uid-owner clash -j RETURN
iptables -t mangle -A OUTPUT -p udp -m owner --uid-owner clash -j RETURN

# 让本机发出的流量跳转到 clash_local
# clash_local 链会为本机流量打 mark, 打过 mark 的流量会重新回到 PREROUTING 上
iptables -t mangle -A OUTPUT -j clash_local

# 修复 ICMP(ping)
# 这并不能保证 ping 结果有效 (clash 等不支持转发 ICMP), 只是让它有返回结果而已
# --to-destination 设置为一个可达的地址即可
sysctl -w net.ipv4.conf.all.route_localnet=1
iptables -t nat -A PREROUTING -p icmp -d 198.18.0.0/16 -j DNAT --to-destination 127.0.0.1

#!/usr/bin/env bash

set -ex

ip rule del fwmark 666 table 666 || true
ip route del local 0.0.0.0/0 dev lo table 666 || true

iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X clash || true
iptables -t mangle -X clash_local || true

每行都有详细的注释，再细节可以去问 ChatGPT

clash 配置文件

clash 配置文件可以从各订阅商处获得，格式应当是 yaml。将其保存到 /var/lib/clash/config.yaml，并将其按照如下模块更改：

tproxy-port: 7893   # iptables.sh 将所有流量转发到了 7893 端口
mixed-port: 7890
allow-lan: true
find-process-mode: off
bind-address: "*"
mode: rule
log-level: debug
ipv6: false # 不进行 IPv6 流量代理

external-controller: 0.0.0.0:9090
secret: # 登陆 ui 的密码
external-ui: ui # webui 的基础路径
external-ui-name: xd # webui 的下级路径
external-ui-url: https://github.com/MetaCubeX/metacubexd/archive/refs/heads/gh-pages.zip
unified-delay: true
tcp-concurrent: true
experimental:
  sniff-tls-sni: true
geodata-mode: true
geodata-loader: standard
geox-url:
  geoip: https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.dat
  geosite: https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geosite.dat
  mmdb: https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/country.mmdb
profile:

tproxy-port: 7893   # iptables.sh 将所有流量转发到了 7893 端口
mixed-port: 7890
allow-lan: true
find-process-mode: off
bind-address: "*"
mode: rule
log-level: debug
ipv6: false # 不进行 IPv6 流量代理

external-controller: 0.0.0.0:9090
secret: # 登陆 ui 的密码
external-ui: ui # webui 的基础路径
external-ui-name: xd # webui 的下级路径
external-ui-url: https://github.com/MetaCubeX/metacubexd/archive/refs/heads/gh-pages.zip
unified-delay: true
tcp-concurrent: true
experimental:
  sniff-tls-sni: true
geodata-mode: true
geodata-loader: standard
geox-url:
  geoip: https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.dat
  geosite: https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geosite.dat
  mmdb: https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/country.mmdb
profile:
  tracing: true
  store-selected: true
  store-fake-ip: true
sniffer:
  enable: true
  parse-pure-ip: true
  override-destination: true

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:1053 # DNS 监听端口
  use-hosts: true
  enhanced-mode: fake-ip
  default-nameserver: # 建议修改为国内 DNS 服务器
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - tls://dot.pub
    - tls://dns.alidns.com
    - https://dns.alidns.com/dns-query
  fallback:
    - https://dns.cloudflare.com/dns-query
    - tls://dns.google:853
    - https://1.1.1.1/dns-query
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  fake-ip-filter:
    - '+.lan'
    - '+.cluster.local'
    - 'time.*.com'
    - 'time.*.gov'
    - 'time.*.edu.cn'
    - 'time.*.apple.com'
    - 'ntp.*.com'
    - 'localhost.ptlogin2.qq.com'
    - '+.ntp.org.cn'
    - '+.pool.ntp.org'
    - '+.localhost'
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw
    ipcidr:
      - 224.0.0.0/4
      - 240.0.0.0/4
      - 169.254.0.0/16
      - 0.0.0.0/8
      - 127.0.0.1/32
    domain:
      - '+.google.com'
      - '+.facebook.com'
      - '+.youtube.com'

proxies:  # 以下为你的代理节点、分组及代理规则
proxy-groups:
rules:

这里着重说一下 dns 部分，dns 分成了两个 dns server 组：

nameserver 部分为国内的公共 DNS
fallback 部分为国外的公共 DNS

fallback-filter 控制了当域名满足什么条件时，使用 fallback 组的 DNS 解析结果

geoip-code 为反向条件，即通过 nameserver 解析出的 IP 未命中 geoip-code 则会使用 fallback 的解析结果
geosite 为正向条件，匹配 geosite 中的域名会使用 fallback
ipcidr 为正向条件，nameserver 解析出这些结果时（即污染 IP）则会使用 fallback 的解析结果
domain 为正向条件，匹配到这些域名则会直接使用 fallback

由此即完成了 DNS 解析的分流。

clash 的其他相关文件

clash 还需要一些配套文件，在启动前需要先下载下来

cd /var/lib/clash
wget -q --progress=bar:dot --show-progress -O country.mmdb https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb
wget -q --progress=bar:dot --show-progress -O geosite.dat  https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat
wget -q --progress=bar:dot --show-progress -O GeoIP.dat    https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat

mkdir -p ui
cd ui
wget -q --progress=bar:dot --show-progress -O xd.zip https://github.com/MetaCubeX/metacubexd/archive/refs/heads/gh-pages.zip
unzip -oqq xd.zip
mv metacubexd-gh-pages xd

最终 /var/lib/clash 目录下应当是这样的

/var/lib/clash
├── clean.sh
├── config.yaml
├── country.mmdb
├── GeoIP.dat
├── geosite.dat
├── iptables.sh
└── ui

由于 clash 程序以 clash 用户身份启动，所以需要更改下所有权：

chown -R clash:clash /var/lib/clash

并设置 iptables.sh 和 clean.sh 可执行

chmod +x iptables.sh
chmod +x clean.sh

服务启动

完全配置好以后，我们可以设置 /etc/systemd/system/clash.service 为开启自动启动，并立即启动起来。

systemctl enable --now clash.service

后续如想查看日志，我们直接使用 Debian 自带的工具来查看：

journalctl -efu clash.service

访问 webui：http://192.168.7.2:9090/ui/xd

webui 的配置大家就很熟悉了。如果配置完成没啥问题，就可以将本机的 dns 改为 127.0.0.1 了（上文提到），并将内网设备的网关和 DNS 都指向 192.168.7.2

端口映射

如果你在主路由上配置了端口映射，且被映射端口的机器网关配置的是旁路由，那此时端口映射应当是失效了。可以在旁路由端口映射失效解决这篇文章中找到解决方案。

GFW 原理考

Sun, 23 Jun 2024 07:31:32 GMT

技术无罪。

防火长城（英语：Great Firewall，GFW），中国国家防火墙，或简称为墙、防火墙等，中国网信办称其为数据跨境安全网关，是该国政府过滤国际互联网出口内容的软硬件系统集合。———— Wikipedia

要有效对抗 GFW，不应只关注哪些网站被封，而应深入了解其封锁机制。知道 Google 被封并不能直接帮助翻墙，但理解 GFW 如何封锁 Google 对选择和实施翻墙方案至关重要。因此，在讨论翻墙方法之前，必须先深入研究 GFW 的封锁原理。

GFW 在哪

很多人可能想当然：GFW 当然部署在出口网关上，这样就能直接抓到全部出口流量进行审查了。但事实上，据 gfwrev.blogspot.com 考证，GFW“在三个国际出口作旁路监听”，通过分光的方式将所有出入境的 IP 包复制到 GFW 集群上以进行审查。推测的 GFW 网络拓扑如下（图源 gfwrev.blogspot.com）：

gfw topology

GFW 希望对不同线路的链路异构性进行耦合，并研究了多种链路的耦合技术（来源：高速网络环境下入侵检测系统结构研究）。根据《国际通信出入口局管理办法》，几大 ISP 在公用国际光缆处汇合，而安管中心（CNNISC）有独立的交换中心，各 ISP 分别接入其交换中心。为了适应不同 ISP 的链路规格，GFW 的交换中心需要对不同链路进行整合，不同 ISP 分别引出旁路接入 GFW。接入的线路主要是光纤线路，所以称为“旁路分光”。实验发现，GFW 的接入地点不一定紧靠最后一跳，所以图中以虚线表示。

关于这些有一篇更严谨的研究论文：Internet Censorship in China: Where Does the Filtering Occur?

早期（2010 年）研究认为，GFW 工程伪装成“虚拟计算环境实验床”计划实施

“虚拟计算环境实验床”是由国家计算机网络应急技术处理协调中心（CNCERT/CC）和哈尔滨工业大学（HIT）协作建设，以国家计算机网络应急技术处理协调中心遍布全国 31 个省份的网络基础设施及计算资源为基础，对分布自治资源进行集成和综合利用，构建起的一个开放、安全、动态、可控的大规模虚拟计算环境实验平台，研究并验证虚拟计算环境聚合与协同机理。

从“虚拟计算环境试验床”公开的论文：计算网格环境下基于多址协同的作业级任务调度算法来看，2005 年该平台的配置如下：

| 站点 | 地理位置 | 机型 | 节点数 | 每节点处理器 | 每节点主存 | | ---- | ---- | ---- | ---- | ---- | ---- | |CNCERT/CC|北京 | 曙光 4000L|128 节点|2Xeon 2.4G|RAM2G| |HIT|哈尔滨 | 曙光服务器|32 节点|2Xeon 2.4G|RAM2G| |CNCERT/CC|上海|Beowulf 集群|64 节点|2*AMD|Athlon 1.5G|RAM2G|

当然，如此配置仅是 2005 年的配置，目前 GFW 的软硬件配置已难以考证。

数据处理

GFW 在获取到 IP 包后，需要决定是否允许你与服务器之间的通信继续。它不能过于激进，因为全国性地阻断访问国外网站违背其存在价值。GFW 在理解 IP 包的含义后，才决定是否安全地阻断你与国外服务器的连接。GFW 首先需要进行重建，分析其中的 TCP 协议，以最终重建出一个完整的字节流，供后续在这个重建的字节流上分析具体的应用协议，比如 HTTP 协议。然后在应用协议中查找是否存在不和谐的内容，然后决定采用何种应对方式。

为了简化讨论，假设有如下三个 TCP 包：

IP 包 1：包含 TCP 包：包含的数据：Get /inde
IP 包 2：包含 TCP 包：包含的数据：x.html H
IP 包 1：包含 TCP 包：包含的数据：TTP/1.1

重建需要做的事情就是把 IP 包 1 中的 GET /inde 和 IP 包 2 中的 x.html H 和 IP 包 3 中的 TTP/1.1 拼到一起变成 GET /index.html HTTP/1.1。拼出来的数据可能是纯文本的，也可能是二进制加密的协议内容。具体是什么是你和服务器之间约定好的。GFW 做为窃听者需要猜测才知道你们俩之间的交谈内容。对于 HTTP 协议就非常容易猜测了，因为 HTTP 的协议是标准化的，而且是未加密的。所以 GFW 可以在重建之后很容易的知道，你使用了 HTTP 协议，访问的是什么网站。

重建这样的字节流有一个难点是如何处理巨大的流量？这个问题在这篇博客中已经讲得很明白了。其原理与网站的负载均衡器一样。对于给定的来源和目标，使用一个 HASH 算法取得一个节点值，然后把所有符合这个来源和目标的流量都往这个节点发。所以在一个节点上就可以重建一个 TCP 会话的单向字节流。

最后为了讨论完整，再提两点

虽然 GFW 的重建发生在旁路上是基于分光来实现的，但并不代表整个 GFW 的所有设备都在旁路。后面会提到有一些 GFW 应对形式必须是把一些 GFW 的设备部署在了主干路由上，比如对 Google 的 HTTPS 的间歇性丢包，也就是 GFW 是要参与部分 IP 的路由工作的。
重建是单向的 TCP 流，也就是 GFW 根本不在乎双向的对话内容，它只根据监听到的一个方向的内容然后做判断。但是监听本身是双向的，也就是无论是从国内发到国外，还是从国外发到国内，都会被重建然后加以分析。所以一个 TCP 连接对于 GFW 来说会被重建成两个字节流。

分析

分析是 GFW 在重建出字节流之后要做的第二步。对于重建来说，GFW 主要处理 IP 协议，以及上一层的 TCP 和 UDP 协议就可以了。但是对于分析来说，GFW 就需要理解各种各样的应用层的稀奇古怪的协议了。甚至，我们也可以自己发明新的协议。

总的来说，GFW 做协议分析有两个相似，但是不同的目的。第一个目的是防止不和谐内容的传播，比如说使用 Google 搜索了“不该”搜索的关键字。第二个目的是防止使用翻墙工具绕过 GFW 的审查。

对于 GFW 具体是怎么达到目的一，也就是防止不和谐内容传播的就牵涉到对 HTTP 协议和 DNS 协议等几个协议的明文审查。大体的做法是这样的：

1. 特征检测
2. 拆包
3. 关键词匹配

像 HTTP 这样的协议会有非常明显的特征供检测，所以第一步就没什么好说的了。当 GFW 发现了包是 HTTP 的包之后就会按照 HTTP 的协议规则拆包。这个拆包过程是 GFW 按照它对于协议的理解来做的。比如说，从 HTTP 的 GET 请求中取得请求的 URL。然后 GFW 拿到这个请求的 URL 去与关键字做匹配，比如查找 Twitter 是否在请求的 URL 中。为什么有拆包这个过程？首先，拆包之后可以更精确的打击，防止误杀。另外可能预先做拆包，比全文匹配更节省资源。其次，liruqi/jjproxy 的核心就是基于 GFW 的一个 HTTP 拆包的漏洞，当然这个 bug 已经被修复了。其原理就是 GFW 在拆解 HTTP 包的时候没有处理有多出来的 \r\n 这样的情况，但是你访问的 google.com 却可以正确处理额外的 \r\n 的情况。从这个例子中可以证明，GFW 还是先去理解协议，然后才做关键字匹配的。关键字匹配应该就是使用了一些高效的正则表达式算法，没有什么可以讨论的。

目前已知的 GFW 会做的协议分析如下：

DNS 协议

GFW 可以分析 53 端口的 UDP 协议的 DNS 查询。如果查询的域名匹配关键字则会被 DNS 劫持。可以肯定的是，这个匹配过程使用的是类似正则的机制，而不仅仅是一个黑名单，因为子域名实在太多了。证据是

2010 年 3 月，一名智利域名注册商的技术人员发现向位于中国的根服务器查询 facebook.com、youtube.com 和 twitter.com 等域名时的回复不正常。中国根服务器运营商 Netnod 于是暂时切断了其与国际互联网的连接。安全专家认为这与 Netnod 无关，而是中国政府修改某处网络时造成的。
2014 年 1 月 21 日下午三点半，中国互联网域名解析异常，大量网站被错误解析到 IP 地址 65.49.2.178，这个 IP 位于美国加利福尼亚州费利蒙市 Hurricane Electric 公司，被动态网公司租用于翻墙软件连接节点。动态网公司和研究人员认为这是因为防火长城的工作人员操作失误，另一些人认为，不能排除真正的黑客借这一 IP 地址作为跳板发动攻击的可能。
2015 年 1 月 2 日，污染方式有所改变，防火长城不再注入固定、被封锁 IP 地址，而是境外真实网站的、可访问的地址，这导致了境外服务器遭受来自中国的 DDoS 攻击，部分网站因此屏蔽中国 IP。该年 4 月，CNCERT 发表声明称，劫持是境外攻击所致。

来源：https://zh.wikipedia.org/wiki/%E9%98%B2%E7%81%AB%E9%95%BF%E5%9F%8E

HTTP 协议

GFW 可以识别出 HTTP 协议，并且检查 GET 的 URL 与 HOST。如果匹配了关键字则会触发 TCP RST 阻断。

TLS 协议

早期 TLS 版本中，服务器握手响应，包括证书，是未被加密的，GFW 可以嗅探它而得知访问站点，自 TLS 1.3 开始，ServerHello 之后的握手信息，包括站点证书，也会被加密后传输，一般可以认为能防止对证书信息的检测

然而现在普遍使用的 SNI 协议是 TLS 的一个扩展协议，在该协议下客户端在握手过程开始时告诉服务器其连接的域名，以便运作多个 HTTPS 网站的服务器选择并提供对应证书，而该扩展也未被加密。GFW 当前也会嗅探 SNI 握手阶段的明文域名以进行阻断。由于 HTTPS 即 HTTP + TLS，对 HTTPS 连接的检测仍可以归类为对 HTTP 的检测。

注意：由于 GFW 无法获取目标域名的证书，GFW 仍然无法解密实际的 HTTPS 内容

流量特征识别

GFW 的第二个目的是封杀翻墙软件。为了达到这个目的 GFW 采取的手段更加暴力。原因简单，对于 HTTP 协议的封杀如果做不好会影响互联网的正常运作，GFW 与互联网是共生的关系，它不会做威胁自己存在的事情。但是对于 TOR 这样的几乎纯粹是为翻墙而存在的协议，只要检测出来就是格杀勿论的了。GFW 具体是如何封杀各种翻墙协议的，我也不是很清楚，事态仍然在不断更新中。但是举两个例子来证明 GFW 的高超技术。

第一个例子是 GFW 对 TOR 的自动封杀，体现了 GFW 尽最大努力去理解协议本身。根据这篇博客 https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors。使用中国的 IP 去连接一个美国的 TOR 网桥，会被 GFW 发现。然后 GFW 回头（15 分钟之后）会亲自假装成客户端，用 TOR 的协议去连接那个网桥。如果确认是 TOR 的网桥，则会封当时的那个端口。换了端口之后，可以用一段时间，然后又会被封。这表现出了 GFW 对于协议的高超检测能力，可以从国际出口的流量中敏锐地发现你连接的 TOR 网桥。据 TOR 的同志说是因为 TOR 协议中的握手过程具有太明显的特征了。另外一点就表现了 GFW 的不辞辛劳，居然会自己伪装成客户端过去连连看。

第二个例子表现了 GFW 根本不在乎加密的流量中的具体内容是不是有敏感词。只要疑似翻墙，特别是提供商业翻墙服务，就会被封杀。（几乎可以确定）GFW 已经升级为能够机器识别出哪些加密的流量是疑似翻墙服务的。

GFW 显然近期的工作重心在分析网络流量上，从中识别出哪些是翻墙的流量。这方面的研究还比较少，而且一个显著的特征是自己用没关系，大规模部署就容易出问题。

干扰措施

GFW 通过协议分析，确定你这个字节流是“具有威胁的”，就会通过以下几种方式来干扰继续通信：

IP 封锁

一般常见于人工检测之后的应对。还没有听说有什么方式可以直接使得 GFW 的机器检测直接封 IP。一般常见的现象是 GFW 机器检测，然后用 TCP RST 重置来应对。过了一段时间才会被封 IP，而且没有明显的时间规律。所以我的推测是，全局性的封 IP 应该是一种需要人工介入的。注意我强调了全局性的封 IP，与之相对的是部分封 IP，比如只对你访问那个 IP 封个 3 分钟，但是别人还是可以访问这样的。这是一种完全不同的封锁方式，虽然现象差不多，都是 ping 也 ping 不通。要观摩的话 ping twitter.com 就可以了，都封了好久了。

其实现方式是把无效的路由黑洞加入到主干路由器的路由表中，然后让这些主干网上的路由器去帮 GFW 把到指定 IP 的包给丢弃掉。路由器的路由表是动态更新的，使用的协议是 BGP 协议。GFW 只需要维护一个被封的 IP 列表，然后用 BGP 协议广播出去就好了。然后国内主干网上的路由器都好像变成了 GFW 的一份子那样，成为了帮凶。

如果我们使用 traceroute 去检查这种被全局封锁的 IP 就可以发现，IP 包还没有到 GFW 所在的国际出口就已经被电信或者联通的路由器给丢弃了。这就是 BGP 广播的作用了。

DNS 劫持

这也是一种常见的人工检测之后的应对。人工发现一个不和谐网站，然后就把这个网站的域名给加到劫持列表中。其原理是基于 DNS 与 IP 协议的弱点，DNS 与 IP 这两个协议都不验证服务器的权威性，而且 DNS 客户端会盲目地相信第一个收到的答案。所以你去查询 facebook.com 的话，GFW 只要在正确的答案被返回之前抢答了，然后伪装成你查询的 DNS 服务器向你发错误的答案就可以了。

TCP 连接重置

TCP 协议规定，只要看到 RST 包，连接立马被中断。从浏览器里来看就是连接已经被重置。我想对于这个错误大家都不陌生。据我个人观感，这种封锁方式是 GFW 目前的主要应对手段。大部分的 RST 是条件触发的，比如 URL 中包含某些关键字。目前享受这种待遇的网站就多得去了，著名的有 facebook。还有一些网站，会被无条件 RST。也就是针对特定的 IP 和端口，无论包的内容就会触发 RST。比较著名的例子是 https 的 wikipedia。GFW 在 TCP 层的应对是利用了 IPv4 协议的弱点，也就是只要你在网络上，就假装成任何人发包。所以 GFW 可以很轻易地让你相信 RST 确实是 Google 发的，而让 Google 相信 RST 是你发的。

端口封锁

GFW 除了自身主体是挂在骨干路由器旁路上的入侵检测设备，利用分光技术从这个骨干路由器抓包下来做入侵检测 (所谓 IDS)，除此之外这个路由器还会被用来封端口 (所谓 IPS)。GFW 在检测到入侵之后可以不仅仅可以用 TCP RST 阻断当前这个连接，而且利用骨干路由器还可以对指定的 IP 或者端口进行从封端口到封 IP，设置选择性丢包的各种封禁措施。可以理解为骨干路由器上具有了类似“iptables”的能力（网络层和传输层的实时拆包，匹配规则的能力）。这个 iptables 的能力在 CISCO 路由器上叫做 ACL Based Forwarding (ABF)。而且规则的部署是全国同步的，一台路由器封了你的端口，全国的挂了 GFW 的骨干路由器都会封。一般这种封端口都是针对翻墙服务器的，如果检测到服务器是用 SSH 或者 VPN 等方式提供翻墙服务。GFW 会在全国的出口骨干路由上部署这样的一条 ACL 规则，来封你这个服务器 + 端口的下行数据包。也就是如果包是从国外发向国内的，而且 src（源 ip）是被封的服务器 ip，sport（源端口）是被封的端口，那么这个包就会被过滤掉。这样部署的规则的特点是，上行的数据包是可以被服务器收到的，而下行的数据包会被过滤掉。

如果被封端口之后服务器采取更换端口的应对措施，很快会再次被封。而且多次尝试之后会被封 IP。初步推断是，封端口不是 GFW 的自动应对行为，而是采取黑名单加人工过滤地方式实现的。一个推断的理由就是网友报道，封端口都是发生在白天工作时间。

反向墙

大部分机场使用的国内中转服务器，GFW 检测到了十分异常的境外大流量，就会在特殊时期，如两会和国庆期间，将该服务器反向墙。具体表现为国外的服务器无法访问该被反向墙了的 IP。ping 该国内服务器就是国外一片红，国内一片绿。解决方法不多，要么更换 IP，或者等敏感时期过去，自动恢复。

本文转载编辑补充自

https://ednovas.xyz/2022/06/25/gfw/#%E4%B8%AD%E8%BD%AC

https://gfwrev.blogspot.com/2010/02/gfw.html

2024 学习计划

Wed, 03 Jan 2024 18:06:51 GMT

2024年的学习计划明确而具体，目标包括日语达到N2水平，完成SICP和TAPL的学习，深入操作系统的知识以实现一个完整的POSIX内核，同时也计划更新博客主题。这些目标不仅具挑战性，也为个人成长和技能提升提供了清晰的方向。

RISC-V 工具链与模拟器（emulator）的安装

Wed, 24 May 2023 09:51:09 GMT

闲的无聊看看 spike 源码，但是翻了很多教程都没有可以直接安装好 spike 和相关的工具链。于是自己动手丰衣足食，直接读相关仓库的 README，基本都可以安装成功，但是还是暗藏着一个小坑，记录一下。

工具链（riscv-gnu-toolchain）的安装

RISC-V 工具链包括 gcc、gdb、objdump/copy 和相关的标准库实现等，建议首先安装。

仓库地址：https://github.com/riscv-collab/riscv-gnu-toolchain

clone 时建议加上 --depth=1 参数缩小 clone 体积，后面几个仓库的 clone 也建议加此参数。

前置的依赖安装可见 README 中的 Prerequisites 一节，当前 Debian 系下为：

sudo apt install autoconf automake autotools-dev curl python3 libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc zlib1g-dev libexpat-dev ninja-build

clone 后按照工具链中的 Installation (Newlib) 一节基本可以安装成功，但是有坑点：

使用此方式编译的 gcc 无法编译 riscv-pk，会报 extension `zifencei' required 的错误，推测是因为默认的编译参数并不支持 zifencei 扩展（即 FENCE.I 指令）

可用的编译参数如下：

./configure --prefix=/opt/riscv --with-arch=rv64gc
make

建议首先在 /opt 下建立 riscv 文件夹，并保证 riscv 文件夹的所有人为普通用户自己。如非则需要 chown：

sudo chown 1000:1000 /opt/riscv

这里假设 uid 和 gid 皆为 1000，具体可以通过 id 命令查看。

安装完成后需要将 /opt/riscv/bin 加入 Path，具体方式可 Google 可 ChatGPT。后续安装的内容也都会放入 /opt/riscv 中。完成后 riscv64-unknown-elf-gcc 应当可用。

模拟器（spike）的安装

仓库地址：https://github.com/riscv-software-src/riscv-isa-sim

clone 下来后按照 README 中的 Build Steps 一节直接安装即可，并无坑点。当前命令：

$ sudo apt install device-tree-compiler
$ mkdir build
$ cd build
$ ../configure --prefix=/opt/riscv
$ make
$ make install

安装完成后 spike 命令应可用

模拟内核（riscv-pk）的安装

仓库地址：https://github.com/riscv-software-src/riscv-pk

pk 即 Proxy Kernel，用来直接运行静态链接的用户态 RISCV 程序，毕竟只要验证的话，再跑一个操作系统太重了。

clone 下来后按照 README 中的 Build Steps 直接安装即可。坑点仅限于工具链一节提到的 FENCE.I 指令。当前命令：

$ mkdir build
$ cd build
$ ../configure --prefix=/opt/riscv --host=riscv64-unknown-elf
$ make
$ make install

验证

验证使用了 spike 中的例子。新建 hello.c，内容如下：

#include <stdio.h>

void main()
{
    const char *s = "Hello.\n";
    while (*s) putchar(*s++);
    while(1);
}

编译该文件：

$ riscv64-unknown-elf-gcc -o hello hello.c

通过 spike 运行：

spike pk hello

可以看到终端输入了 Hello.，按多次 ctrl+c 可退出。

漫谈编程语言

Sat, 08 Apr 2023 05:16:36 GMT

本文通过讨论如何设计一门编程语言的方式，来普及编程语言理论中的一些基础概念、实现思路和现状。

我来设计编程语言……吗？

现在由我们来设计一门全新的编程语言：C--。

对，就是我们自己设计。

我们先抛下一些编译原理、编译器和解释器的实现等一些复杂的东西，不会去讨论一些特性的具体实现（看看标题：漫谈！）。

我们来自底向上建设这门属于我们自己的编程语言。

最底层我们直接假设好了，我们这门编程语言的最终编译产物是 RISC-VI 格式，有一个 RISC-VI 指令集与之对应。这个汇编语言十分基础，只能对内存和寄存器进行一些简单的操作。

代码在哪里跑？

这个问题其实应该是 RISC-VI 指令集或者架构的问题，和我们要设计的高级语言特性似乎没有关系。但这其实关系到了你的代码处于计算机系统的哪一层，这是编程语言设计者首先就必须要考虑的问题：

计算机系统的本质，就是分层的虚拟机

在这个系统的分层虚拟机模型中，上层会包装和屏蔽下层的操作接口，并增加了自身的特性，以供更上一层使用。

操作系统就是一层对于硬件（裸机）的虚拟，例如你的计算机是 x86 指令集架构，当你将你写的 C 语言小程序编译到二进制后运行时，操作系统是需要首先解析这个二进制文件的格式，如果你是 Linux 操作系统，那这个可执行文件的格式就是 elf 格式。按照 elf 格式解析完成后，操作系统会将文件中的各个段加载到内存中，并跳转到代码段的第一个指令开始执行。当然实际不会这么简单，真正的操作系统还会更精细地管理内存资源，并通过进程等方式隔离运行中的不同任务。

很巧合的是（？），C 语言编译的二进制文件，不仅仅可以在操作系统这一层执行，其实也是可以在裸机上运行的。一个很典型的例子就是，Linux 内核大部分就是由 C 语言写出来的（最近主线中合入了 rust 代码，未来可期）。在系统编程这个层面，C 程序主要使用的是操作系统提供的系统调用。例如，在 x86 的 linux 下，程序需要将文件中的数据读入内存时，通常调用 sys_read 这个系统调用。在收到这个系统调用后，linux 会代你从文件中读取，当然也少不了前置的权限校验等工作。然而，如果你要使用 C 编写一个操作系统，当然就没有系统调用给你使用了，甚至连文件这个概念都是操作系统抽象出来的。这时你不得不通过某种方式直接和硬盘驱动交互，通过修改硬盘控制器中一些寄存器，来达到读取某个位置的一些数据这一简单的目的。

通过这样的描述，可以看出操作系统完美符合上述的虚拟机的定义。甚至可以说，Linux 就是一个用于执行 elf 文件的虚拟机（当然它还干了更多）。如果不考虑操作系统提供给 C 语言的标准库，C 语言是运行在裸机这一层语言（其实是 C 语言的编译产出运行在这一层，不过先这么说着吧）。

我们来看另一个🌰：Python。Python 是一个典型的解释型语言。它的官方解释器是 CPython，这是一个用 C 语言编写的 Python 解释器。套用上面的分层模型，那就是 CPython 是基于操作系统的一个虚拟机：它包装了操作系统提供的接口，供上层的 Python 程序去调用。

当然，极端一点，即使是 C 语言这种编译型语言，也可以勉强看作是解释型语言：CPU 确实是一条一条读取指令、解析执行的，只是这些指令是二进制的。而 Python 作为解释型语言，它的指令是可读的，CPython 的输入是人类可读的字符串。

解释型语言的一个巨大的好处，就是可移植性强。解释器屏蔽了不同操作系统的底层差异，向高级语言这一层提供了相同的 API，这样你写的代码，就可以一次编写，处处执行了。当然，根据苦难守恒定律，你是轻松了，苦的是写解释器的人。不过，即使是一门编译型语言，编译器也不得不根据不同的指令集架构去分别实现，看起来也没苦到哪去～

既然提到了处处执行，就不得不讲一下最著名的一次编译，处处执行：Java！Java 将编译和解释结合到了一起。JVM 就相当于 Python 中的 CPython，是 Java 语言的一个运行时（Runtime）。java 文件首先需要编译成 class 文件，JVM 读入的文件格式，就是 class 文件格式。这个文件也是一个二进制文件，但是其格式在不同指令集架构的操作系统上是相同的。这就是为什么，我在 x86 下编译的 class 文件，放到 RISC-V 上的 JVM 中也可以执行。JVM 在读入 class 文件后，还是会像解释器一样，一条一条加载指令解析执行。所以很难去界定 Java 究竟是一门编译型语言还是解释型语言。

JVM 是一个很成功的虚拟机（计算机系统层面），它不仅支持了 Java 语言在其上运行，还支持了许多其他语言，如 Scala 和 Groovy。当然这基于一个重要的事实：这些语言都可以编译到 class 格式。

我们普遍认为：解释型语言的执行效率较低，而编译型语言的执行效率比较高。然而随着编程语言的发展，许多解释型语言都加入了一些语言特性来提升运行效率。以 Java 为例，在 JVM 解释执行 class 文件的阶段，JVM 会动态分析热点代码，将热点代码直接编译为机器语言。再次执行到热点代码时就不会再次解释，而是直接执行已经编译好的机器语言了。这个技术被称为 JIT（Just-in-time compilation，即使编译）。类似的，Python 也有 numba 这个库用于加速执行，也是使用了 JIT 技术。

当然，如果你写出了一个 C 语言的解释器，你也可以说 C 语言是解释型语言（

类型系统

现在我们确定下来了 C-- 的运行位置，但我们的 C-- 还是非常简陋，甚至根本不存在：

如果是走编译型语言的路子，RISC-VI 是一个指令集架构，一般和高级语言无关
如果走解释型语言的路子，RISC-VI 以及对应的解释器可能是由我们设计和实现的

RISC-VI 是一个只能操作内存和寄存器的汇编语言，内存区域和寄存器在它眼中，只是一些无意义的字节数组，你可以操作任何一个字节（在下层虚拟机允许的范围内）

我们假设现在我们的语言没有类型系统，所有的操作都是直接处理字节数组。如果是在 C 语言中，相当于不定义任何类型，直接使用 void * 指针，去操作所有的字节。能使用的操作只有取地址和解引用，以及对字节赋值和取值，那和直接写汇编语言都没啥区别！我们在堆上创建一个四字节整数并赋值为 1 的方法就像下面一样（当然用的是 C 语法，实际上没有类型系统真的和汇编一样）：

void *intBytes = malloc(4);    // 堆上分配四字节
*(intBytes+3) = 0x01;          // 假设大端序，偏移为 3 处设置为 1

我们熟知的，int、float 啥啥啥，都去哪了？那就是类型系统的工作了。

类型的本质是对一块内存区域的解释方式

类型系统将无序的堆栈空间划分为有实际意义的块，根据类型的不同赋予它们不同的解释方式。当然对于程序员来说，不同的类型最直观的差异在于定义类型时语法的不同。比如在 C 语言中，int 通常用于表示四字节整形，而 double 则表示符合 IEEE 754 规范的双精度浮点型。类型将影响编译器生成的运行时对这段字节的操作方式。

有了类型系统后，上面的创建四字节整数的方法就变成了这样：

int *intBytes = (int *)malloc(4);
*intBytes = 1;

由于我们声明了 intBytes 是一个 int 类型的指针，指向的那片内存区域应当按照整型变量去解析。于是第二行我们可以直接给 intBytes 赋值为 1，而不需要担心这个 1 会被赋值给第 0 个字节而非第 3 个。编译器在得知 intBytes 是一个 int 类型的指针时，对其的一切操作都会按照 int 类型的操作加以定制。生成的最终的机器代码其实还是将第三个字节置为 1，但是这是编译器帮我们实现的，我们只管操作各种类型即可。

有一个有趣的点，就是 C 语言在编译期优化了指针变量的偏移计算，例如上述的例子：intBytes+1 这个地址实际上代表了 intBytes 指向的地址 +4，因为 int 类型占用四个字节。这也是 C 语言借此实现数组的重要依据。

类型系统是一个编译期特性（对于 C 语言来说）

同样我们定义的结构体，本质上也是用于指导编译器操作内存的，例如如下的结构体：

typedef exampleStruct struct {
	int a;
	int b;
}

这个结构体中有两个 int 变量，占用内存 8 字节。那么当我们定义一个 exampleStruct 类型的指针 esp，指向一片内存区域时，实际上就是认为这个地址及其后 8 字节的区域按照 exampleStruct 的结构去解析。当我们使用 esp.b 或者 esp->b 去操作这里的 int b 时，实际上就是在按照 int 的方式操作 esp 指向地址之后的第四到第七个字节。

所以可以这么说，结构体中定义的变量，在运行时只用于指示这个变量的地址相对于结构体起始位置的偏移。

至于不使用指针的方式，直接在函数中使用 exampleStruct esp; 声明一个结构体，则属于编译器对于栈上变量分配的特殊处理，甚至可以理解为语法糖。因为你：

不需要手动初始化这个结构体，声明一下就能用，实际上编译器在编译时就决定了这个结构体在栈帧的位置
不需要管理这个结构体的生命周期，函数结束自动释放，当然释放的方式就是栈指针上移（栈向下生长），不会覆写这片内存

当然栈上分配的坏处也不用多说，它的第二点好处就是坏处，函数返回后会自动释放，就没法在函数之外去使用了。

相对于 C 来说，Java 的类型系统就十分局限：类型信息被直接写进了对象所在的内存中，强制类型转换也只能在类型树的父子节点之间进行。

传值还是传引用？

一个经常被讨论的、同时也是经常会犯错的点，就是函数的传参，到底是传值还是传引用。

究其本质，可以认为所有的函数传参都是传值，所谓的传引用，本质上也是基于传值做的优化。

C 语言自不必多说，无论是基于寄存器传参还是基于栈传参，都是要将原内容复制一份或者将原内容备份一份，保证在新函数返回后这部分内容不会发生变化。如果传递的是个指针，可以去除其指针的属性来看，本质上只是传递了一串数字（根据指令集架构可能是 32 位或 64 位），同你将这个地址赋值给一个 long 变量后传递的结果是一样的。

传引用这种说法，主要出现在 Java 中。引用本质上是一种对象句柄，程序可以通过句柄访问对象的部分信息。句柄不代表对象的内存地址，但是在实现上一定包含了对象的实际内存地址。当传递一个引用到函数或方法中时，可以看作传递的是一个包含对象实际地址的结构体，和 C 语言的传递指针类似，所以行为类似。

然而 Java 中还包含了 8 种基本数据类型，这 8 种基本数据类型又有其对应的包装类，在实现上显得很不统一，据说是早期为了吸引 C++ 程序员迁移的一种举措，属实失了优雅。

数组是什么？

在拥有了基础的类型系统后，下面就需要考虑一种特殊但是很常见的复合数据类型：数组。但是，数组是什么，以及数组真的存在吗？

C 语言在运行时实际上是没有数组的，数组成了一个编译期语法糖。C 基于指针实现了数组。数组名实际上也是指向数组第零个元素的地址，即当我声明 int a[10] 时，a 在使用时等同于 &a[0]。而数组的下标运算（方括号），也是基于类型指针的偏移实现的。当使用 a[1] 获取数组中的第一个元素时，可以认为等同于 *(a+1)，更具体的：

int b = a[0];

// 等同于
void *p = (void *)a;
p += 4;
int b = *((int *)p);

由于数组的实现是基于特定类型指针的，且可以和对应类型的指针任意转换，所以实际上对于数组越界，在语言层面是没有任何检查的。例如我在栈上定义了一个长度为 10 的数组，那么我去读取和写入第 11 个元素有时是没有问题的。

有人会说不对不对，数组越界会出现段错误 segment fault。这实际上不是 C 语言在检查，而是在读取和写入超限内存时，可能读取到了不可读的内存、写入了不可写的内存，引起了操作系统的报错。这不属于语言层面的错误。

在 C 语言中，C 语言向参数传递数组有三种方式：传递指针、传递已定义大小的数组和传递未定义大小的数组，分别如下：

void func(int *array);
void func(int array[10]);
void func(int array[]);

值的一提的是，在使用这三种方式传参时，第一种和第三种，在 func 中都没有办法通过 len 获取原数组的长度，第二种获取的长度永久为 10，即使实参并不是一个长度为 10 的数组。这足以说明，数组的长度信息，是写在其类型定义中的，当由于传参等方式导致类型的变化，会导致长度信息的丢失。这更贴合了数组本质是由指针来实现的这一说法：实际的存储内存中，除了连续的各个元素外，就没有其他信息了。

与之相对的，Java 是有真正的数组的。Java 中每个数组都是一个对象，数组的相关信息，如基本类型和长度等，都写在对象头中。所以 Java 可以在运行时检查数组是否超限访问，并抛出 IndexOutOfBoundsException。

面向过程还是面向对象？

实际上，这说不上是一个问题，广义上来说，面向对象和面向过程更多的是一种编程思想和范式而非具体的编程语言的差别。C 语言同样可以通过定义结构体来实现面向对象的编程。

那么可以狭义定义一下面向过程和面向对象：只有原生支持、完整实现了面向对象的三大特性的语言（封装、继承和多态），才可以称为面向对象的编程语言。

封装自然不必多说，简单的封装连 C 语言都可以做得到：包装成一个结构体就可以了。然而，封装的一个重要的目的：“对象的内部实现细节被隐藏起来，外部只能通过对象提供的接口来访问和操作对象的数据。”，对于 C 语言的结构体，是没有访问控制的，内部的字段也可以被任意修改，这种封装实质上是没有意义的。至于 Java、CPP 和 C 的一个语法上很大的区别：可以直接通过 . 运算调用对象（结构体）的成员方法，在实现上实际上并没有什么特殊的：在底层实现上，成员方法就是第一个参数为对象指针的函数，编译器自动将对象指针添加到函数参数中并命名为 this 指针，除此以外成员方法和一般函数并无不同。

在实现上，Java、C++ 和 Golang 有异曲同工之妙：它们都通过直接或者间接的方式，通过组合来实现了继承。由于需要使用的是组合，所以在自定义构造方法时，都需要首先调用父类的构造方法。golang 的继承中组合的意味最为明显：直接在结构体中定义一个无名的父类结构，这使得访问父类的变量本质上就是直接访问这个父类对象的变量，而使得更像是一个语法糖了：

type Parent struct {
	a int64
}

type Child struct {
	Parent
	b int64
}

c := &Child{Parent{}, 0}
a := c.a
//或者
a := c.Parent.a;

相对于 Java 和 C++，Golang 的继承更像是过家家，并没有规定子类对父类变量的访问控制，而是直接沿用了通过首字母大小写来决定是否包导出的方法，缺乏像 Java 一般的 protected 来具体控制子访问父的场景。

多态这一特性，一个典型的表现就是：父指针指向不同子类对象时，调用其共有的函数，不同的子类会有不同的行为。Java 和 C++ 以两种典型的方式实现了多态。Java 由于包含一个运行时（JVM），使得它在实现多态时非常容易：虽然使用的是父类型的对象句柄去调用的方法，但是由于可以根据对象句柄定位到对象的具体信息，包含各种类型和方法信息，调用具体的实现方法也就变得比较容易，所以说 Java 的多态是一种运行时多态。而 C++ 则是一种编译期多态。C++ 中，每个类包含了一个虚函数表，对象在实例化时会包含指向自己的虚函数表的指针，虚函数即可能会由于继承而被重写的方法的列表。编译器保证如果子类和父类同时实现了一个方法，那么这个方法在父类和子类的虚函数表中位于同一个位置。这样，对于一个可能被继承的方法的调用，都变成了类似于“调用虚函数表中第 N 个函数”这样的指令。在通过父类指针调用方法时，实际上找到的是子类对象虚函数表中的函数指针，从而实现了调用子类的函数实现，实现了多态。

泛型的实现

泛型，得益于 idea 的智能提示，基本算是最广为使用的高级语言特性了。然而，Java 直到 JDK 5 才实现了泛型编程，而 C++ 则更是在 C++11 标准中才引入模板编程（泛型的一种实现方法），算是个很新的特性。很有趣的是，这两种实现恰好代表了两种截然不同的泛型实现方式。

以 Java 为例，泛型是一个编译期实现，在运行时则是无感的，即所谓的类型擦除。所以 Java 的泛型只用于编译期的类型检查：检查你所传入的对象或者类型是否符合泛型参数中规定的类型。如果你通过某种方式绕过了编译期的泛型检查：例如手动构造了一个 class 文件，或者干脆就是运行时通过反射等方式，那么 JVM 对此是无能为力的。例如，你声明了一个 List<String> 的列表，常规写代码只能 List 内塞入 String 类型的变量。但由于类型擦除的特性，在运行时它本质上只是个 List，或者叫 List<Object> 也可以，那如果在运行时通过某种方式塞进去一个 Integer，JVM 是不会报错的。

C++ 中，泛型是通过代码生成来实现的，所以 C++ 中泛型的实现被称为模板。编译器会检查模板类的每一个实例化的位置都涉及了哪些模板参数，针对每一种模板参数，生成这套模板参数对应的每一个定义在泛型类中的方法。例如，如果我定义了一个 ClassName< typename T > 的模板类，其中包含了一个 Test(T t) 方法，并在下面通过 ClassName<int> testObj 根据这个模板创建了一个对象。那么在编译产出中，其实是真实存在 Test(int t) 这个方法的。和 Java 一样，运行时也是无法感知泛型的存在的，根据模板生成的类和方法，同手动定义的无异。但是这种方式实现泛型，相对于 Java 无疑更加安全。由于使用的不是类型擦除而是代码生成，不会出现像 Java 一样只要绕过编译就完全没有检查的现象。

C++ 的泛型有一个缺点，就是通过模板生成的最终实现类必须是完整的，所以即使不包含模板参数的函数，也会被重复生成。即使它们的代码都相同。这样就可能会造成比较大的空间浪费。C# 在实现泛型时，针对这一点进行了优化，C# 不会在编译期直接生成最终的模板代码，而是统计出这个模板类有多少种不同的实现，.Net 运行时（CLR，类似于 JVM）的 JIT 编译期会为这个模板生成一份共享的机器码，而类型特化的信息存在一个额外的表里面由每个实例化泛型类型自己存储，这样就可以共享大部分代码了。具体可见这篇论文。不过这也怪不得 C++，C# 有一个运行时，除非 C++ 也有一个自己的运行时，或者将运行时编译到结果产物中，否则是很难实现这种动态共享的。

尾声

当你定好了上面的内容，你就差不多确定了你的编程语言的大致样貌，甚至你还没确定它的语法！剩余的就是一些非常通用、按部就班的内容：去实现它！

当然，你可以尽情地给你的语言添加一些高级特性：例如 gc、例如特殊的生命周期管理。拥有一个 VM 会让高级特性的实现轻松很多，但不是必须的：例如 golang 在实现 gc 时，直接将 gc 相关的代码编译进最终的产物中，相当于你的每一个编译产物都带了一个小小的 VM。

当然，大部分人并需要自己实现编程语言，但是了解这些编程语言之间的一些共性和特性仍然是必要的。世界上没有最好的编程语言，只有某个场景下最适合的编程语言。所以那些最佳编程语言之争，就显得非常可笑：每个编程语言的出现，必然是为了解决某个问题而来。如果有这样一门新编程语言，除了语法之外，和另一门已经存在的编程语言在特性上没有任何不同，那这门新语言是难以长久的：如果不能解决新问题，为什么要费心思学新语言呢？

当然，了解这些特性，还是有一些意想不到的好处的。比如程序员间喝酒吹牛、或者一些技术群中又在争论最好的语言时（当然是有理有据的争论），你就可以高谈阔论了。

一次失败的项目实践——春节七天乐（不起来）

Thu, 02 Feb 2023 15:24:55 GMT

缘起

最初是在过年回家的高铁上，在知乎上看到了这篇文章：将 Go 程序跑在裸机上，大致想法是通过实现一遍系统接口，来接管 golang 程序的各种系统调用和中断之类的。感觉这个想法十分有趣。作者还用 golang 写了一个 x86 os：eggos，完成度相当之高。由于是从底层魔改了 golang 的运行时，用户程序完全无感知，所以各种 golang 的第三方库都可以直接使用。作者甚至实现了一个支持 TCP/IP 的协议栈，使得一些网络库可以直接使用。看的我心潮澎湃。

搜了搜一些前人的工作，发现这个想法很早就被人提出来过。2018 年 OSDI 会议上就有一篇论文，讲述了使用高级语言实现操作系统的好处和代价，幻灯片在这儿。另外，相关的实现这几年也是有的，比如 gopher-os，一个验证性质的内核，只是为了证明使用 golang 实现操作系统是可行的。另外还有 MIT 的一个博士论文项目 Buscuit，思路是 hack 编译器使得能够编译到裸机，这个项目完成度更高，实现了部分 POSIX 接口，甚至可以在上面跑 redis 和 nginx。

在研究资料过程中，发现了一个共同点：都是基于 x86 架构实现的。我之前用 c 写过一个小内核，是基于 RISC-V 架构，RISC-V 的汇编和各种机制都十分简单，写起来也很舒服。于是就有了这么个想法：用 go 实现一个 RISC-V 的操作系统。

说干就干！到家第二天就开始搞起来了。

就是干！

做一个项目，很重要的一点，就是起名字（bushi

但我确实首先想到了一个绝妙的名字：goose

README

太妙了兄弟们！

首先 go 是原生支持交叉编译到 RISC-V 64 位的可执行文件的，这是好事。只需要在 go build 命令之前加上 GOOS=linux GOARCH=riscv64 即可，非常方便。

虚拟机照例使用的是 qemu，平台还是 virt。virt 平台的内存布局：0x80000000 以上是物理内存区域，0x80000000 以下是 mmio 区域（大概就是把设备的内存映射到了这片区域，操作这块内存等同于操作这个设备）。virt 启动时会把 pc 设置为 0x80000000

然而正常编译的 go 可执行文件，由于运行在用户态虚拟地址上，entry 的地址都是低地址，大概 0x10000 左右。好在 go 提供了一个链接标志 -T 来指定 TEXT 段的起始地址，可以用这个标志把整个代码段放在高地址内存处，同时还可以通过 -E 来指定入口的标志，这样就可以写一个函数来接管 go 的启动过程（go 程序的入口不是 main 函数，而是 _entry 函数，这个函数用来做一些初始化工作）

然而还有一个严重的问题：我们指定了入口函数，但是没有办法指定这个函数的起始地址，就没法把这个函数放到 0x80000000 处，virt 在启动的时候，0x80000000 就可能是一堆啥也不知道的代码。通常，如果是 c，我们可以通过编写链接脚本来解决这个问题，而且非常简单：直接指定好入口标记的地址，一行就完事。可是这是 go。

在查了一些资料后，在 stackoverflow 上看到了这个提问，使用外部链接器而非 go 自己内置的链接器，这样就可以指定链接脚本了。但是尝试了下之后，不太可行。go 的可执行文件中除了一些已知的 text 段、bss 段、rodata 段和 data 段，还有一些自己的乱七八糟的段，这些都必须在链接脚本里显式指定，几乎不太可能。

于是更换思路，入口可以写一段 c 代码，这段 c 代码动态获取 go 代码的入口然后跳转过去。由于 go 代码的入口只存在于 elf 文件中，在加载后的内存映像中是没有这个信息的。所以可以把这个 elf 文件直接以二进制的形式链接到 c 程序的 data 段，可以为这段保存二进制的内存开始和结尾指定一个名字，我是用的是 _binary_kernel_elf_start 和 _binary_kernel_elf_end。这样在 c 代码中就可以快速找到了。而 c 代码的作用，就是解析这段内存中保存的 elf 文件，把需要载入内存的段复制到内存对应的地址处，再跳转到 elf 指定的 entry 处即可。

这里贴一下入口的汇编代码，大概就是设置好栈就跳转进 c 函数中，同时指定了 data 段中的两个符号间的一段内存是编译好的 go 可执行文件：

    .section .text.entry
    .globl _start
    # 仅仅是设置了 sp 就跳转到 main
_start:
    la sp, bootstacktop
    call bootmain

# 启动线程的内核栈 bootstack 放置在 bss 段的 stack 标记处
    .section .bss.stack
    .align 12
    .global bootstack
bootstack:
    # 以下 16K 字节的空间作为 OS 的启动栈
    .space 0x4000
    .global bootstacktop
bootstacktop:

    .section .data
    .globl _binary_kernel_elf_start
    .globl _binary_kernel_elf_end
_binary_kernel_elf_start:
    .incbin "kernel.elf"
_binary_kernel_elf_end:

C 函数 bootmain 也十分简单，解析 elf 文件，读取程序头表，把各个段都加载到需要的物理内存处：

void
bootmain()
{
    struct elfhdr *elf;
    struct proghdr *ph, *eph;
    void (*entry)(void);
    uchar *pa;
 
    elf = (struct elfhdr *)(_binary_kernel_elf_start);
 
    if (elf->magic != ELF_MAGIC)
        return;
 
    ph = (struct proghdr *)((uchar *)elf + elf->phoff);
    eph = ph + elf->phnum;
    for (; ph < eph; ph++)
    {
        pa = (uchar *)ph->paddr;
        readseg(pa, ph->filesz, ph->off);
        if (ph->memsz > ph->filesz)
            clearMem(pa + ph->filesz, ph->memsz - ph->filesz);
    }
 
    entry = (void (*)(void))(elf->entry);
    entry();

void
bootmain()
{
    struct elfhdr *elf;
    struct proghdr *ph, *eph;
    void (*entry)(void);
    uchar *pa;
 
    elf = (struct elfhdr *)(_binary_kernel_elf_start);
 
    if (elf->magic != ELF_MAGIC)
        return;
 
    ph = (struct proghdr *)((uchar *)elf + elf->phoff);
    eph = ph + elf->phnum;
    for (; ph < eph; ph++)
    {
        pa = (uchar *)ph->paddr;
        readseg(pa, ph->filesz, ph->off);
        if (ph->memsz > ph->filesz)
            clearMem(pa + ph->filesz, ph->memsz - ph->filesz);
    }
 
    entry = (void (*)(void))(elf->entry);
    entry();
}

最后 entry 的位置就是从 elf 头中读出来的 go 入口函数地址，跳转过去即可。

go 入口函数是 rt0 函数，是一个汇编函数。go 使用的汇编格式是 PLAN9 汇编，起源于一个上古操作系统 plan9。这个格式的汇编支持多个指令集架构，但是很神奇的是找不到任何官方的文档描述不同的指令集架构中这个格式的汇编支持哪些指令。x86 的还能找到点资料，因为 PLAN9 汇编的例子基本是 x86 的，RV64 则是一点痕迹都没有，完全靠猜（

通过各种摸索，最后终于写出了入口：

#include "textflag.h"

TEXT ·rt0(SB),NOSPLIT|NOFRAME,$0
    CALL ·kernelStackTop(SB)
    MOV  0(SP), A1
    MOV  A1, SP
    CALL ·kmain(SB)
    UNDEF
    RET

这个格式也蛮阴间的……做的事情基本一致，调用 kernelStackTop 获得预先分配好的栈顶地址，并把 SP 指针指向那个地址，随后就调用 go 语言的入口了：kmain。唯一的 go 文件写得也很简单：

type stack [16 * 4096]byte

type virtualAddress uintptr

var (
    kstack stack
)

//go:nosplit
func (s *stack) top() virtualAddress {
    stackTop := uintptr(unsafe.Pointer(&s[0])) + unsafe.Sizeof(*s)
    // Align to 16 bytes.
    stackTop = stackTop &^ 0xf
    return virtualAddress(stackTop)
}

//go:nosplit
func kernelStackTop() uint64 {
    return uint64(kstack.top())
}

//go:nosplit
func rt0()

//go:nosplit

type stack [16 * 4096]byte

type virtualAddress uintptr

var (
    kstack stack
)

//go:nosplit
func (s *stack) top() virtualAddress {
    stackTop := uintptr(unsafe.Pointer(&s[0])) + unsafe.Sizeof(*s)
    // Align to 16 bytes.
    stackTop = stackTop &^ 0xf
    return virtualAddress(stackTop)
}

//go:nosplit
func kernelStackTop() uint64 {
    return uint64(kstack.top())
}

//go:nosplit
func rt0()

//go:nosplit
func kmain() {
    for {
    }
}

预先分配了 stack 数组作为内核栈，kmain 啥也没干，就是无限循环。注意每个函数都有一个编译标识：//go:nosplit，表示让编译器不要插入检查这个函数的是否会栈溢出的代码，同时还有一个隐式的用途：阻止编译器在函数中插入 gc 检查点。如果触发了 gc，以现在这个啥也没有的裸机，gc 是完全不支持的（当然 gc 也不应该在内核中跑，更多的处理用户空间的堆）

这样 Makefile 就可以这样写了：

Image: kernel.elf
    $(CC) $(CFLAGS) -fno-pic -O -nostdinc -I. -c boot/boot.c
    $(CC) $(CFLAGS) -fno-pic -nostdinc -I. -c boot/boot_header.S
    $(LD) $(LDFLAGS) -T image.ld -o Image boot.o boot_header.o

kernel.elf:
    GOOS=linux GOARCH=riscv64 go build -o kernel.elf -ldflags '-E goose/kernel.rt0 -T 0x80200000' -gcflags "-N -l" ./kmain

kernel.elf 编译 go 的 elf 文件，指定入口函数为 goose/kernel.rt0，TEXT 段的起始地址为 0x80200000。而 Image 则是编译了上面说的加载内核的入口代码，image.ld 中指定了将入口函数放在 TEXT 段的入口，并把 TEXT 段放在 0x80000000 位置。

/* 执行入口 */
ENTRY(_start)

/* 数据存放起始地址 */
BASE_ADDRESS = 0x80000000;

SECTIONS
{
    /* . 表示当前地址（location counter） */
    . = BASE_ADDRESS;

    /* start 符号表示全部的开始位置 */
    kernel_start = .;

    text_start = .;

    /* .text 字段 */
    .text : {
        /* 把 entry 函数放在最前面 */
        *(.text.entry)
        /* 要链接的文件的 .text 字段集中放在这里 */
        *(.text .text.*)
    }
    ...
}

妥！

因为兴趣很大，整个春节我亲戚都没有走好，整天就是憋在屋里收集资料，在外面也是发呆想思路，魔怔了一样。

大失败

噔噔咚！

在把内核加载到 qemu 开始运行后，debug 看到卡死在把程序段加载到内存中。于是用 readelf 检查了一下 go build 出来的 elf 文件，发现了这个诡异的东西

Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x00000000801ff040 0x00000000801ff040
                 0x0000000000000188 0x0000000000000188  R      0x10000
  NOTE           0x0000000000000f9c 0x00000000801fff9c 0x00000000801fff9c
                 0x0000000000000064 0x0000000000000064  R      0x4
  LOAD           0xffffffffffff1000 0x00000000801f0000 0x00000000801f0000
                 0x0000000000063300 0x0000000000063300  R E    0x10000
  LOAD           0x0000000000060000 0x0000000080260000 0x0000000080260000
                 0x000000000006adb8 0x000000000006adb8  R      0x10000
  ...

注意第三段的 Offset 是 0xffffffffffff1000 这个大的吓人的数。Offset 是这个段的内容在文件中存放的位置相对于文件开头的偏移。这个 elf 文件才几十 KB，哪来这么大的偏移？即使加载到内存中，virt 计算机的默认物理内存大小也只有 128 MB，直接炸裂

百思不得其解，于是开始试验起来，最后发现，只要加上 -T 这个链接参数，就会出现这种情况。但是不加又不行，这些内存段不能被加载到低地址上，因为那是 mmio 的位置。于是我去 go 的 github 仓库里发了个 issue：cmd/link: wrong program header offset when cross-compile to riscv64 when setting -T text alignment。描述了一下后，得到的回答是：

ISSUE

看来是 RV64 对 -T 的支持不太完善……

于是这个项目就被搁置到了现在，可惜了我想的好名字/(ㄒo ㄒ)/ 只能期待后续 go 官方能修复这个问题，但是感觉 go 对 RV64 不是很上心，原生支持交叉编译到 RV64 也是近几年才合进主线的……

很气，转投 Rust 去了！

6.5840 实验 2a —— Leader 选举

Thu, 15 Dec 2022 18:06:10 GMT

前言

6.824 的实验二，是实现 Raft 算法，在后续实验中的实现的分布式 KV 存储会将本实验实现的 Raft 算法作为分布式共识模块使用，所以实验二对后续实验至关重要。

实验二将整个 Raft 算法分为四个步骤，作为四个子实验去实现。实验 2a 只实现基本的 Leader 选举和心跳，来保证在各种极端（断线）场景下都可以正常地换届和选举。

Of course，2a 作为奠定整个四个子实验基础的起始实验，不仅仅需要实现 Leader 选举功能，更需要搭好整体的流程处理的框架。同样，我实现的是无锁版本，Raft 结构体里的 mu 变量可以删掉啦（癫狂

实验讲解

实验指导书在 https://pdos.csail.mit.edu/6.824/labs/lab-raft.html。和实验一不一样，这次几乎没有任何参考。我们需要实现的代码在 src/raft/raft.go 中，这个 Raft 结构体只有一个很基础的结构体：

type Raft struct {
    peers []*labrpc.ClientEnd // RPC end points of all peers
    persister *Persister // Object to hold this peer's persisted state
    me int // this peer's index into peers[]
    dead int32 // set by Kill()
}

每一个 Raft 结构体都是集群中的一个 Server，Raft 结构体需要存储该 Server 所有需要的内容。

其中 peers 是当前配置集群的所有 server，ClientEnd 结构体可以通过调用 Call 直接发送 RPC 请求，me 则是当前机器在集群中的唯一标识，再其他机器上也是认这个 index 的。

lab2a 中 Raft 的入口是 Make() 方法，在 Make 方法初始化完成结构体后，会启动一个协程 rf.ticker()，该协程会执行一个无限循环（其实是根据结束标识持续执行的循环，鉴于我们不关心机器被关闭后的事情，所以可以看作无限循环），这个方法可以看作主协程。

实验二最难的地方就在于，框架实现的内容太少了，我们基本需要从零实现整个 Raft 算法。好在，论文中的 Figure 2 基本已经给出了整体的实现思路。

另外，测试用例的实现在同文件夹下的 test_test.go 中，如果测试用例不通过，可以看一下测试用例的实现，根据测试场景来 debug。

lab 2d 的测试命令为 go test -run 2A，建议使用 go test -race -run 2A 来同时检测数据竞争。

实验思路

整体流程

由于实现无锁版本，首先就需要仔细规划整体的处理流程和协程间通信，打好一个良好的基础，对后续实验也有很大的帮助，毕竟是一系列实验中的第一个。

首先约定主协程就是 rf.ticker() 方法，只有这个方法可以修改 Raft 结构体中的字段，其他协程都不允许，这样就直接避免了数据竞争，所以 ticker() 方法中应当是无限循环监听一堆 channel 的消息。

那么具体有哪些协程需要通信，需要哪些管道呢？首先，选举一共涉及两种 RPC 请求：追加请求和拉票请求，当服务器作为这两种请求的接收端时，一定不是首先在主协程中接收 RPC 请求的，那么这两种 RPC 请求需要发给主协程处理，就需要两个管道；其次，如果机器作为发送端，发送请求一般是由非主协程操作的（不能让主协程等待 RPC 返回），那么在这两种 RPC 获取到响应时，需要提交给主协程处理，就又需要两个管道。

除此以外，还需要两个定时器，分别用于选举超时和心跳超时。实验指导中推荐是使用 time.Sleep()，通过睡一段时间来实现定时。但是这种方式没有办法实现倒计时打断，所以，虽然指导书中不推荐 time.Timer，但是叛逆为了实现倒计时打断重置，我还是使用了 Timer。不过，timer 用对真的挺不容易。

首先需要定义 Server 的状态，来标识 Server 的身份：

type ServerStatus uint8
 
const (
    Follower  ServerStatus = 0
    Candidate ServerStatus = 1
    Leader    ServerStatus = 2
)

对照 Raft 论文 Figure 2，定义一下 Server 的基础字段，并定义上面提到的几个管道和定时器：

type Raft struct {
    ...

    // Status
    Status ServerStatus
    // 已提交日志，外部获取管道
    ApplyCh chan ApplyMsg

    /***** 所有 Server 都包含的持久状态 *****/
    // CurrentTerm 机器遇到的最大的任期，启动时初始化为 0，单调递增
    CurrentTerm int
    // VotedFor 当前任期内投票的 Candidate ID，未投票则为 -1
    VotedFor int
    // Logs 日志条目，每个条目都包含了一条状态机指令和 Leader 接收该条目时的任期，index 从 1 开始
    Logs []*LogEntry

    /***** 所有 Server 都包含的可变状态 *****/
    // CommitIndex 已知的最大的即将提交的日志索引，启动时初始化为 0，单调递增
    CommitIndex uint64
    // LastApplied 最大的已提交的日志索引，启动时初始化为 0，单调递增
    LastApplied uint64

    /******* Leader 包含的可变状态，选举后初始化 *******/
    // NextIndex 每台机器下一个要发送的日志条目的索引，初始化为 Leader 最后一个日志索引 +1
    NextIndex []uint64

type Raft struct {
    ...

    // Status
    Status ServerStatus
    // 已提交日志，外部获取管道
    ApplyCh chan ApplyMsg

    /***** 所有 Server 都包含的持久状态 *****/
    // CurrentTerm 机器遇到的最大的任期，启动时初始化为 0，单调递增
    CurrentTerm int
    // VotedFor 当前任期内投票的 Candidate ID，未投票则为 -1
    VotedFor int
    // Logs 日志条目，每个条目都包含了一条状态机指令和 Leader 接收该条目时的任期，index 从 1 开始
    Logs []*LogEntry

    /***** 所有 Server 都包含的可变状态 *****/
    // CommitIndex 已知的最大的即将提交的日志索引，启动时初始化为 0，单调递增
    CommitIndex uint64
    // LastApplied 最大的已提交的日志索引，启动时初始化为 0，单调递增
    LastApplied uint64

    /******* Leader 包含的可变状态，选举后初始化 *******/
    // NextIndex 每台机器下一个要发送的日志条目的索引，初始化为 Leader 最后一个日志索引 +1
    NextIndex []uint64
    // MatchIndex 每台机器已知复制的最高的日志条目，初始化为 0，单调递增
    MatchIndex []uint64

    // 定时器
    electionTimer  *time.Timer
    heartbeatTimer *time.Timer

    // 处理 rpc 请求的管道
    requestVoteChan   chan RequestVoteMsg
    appendEntriesChan chan AppendEntriesMsg
}

注意用到的管道和定时器等，都需要在 Make() 函数中初始化，否则 nil 管道会阻塞所有的读写操作，并在函数返回前起一协程作为主协程，监听管道消息：

func (rf *Raft) ticker() {
    for !rf.killed() {
        select {
        case <-rf.electionTimer.C:
            rf.startElection()
            resetTimer(rf.electionTimer, RandomizedElectionTimeout())
        case <-rf.heartbeatTimer.C:
            rf.broadcastHeartbeat()
            resetTimer(rf.heartbeatTimer, FixedHeartbeatTimeout())
        case msg := <-rf.requestVoteChan:
            rf.handleRequestVote(msg)
        case msg := <-rf.appendEntriesChan:
            rf.handleAppendEntries(msg)
        case msg := <-rf.requestVoteResChan:
            rf.handleRequestVoteRes(msg)
        case msg := <-rf.appendEntriesResChan:
            rf.handleAppendEntriesRes(msg)
        }
    }
}

两个定时器

electionTimer 是选举超时的定时器，每次需要初始化为一个随机时间，来防止启动时集群中的机器集体选举超时。这里随机时间范围为 300 ~ 450 ms。heartbeatTimer 是心跳超时的定时器，初始化为一个固定时间 100 ms。

func Make(peers []*labrpc.ClientEnd, me int,
    persister *Persister, applyCh chan ApplyMsg) *Raft {
    ...
    rf.electionTimer = time.NewTimer(RandomizedElectionTimeout())
    rf.heartbeatTimer = time.NewTimer(FixedHeartbeatTimeout())
    ...
}

func RandomizedElectionTimeout() time.Duration {
    rand.Seed(time.Now().UnixNano())
    return time.Duration(rand.Intn(150)+300) * time.Millisecond
}

func FixedHeartbeatTimeout() time.Duration {
    return time.Millisecond * 100
}

选举超时定时器主要用于非 Leader，每次收到 Leader 的心跳后，Server 会重置选举定时器，然而在一段时间没有收到 Server 的消息，Server 就会发起选举。发起选举流程如下：

当前任期 +1
身份变为 Candidate，同时投票给自己
向所有机器发送拉票请求

实现如下：

func (rf *Raft) startElection() {
    if rf.Status == Leader {
        // leader 无需发起新选举
        return
    }
    rf.CurrentTerm += 1
    // fmt.Printf("server %d start election for term %d\n", rf.me, rf.CurrentTerm)
    rf.Status = Candidate
    rf.VotedFor = rf.me
    args := RequestVoteArgs{
        Term:         rf.CurrentTerm,
        CandidateId:  rf.me,
        LastLogIndex: len(rf.Logs) - 1,
    }
    if len(rf.Logs) != 0 {
        args.LastLogTerm = rf.Logs[len(rf.Logs)-1].Term
    }
    meta := ElectionMeta{
        term: rf.CurrentTerm,
        yeas: 1,
        nays: 0,
    }
    for peer := range rf.peers {
        if peer == rf.me {
            continue

func (rf *Raft) startElection() {
    if rf.Status == Leader {
        // leader 无需发起新选举
        return
    }
    rf.CurrentTerm += 1
    // fmt.Printf("server %d start election for term %d\n", rf.me, rf.CurrentTerm)
    rf.Status = Candidate
    rf.VotedFor = rf.me
    args := RequestVoteArgs{
        Term:         rf.CurrentTerm,
        CandidateId:  rf.me,
        LastLogIndex: len(rf.Logs) - 1,
    }
    if len(rf.Logs) != 0 {
        args.LastLogTerm = rf.Logs[len(rf.Logs)-1].Term
    }
    meta := ElectionMeta{
        term: rf.CurrentTerm,
        yeas: 1,
        nays: 0,
    }
    for peer := range rf.peers {
        if peer == rf.me {
            continue
        }
        go rf.sendRequestVoteRoutine(peer, args, &meta)
    }
}

构造了一个 ElectionMeta 来存储一次选举的元信息，包含这次选举的任期、投赞同和反对票的 Server 个数。由于不可能在主协程中等待各个机器投票完毕，便对集群中的每一台机器都开启了一个协程来管理拉票 RPC，这些 RPC 会在获知选举结果后通过管道通知主协程。另外在发起选举后，需要重置选举超时定时器。

心跳超时定时器主要用于 Leader，用来在集群中维系自己的 Leader 身份，每当心跳超时定时器超时，Leader 就会在集群中广播心跳，来保证不会有新的选举发起。同样，广播过后也需要重置心跳超时定时器。

func (rf *Raft) broadcastHeartbeat() {
    if rf.Status != Leader {
        return
    }
    // fmt.Printf("server %d broadcast heartbeat\n", rf.me)
    args := AppendEntriesArgs{
        Term:     rf.CurrentTerm,
        LeaderID: rf.me,
    }
    for peer := range rf.peers {
        if peer == rf.me {
            continue
        }
        go rf.sendAppendEntriesRoutine(peer, args)
    }
}

心跳 RPC 复用追加 RPC，同样，和集群中其他机器的 RPC 连接在单独的协程中处理。

拉票相关

在选举定时器超时后，非 Leader 的机器就会发起新的选举，来尝试选出新的 Leader。在上面 StartElection() 中，已经为每个机器开启了一个协程，用来管理对每个机器的拉票 RPC。发送拉票请求的协程函数如下：

// 发送拉票请求的协程
func (rf *Raft) sendRequestVoteRoutine(peer int, args RequestVoteArgs, electionMeta *ElectionMeta) {
    reply := RequestVoteReply{}
    ok := rf.sendRequestVote(peer, &args, &reply)
    if !ok {
        return
    }
    msg := RequestVoteResMsg{
        resp: &reply,
        meta: electionMeta,
    }
    rf.requestVoteResChan <- msg
}

没有特殊的处理，仅仅是发送 RPC 请求，并将请求结果包装后通过管道发送给主协程处理。这里定义 RPC 的请求和响应参数结构：

// 拉票 RPC 请求
type RequestVoteArgs struct {
    // Term Candidate 的任期
    Term int
    // CandidateId 拉票的 Candidate 的 ID
    CandidateId int
    // LastLogIndex Candidate 最后一条日志序列的索引
    LastLogIndex int
    // LastLogTerm Candidate 最后一条日志序列的任期
    LastLogTerm int64
}

// 拉票 RPC 响应
type RequestVoteReply struct {
    // Term 当前任期
    Term int
    // VoteGranted true 则拉票成功
    VoteGranted bool
}

// 拉票请求 RPC 发送入口
func (rf *Raft) sendRequestVote(server int, args *RequestVoteArgs, reply *RequestVoteReply) bool {
    ok := rf.peers[server].Call("Raft.RequestVote", args, reply)
    return ok
}

接收端的 RPC 入口是 RequestVote 方法，由于接收 RPC 请求的协程不是主协程，这里仍然需要使用管道将拉票请求传递给主协程处理

/********* 拉票请求接收端相关方法 *********/
// 拉票请求 RPC 接收入口
func (rf *Raft) RequestVote(args *RequestVoteArgs, reply *RequestVoteReply) {
    msg := RequestVoteMsg{
        req: args,
        ok:  make(chan RequestVoteReply),
    }
    rf.requestVoteChan <- msg
    resp := <-msg.ok
    *reply = resp
}

// 主协程处理拉票请求
func (rf *Raft) handleRequestVote(msg RequestVoteMsg) {
    req := msg.req
    if req.Term < rf.CurrentTerm ||
        (req.Term == rf.CurrentTerm && rf.VotedFor != -1 && rf.VotedFor != req.CandidateId) {
        msg.ok <- RequestVoteReply{
            Term:        rf.CurrentTerm,
            VoteGranted: false,
        }
        return
    }
    rf.rpcTermCheck(req.Term)
    rf.VotedFor = req.CandidateId

/********* 拉票请求接收端相关方法 *********/
// 拉票请求 RPC 接收入口
func (rf *Raft) RequestVote(args *RequestVoteArgs, reply *RequestVoteReply) {
    msg := RequestVoteMsg{
        req: args,
        ok:  make(chan RequestVoteReply),
    }
    rf.requestVoteChan <- msg
    resp := <-msg.ok
    *reply = resp
}

// 主协程处理拉票请求
func (rf *Raft) handleRequestVote(msg RequestVoteMsg) {
    req := msg.req
    if req.Term < rf.CurrentTerm ||
        (req.Term == rf.CurrentTerm && rf.VotedFor != -1 && rf.VotedFor != req.CandidateId) {
        msg.ok <- RequestVoteReply{
            Term:        rf.CurrentTerm,
            VoteGranted: false,
        }
        return
    }
    rf.rpcTermCheck(req.Term)
    rf.VotedFor = req.CandidateId
    resetTimer(rf.electionTimer, RandomizedElectionTimeout())
    // fmt.Printf("server %d vote for server %d for term %d\n", rf.me, msg.req.CandidateId, req.Term)
    msg.ok <- RequestVoteReply{
        Term:        rf.CurrentTerm,
        VoteGranted: true,
    }
}

如果 Server 投了赞成票，还需要重置选举超时定时器。rpcTermCheck() 是一个通用的，用于检查 rpc 请求或响应中的任期是否大于自身的任期，如果大于自身任期则需要更新任期并成为 Follower：

// 检查 rpc 请求响应中的 term，如果大于自己的则需要更新任期并成为 Follower
func (rf *Raft) rpcTermCheck(msgTerm int) {
    if rf.CurrentTerm < msgTerm {
        rf.CurrentTerm = msgTerm
        rf.Status = Follower
        rf.VotedFor = -1
    }
}

在发起投票的协程获得了返回的投票结果后，将投票结果提交给主协程处理，在主协程中进行一些计票等判断。主协程处理投票结果如下

// 主协程处理拉票请求返回结果
func (rf *Raft) handleRequestVoteRes(msg RequestVoteResMsg) {
    meta := msg.meta
    if rf.Status != Candidate {
        return
    }
    if rf.CurrentTerm != meta.term {
        return
    }
    if msg.resp.VoteGranted {
        meta.yeas++
        if meta.yeas > len(rf.peers)/2 {
            // fmt.Printf("server %d become leader for term %d\n", rf.me, rf.CurrentTerm)
            rf.Status = Leader
            resetTimer(rf.heartbeatTimer, FixedHeartbeatTimeout())
            rf.broadcastHeartbeat()
        }
    } else {
        meta.nays++
        rf.rpcTermCheck(msg.resp.Term)
        if meta.nays > len(rf.peers)/2 {
            // 反对票超过一半，则该任期选举失败；可以给其他机器投票
            rf.VotedFor = -1
        }
    }

// 主协程处理拉票请求返回结果
func (rf *Raft) handleRequestVoteRes(msg RequestVoteResMsg) {
    meta := msg.meta
    if rf.Status != Candidate {
        return
    }
    if rf.CurrentTerm != meta.term {
        return
    }
    if msg.resp.VoteGranted {
        meta.yeas++
        if meta.yeas > len(rf.peers)/2 {
            // fmt.Printf("server %d become leader for term %d\n", rf.me, rf.CurrentTerm)
            rf.Status = Leader
            resetTimer(rf.heartbeatTimer, FixedHeartbeatTimeout())
            rf.broadcastHeartbeat()
        }
    } else {
        meta.nays++
        rf.rpcTermCheck(msg.resp.Term)
        if meta.nays > len(rf.peers)/2 {
            // 反对票超过一半，则该任期选举失败；可以给其他机器投票
            rf.VotedFor = -1
        }
    }
}

前置两个校验，如果当前 Server 的身份不是 Candidate，或者 Server 的任期和投票的任期不一致，就说明是一场过期的投票，无需处理，直接返回即可。

如果投的是赞成票，那么就计算一下当前赞成票数是否已大于一半，如果已经大于一半，说明选举成功，发起选举的 Server 转变为 Leader，并重置心跳定时器，向所有机器广播心跳来声明自己的 Leader 身份。

如果投的是反对票，这里算是个小优化。可以直接校验反对票是否已经超过一半，如果超过一半，那么可以认为该次发起的选举已经失败。可以将本任期内的投票置为 -1，以给其他潜在的 Candidate 投票来加速 Leader 选举。

追加相关

追加相关的内容，本次实验只需要实现心跳的处理即可。更具体的追加在实验 2b 中。

在 broadcastHeartbeat() 函数中，对集群中的全部机器广播心跳，使用的就是追加请求。对于每个机器都有一协程来管理与之通信的追加请求。追加协程的函数如下

// 发送追加请求的协程
func (rf *Raft) sendAppendEntriesRoutine(peer int, args AppendEntriesArgs) {
    reply := AppendEntriesReply{}
    ok := rf.sendAppendEntries(peer, &args, &reply)
    if !ok {
        return
    }
    rf.appendEntriesResChan <- AppendEntriesResMsg{
        resp: &reply,
    }
}

与上面的发起选举类似，也是直接发送一个 RPC 请求，并等待响应，将响应通过管道交由主协程处理。追加 RPC 的请求与响应定义如下

// 追加 RPC 请求
type AppendEntriesArgs struct {
    // Term Leader 的任期
    Term int
    // LeaderID Follower 可以将客户端请求重定向到 Leader
    LeaderID int
    // PrevLogIndex 新日志条目前一个日志条目的日志索引
    PrevLogIndex int
    // PrevLogTerm 前一个日志条目的任期
    PrevLogTerm int
    // Entries 需要保存的日志条目，心跳包为空
    Entries []*LogEntry
    // LeaderCommit Leader 的 CommitIndex
    LeaderCommit int
}

// 追加 RPC 响应
type AppendEntriesReply struct {
    // Term Follower 当前任期
    Term int
    // Success Follower 包含 PrevLogIndex 和 PrevLogTerm 的日志条目为 true
    Success bool
}

// 追加请求 RPC 发送入口

// 追加 RPC 请求
type AppendEntriesArgs struct {
    // Term Leader 的任期
    Term int
    // LeaderID Follower 可以将客户端请求重定向到 Leader
    LeaderID int
    // PrevLogIndex 新日志条目前一个日志条目的日志索引
    PrevLogIndex int
    // PrevLogTerm 前一个日志条目的任期
    PrevLogTerm int
    // Entries 需要保存的日志条目，心跳包为空
    Entries []*LogEntry
    // LeaderCommit Leader 的 CommitIndex
    LeaderCommit int
}

// 追加 RPC 响应
type AppendEntriesReply struct {
    // Term Follower 当前任期
    Term int
    // Success Follower 包含 PrevLogIndex 和 PrevLogTerm 的日志条目为 true
    Success bool
}

// 追加请求 RPC 发送入口
func (rf *Raft) sendAppendEntries(server int, args *AppendEntriesArgs, reply *AppendEntriesReply) bool {
    ok := rf.peers[server].Call("Raft.AppendEntries", args, reply)
    return ok
}

接收方在收到追加 RPC 请求后，将请求交由主协程处理，当前主协程也只需要处理心跳场景，即转变为 Follower，重置选举超时定时器，并判断是否需要更新任期：

/********* 追加请求接收端相关方法 *********/
// 追加请求 RPC 接收入口
func (rf *Raft) AppendEntries(args *AppendEntriesArgs, reply *AppendEntriesReply) {
    msg := AppendEntriesMsg{
        req: args,
        ok:  make(chan AppendEntriesReply),
    }
    rf.appendEntriesChan <- msg
    resp := <-msg.ok
    *reply = resp
}

// 主协程处理追加请求
func (rf *Raft) handleAppendEntries(msg AppendEntriesMsg) {
    rf.Status = Follower
    resetTimer(rf.electionTimer, RandomizedElectionTimeout())
    rf.rpcTermCheck(msg.req.Term)
    msg.ok <- AppendEntriesReply{
        Term: rf.CurrentTerm,
    }
}

最后发送端处理响应，只需要检查任期即可，仍可复用 rpcTermCheck()：

// 主协程处理追加请求返回结果
func (rf *Raft) handleAppendEntriesRes(msg AppendEntriesResMsg) {
    resp := msg.resp
    rf.rpcTermCheck(resp.Term)
}

Raft 论文阅读

Sat, 03 Dec 2022 13:40:09 GMT

前言

Raft 是用于管理日志复制的共识算法。共识算法适用于包含多台机器的集群中，以保证在其中有些机器挂掉时仍然能正常对外提供服务。由此，共识算法在构建可靠的大规模软件系统中十分重要。

关于 Raft 算法主要的论文就是《In Search of an Understandable Consensus Algorithm (Extended Version)》，可以在这里阅读。论文也不长，18 页。文中大量出现了将 Raft 和 Paxos 的对比（开头就是一顿诉苦），凸显了 Raft 最大的优势：more understandable。

本文是在论文阅读中的笔记。

前情提要

共识算法的提出主要是用于复制状态机（Replicated state machines）模型。复制状态机通常用复制日志实现，每个日志中都包含一系列指令。集群中的每台机器都按相同的顺序执行这一系列指令，最终就会到达相同的状态。注意这个最终，表面这是最终一致性而非强一致性的。

共识算法保证复制日志在集群中是连续的，共识模块和其他机器上的共识模块通信来保证每台机器最终都按照相同顺序执行了相同的指令，即使其中某些机器挂掉了。这样保证了所有机器像单台机器一样共同对外提供服务。

共识算法仅适用于非拜占庭场景，即节点不会蓄意伪造信息。

算法描述

Raft 共识算法可以分成三个相对独立的子模块： - Leader 选举：如果一个现有的 Leader 挂掉了，必须选举出一个新的 Leader - 日志复制：Leader 必须从客户端接收日志，并在集群中复制，保证其他机器上的日志和自身的一致 - 安全性保障：如果任何机器接受了一个特定指令，那么其他机器就不可能再接收拥有和该指令相同的日志索引（log index）的指令

Raft 基础

Raft 集群中的机器在任何时候都只有三种状态： - Leader：负责处理所有的客户端请求 - Follower：不处理请求，被动接收 Leader 和 Candidate 的请求并应答 - Candidate：用于选举出一个 Leader

正常执行的情况下，集群只有一个 Leader，其他所有机器都是 Follower。

Raft 将时间划分为多个任期，每个任期开始时都会在集群中举行选举，一个或多个 Candidate 会尝试成为 Leader。如果某个 Candidate 赢得了选举，那么它就会变成 Leader，其余机器变为 Follower。

任期是一个单调递增的整数，每台机器中都会保存当前任期，机器之间通信时也会带上当前任期。如果某台机器发现自己的当前任期小于其他机器，就会更新自己的当前任期。如果 Candidate 或者 Leader 发现自己的当前任期小于其他任期（出现新任期的 Leader），就会立刻转变成为 Follower。

Raft 机器之间的基本通信只需要两种类型的 RPC。拉票请求（RequestVote RPCs，这个翻译怎么怪怪的）在选举中由 Candidate 发起；追加请求（AppendEntries RPCs）由 Leader 发起，用于复制日志和维持心跳。

Leader 选举

机器启动时的状态是 Follower，并且会在收到合适的 RPC 的情况下一直保持 Follower 状态。Leader 会定时发送不包含命令的追加请求作为心跳来维持 Server 身份。一旦某个 Follower 一段时间内没有收到请求，就会发起一场选举。

发起选举的 Follower 会转变为 Candidate，并将当前任期 +1，给自己投票后并行地向集群中的其他机器发送拉票请求。Candidate 会维持该状态直到一下三种情况发生：1. 如果某个 Candidate 获得了集群中大多数机器的票，那么它就赢得了选举。每个机器在某个任期中最多只会给一个 Candidate 投票，按照先来先得的原则，这样保证了每个任期中最多只有一个 Candidate 赢得选举。赢得选举的 Candidate 会变成 Leader，并向其他机器发送心跳来维持 Leader 地位。2. Candidate 可能会收到其他机器的追加请求：如果该请求中的任期大于等于 Candidate 的当前任期，Candidate 就会转变为 Follower；否则会拒绝该请求并维持 Candidate 状态。3. 如果许多 Follower 同时转变为 Candidate，那么可能没有一个 Candidate 可以获得大多数票。这种情况下 Candidate 会超时，将当前任期 +1 并发起一场新的选举。

为了防止场景 3 无限循环下去，Candidate 的超时时间一般设置为某个固定区间的随机时间以防止同时超时。

日志复制

每个客户端请求都包含一条需要日志复制状态机执行的指令，Leader 收到请求后会将该指令添加到 log 中，并行向集群中的机器发起追加请求来复制指令。当指令完成复制后，Leader 会提交（Commit）该命令到状态机并回复客户端执行成功。

每个追加请求中除了包含需要复制到指令，还包含 Leader 收到指令时的当前任期，同时还包含了一个整数索引来标明其在日志中的位置。

当接收该命令的 Leader 成功将命令复制到大多数机器上时，这条命令就会被 Leader 提交。Raft 会保证被提交的命令是持久化的，且最终会被所有可用的状态机执行。这个提交会同时提交所有前序的指令，即使是由其他的 Leader 创建的。Leader 会持续记录即将提交的日志索引并在所有追加请求中包含该索引。当 Follower 得知某个日志条目已经被提交了，它也会将该条目提交到它的状态机中。

同时 Raft 还需要保证以下两条规则： - 如果两个日志条目拥有相同的任期和日志索引，那么它们一定保存了相同的指令 - 如果两个日志条目拥有相同的任期和日志索引，那么这两条日志的所有前序日志都是相同的

第一条的保证比较简单，主要看第二条的保证。

当发送追加请求时，Leader 还会将新日志条目前面那一条条目的任期和日志索引包含在请求中。如果 Follower 在其日志序列中找不到该条日志，就会拒绝该请求，这就是连续性检查。由此，只要请求成功返回，Leader 就会知道 Follower 的日志和自己的是一致的。

当连续性检查失败时，Leader 会强制要求 Follower 的日志序列和自身保持一致。具体：Leader 需要找到找到和 Follower 相同的最后一条日志，删除 Follower 日志序列中那一条日志中的后面所有日志，并将自己的后续日志发给 Follower。Leader 需要给每个 Follower 维护一个 nextIndex，保存着下一个将要给该 Follower 发送的日志索引。当 Leader 刚启动时，会将所有 Follower 的 nextIndex 都初始化为其 log 序列最后一个日志索引 +1。当某个 Follower 没有通过，Leader 会将该 Follower 的 nextIndex -1 并重发追加请求。

这里说的有点模糊，我估计应该是每个追加请求发送的是从 nextIndex 到后一个日志条目，否则在连续性检查通过后，仅仅是将 Follower 的日志序列裁剪到了 Leader 和 Follower 一致处，一致处后续的日志并没有同步到 Follower

安全性保障

以上描述的机制并不能完全保证安全性，例如可能存在这种可能性：某台机器突然不可达，在此期间 Leader 提交了多条日志，该机器可能会被选举为 Leader，导致这些日志被覆写。本节增加了一个选举时的限制来完善 Raft 算法。该限制保证了任一任期的 Leader 一定包含了前一任期的全部提交了的日志。

首先，拉票请求会包含 Candidate 的日志信息，如果其他机器发现自己的日志比 Candidate 的日志更新（最后一个条目的任期更大、日志索引更大），那么该机器就会拒绝投票请求。

另外，一旦某条当前任期的日志条目被大多数机器接收，Leader 就会将其提交。如果 Leader 在提交条目时就挂了，下一任 Leader 会继续尝试完成这个条目的复制。但是 Leader 不能立刻确定某个前一任期的条目已经被提交，即使它已经存储在大多数机器上。由此可能会导致论文 Figure 8 中的问题。

由此，Raft 并不通过检查副本的个数来尝试提交前一个任期的日志条目。只会检查副本个数来提交当前任期的日志条目，当某个当前任期的条目被提交，那么该条目前面的所有条目都被隐式地提交了。

集群节点变更

在集群节点变更的过程中，如果想要不让整个集群下线而实现集群配置变更，集群存在出现两个独立的“主体”的可能，即可能会选举出两个 Leader。

为了保证节点变更的安全性，Raft 采用了两阶段方法。首先集群切换到一个联合共识（joint consensus）状态，在联合共识被提交后，系统再切换到新配置。联合共识状态下，集群仍然可以正常地对外提供服务。在联合共识状态下： - 日志会被复制到新旧配置中的所有机器上 - 两个配置上的每台机器都允许成为 Leader - 选举和追加需要在新旧两个配置上都分别获得大多数同意才能生效

集群配置在日志中使用特殊的条目存储和传输。流程如下：1. Leader 收到了一个请求，将集群配置从 C_old 切换为 C_new 2. Leader 将 C_old 和 C_new 作为联合共识 C_old,new 配置存储到一条日志条目中 3. 将该条日志条目追加到新旧配置的所有机器上 4. 当某台机器接收到这样的日志条目添加其日志上时（无需提交），后续所有的操作都以该配置为标准进行 5. 当 C_old,new 被多数机器接受后，Leader 将其提交。这时，任何 C_old 或者 C_new 配置的机器就都不可能被选为 Leader 6. Leader 创建一条 C_new 的日志条目，并追加到所有机器上并提交

集群节点变更仍然存在以下三个问题：1. 新机器加入集群时没有存储任何日志，需要花一段时间才能追上旧机器，这可能会在短时间内造成集群的可用性降低。Raft 在将节点加入集群中时，引入了一个新阶段，在这个阶段，新机器可以正常收到追加请求，但是不会被认为是可投票的节点，不必考虑这些新节点即可达成共识。当这些新节点的日志赶上了旧机器的进度，再进行上述处理 2. 集群的 Leader 可能不是新配置的一部分。在这种情况下，当 Leader 提交 C_new 时，它自身就应当被撤下。这导致了有一段时间，Leader 管理着一个不包含它自己的集群，它复制日志但是不把自己视作主体。3. 那些被撤下的服务器可能会破坏集群，由于这些机器接收不到心跳，可能会举行选举。随后发送带有新任期的拉票请求，导致集群的 Leader 恢复成 Follower。虽然这种情况下这种选举不会成功，新 Leader 仍然会在新集群中产生，但是被撤下的机器仍然会选举超时，导致整体可用性较差。

为了防止问题 3 发生，Raft 增加了一条限制：如果服务器在从当前 Leader 处收到心跳的超时时间内收到拉票请求，就不会更新任期和投票。这使得一个 Leader 只要可以维持当前集群的心跳，就不会被更大的任期选票踢下位。

日志压缩

随着日志的增长，机器不能将所有的日志都保存在内存中，所以需要引入快照，定期地将系统的状态保存在持久化存储中，这样从开始到快照点的日志都安全地从内存中删除。

集群中的每台机器独自管理自己的快照，快照仅包含其日志中已提交的日志条目。除了需要保存状态机的当前状态外，还需要保存一些元数据： - 快照包含的最后一个日志条目的日志索引 - 快照包含的最后一个日志条目的日志任期

这些元数据主要用于追加请求时的连续性检查（在连续性检查中需要对比前序日志条目）。如果需要支持上面提到的集群节点变更，快照中还需要包含到快照点处的最新配置信息。当机器完成快照写入后，即可删除快照点之前的所有日志和历史快照。

偶尔，Leader 需要将自身的日志同步到一些新加入的节点或者落后节点时，需要发送快照。Leader 会使用一种新的 RPC 请求：同步快照请求（InstallSnapshot RPC）来向 Follower 发送快照，如下：

type InstallSnapshotRequest struct {
    // Term Leader 的任期
    Term              int64
    // LeaderID Follower 可以将客户端请求重定向到 Leader
    LeaderID          int64
    // LastIncludedIndex 快照包含的最后一个条目的索引
    LastIncludedIndex int64
    // LastIncludedTerm 快照包含的最后一个条目的任期
    LastIncludedTerm  int64
    // Offset 快照文件中的该快照块的偏移
    Offset            int64
    // Data 快照块数据
    Data              []byte
    // Done 是否是最后一个快照块
    Done              bool
}

type InstallSnapshotResponse struct {
    // Term Follower 当前任期
    Term    int64
}

接收者的实现：1. 如果 Term 小于 CurrentTerm，立刻返回 2. 如果是第一个快照块（Offset = 0），创建快照文件 3. 将数据写入到快照文件对应偏移处 4. 如果 Done 为 false，返回并等待下一个同步快照请求 5. 如果日志中包含符合 LastIncludedIndex 和 LastIncludedTerm 的日志条目，则保留它后面所有的日志条目并返回 6. 废弃全部日志 7. 使用快照信息重制状态机，并使用快照中的集群配置

通常快照中会包含接收者当前没有的日志，这种情况下，接收者就会废弃全部日志并使用快照信息。如果快照中的日志条目接收者的日志中全部包含，那么接收者这部分日志会被快照替代，但是快照后的日志条目还需要保留。

最后就是一些快照可能会影响集群的性能的问题。机器可以选择一个固定的字节大小，当日志达到这个大小的时候落快照，不宜过大也不宜过小。过大会导致落快照时间过长，过小会导致落快照过于频繁。另外，落快照可能会花费很长时间（磁盘 IO 是很慢的！），可能会影响正常流程的进行。Raft 推荐使用写时复制技术，在快照写入磁盘过程中，机器仍然可以正常追加日志和处理请求。

客户端交互

客户端的所有请求都由 Raft 集群中的 Leader 处理。当客户端启动时，会随便选择集群中的一个机器发送请求，如果这台机器不是 Leader，它会拒绝这个请求并返回它最近接收到心跳的 Leader 地址。当 Leader 挂掉后，客户端请求会超时，随后客户端会再次尝试随便选择一个机器请求。

Raft 的目标是被实现为可线性化的语义，即每个操作的执行可以看作瞬时完成的，且仅会被执行一次。然而可能存在这种可能，Leader 在执行一条指令后，在响应客户端前挂掉了；客户端就会选择另一个 Leader 重新发送一遍请求，导致指令被执行两次。解决办法是客户端们在执行请求时给每个指令标记上一个单调递增的唯一标识，同时状态机记录最后一条被执行的指令的标识。如果状态机收到一个已经被执行完成的指令，它会立刻返回成功而不会重新执行。

在处理只读请求的时候，由于不需要向日志中写入数据，就无需获得集群共识即可处理请求。然而由于无需共识，此时的 Leader 可能已经被某个新任期的 Leader 替代了（而它自己暂时不知道），这可能会导致这条读请求返回旧的数据。Raft 通过以下两个措施来防止这种事情发生：1. Leader 必须拥有所有已提交的日志条目的最新信息。Leader 完整性保证了 Leader 一定拥有这些条目，但是在其任期开始时它无法确定哪些是已提交的。Raft 处理这个问题的方式是在任期开始时提交一条无操作的日志条目以获取最新的提交信息。2. Leader 在处理只读请求之前必须确定它还是集群 Leader。这只需要在处理请求之前与集群的大部分机器交换一下心跳即可。

算法实现

论文在 Figure 2 中给出了一个非常详细的实现（that's why raft is awesome!），不包含节点变更和日志压缩

Server 状态

type ServerState struct {
    /***** 所有 Server 都包含的持久状态 *****/
    // CurrentTerm 机器遇到的最大的任期，启动时初始化为 0，单调递增
    CurrentTerm int64;
    // VotedFor 当前任期内投票的 Candidate ID，未投票则为 nil
    VotedFor    *int64;
    // Logs 日志条目，每个条目都包含了一条状态机指令和 Leader 接收该条目时的任期，index 从 1 开始
    Logs        []*Log;

    /***** 所有 Server 都包含的可变状态 *****/
    // CommitIndex 已知的最大的即将提交的日志索引，启动时初始化为 0，单调递增
    CommitIndex int64;
    // LastApplied 最大的已提交的日志索引，启动时初始化为 0，单调递增
    LastApplied int64;

    /******* Leader 包含的可变状态，选举后初始化 *******/
    // NextIndex 每台机器下一个要发送的日志条目的索引，初始化为 Leader 最后一个日志索引 +1
    NextIndex  []int64;
    // MatchIndex 每台机器已知复制的最高的日志条目，初始化为 0，单调递增
    MatchIndex []int64;
}

追加请求

type AppendEntriesRequest struct {
    // Term Leader 的任期
    Term         int64
    // LeaderID Follower 可以将客户端请求重定向到 Leader
    LeaderID     int64
    // PrevLogIndex 新日志条目前一个日志条目的日志索引
    PrevLogIndex int64
    // PrevLogTerm 前一个日志条目的任期
    PrevLogTerm  int64
    // Entries 需要保存的日志条目，心跳包为空
    Entries      []*Log
    // LeaderCommit Leader 的 CommitIndex
    LeaderCommit int64
}
 
type AppendEntriesResponse struct {
    // Term Follower 当前任期
    Term    int64
    // Success Follower 包含 PrevLogIndex 和 PrevLogTerm 的日志条目为 true
    Success bool
}

接收者的实现：1. 如果 Term 小于 CurrentTerm，返回 false 2. 如果日志中不包含 PrevLogIndex 和 PrevLogTerm 对应的日志条目，返回 false 3. 如果某个现有的日志条目和新条目包含了相同的日志索引但是有不同的任期，删除该条和其后所有的日志 4. 添加所有在日志中不存在的日志条目 5. 如果 LeaderCommit 大于 CommitIndex，则将 CommitIndex 设置为 LeaderCommit 或者新日志中最后一个索引之间的较小值

拉票请求

type RequestVoteRequest struct {
    // Term Candidate 的任期
    Term         int64
    // CandidateId 拉票的 Candidate 的 ID
    CandidateId  int64
    // LastLogIndex Candidate 最后一条日志序列的索引
    LastLogIndex int64
    // LastLogTerm Candidate 最后一条日志序列的任期
    LastLogTerm  int64
}

type RequestVoteResponse struct {
    // Term 当前任期
    Term        int64
    // VoteGranted true 则拉票成功
    VoteGranted bool
}

接收者实现：1. 如果 Term 小于 CurrentTerm，返回 false 2. 如果 VotedFor 是 nil 或者 CandidateId，且 Candidate 的日志和接收者一样新或者更新，则返回 true

Server 规则

对于所有机器： - 如果 CommitIndex 大于 LastApplied，LastApplied +1，并将日志 log[LastApplied] 提交到状态机 - 如果 RPC 请求或者相应中的 Term 大于 CurrentTerm，则将 CurrentTerm 设置为 Term，并转变为 Follower

对于 Follower： - 相应来自 Candidate 和 Leader 的 RPC - 如果一直到选举超时也没有收到来自当前 Leader 的追加请求或者给某个 Candidate 投票（注意不是收到拉票请求，而是投票），则转变为 Candidate

对于 Candidate： - 一旦转变成 Candidate，即开始选举： - 将当前任期 +1 - 给自己投票 - 重制选举超时计时器 - 向所有其他机器发送拉票请求 - 如果收到了大多数机器的票，则转变成 Leader - 如果收到来自新 Leader 的追加请求，转变为 Follower - 如果选举超时，开始新一轮选举

对于 Leader： - 一旦转变成 Leader，向其他所有机器发送空的追加请求；在空闲时重复发送空追加请求来防止选举超时 - 如果收到来自客户端的指令：添加日志条目到日志中，在条目提交到状态机后返回相应 - 如果最后一条日志索引大于某个客户端的 NextIndex：向客户端发送包含 NextIndex 及其后所有日志条目的追加请求 - 如果成功，更新 Follower 的 NextIndex 和 MatchIndex - 如果因为日志连续性而失败，NextIndex -- 并重拾 - 如果存在一个 N 大于 CommitIndex，大多数 MatchIndex 大于等于 N，且第 N 条日志的任期等于当前任期，则设置 CommitIndex 为 N

golang 支持不同类型结构体间的深拷贝

Sun, 14 Aug 2022 17:05:01 GMT

最近在做系统重构，忙得不可开交～博客荒废了好一阵子

在重构时，遇到了一个很恶心的事情：分层架构中不同层实体的互相转换。以商品为例，在视图层可能存在一个商品 VO，在领域层有个商品 entity 或者叫 DO（domain object），在存储层还可能有个商品 PO 对应着数据库实体……

这些实体结构大都很像，甚至好多基本一致或完全一样，或存在着细微的区别，例如某个字段在这个实体中是指针类型，而在另外的结构中则不是指针类型，因而导致无法直接强转，比如写很多 assembler 方法来对实体做转换，遇到复杂结构简直就是地狱。本质上就是深拷贝，就因为类型不一致而没法处理。

于是想着能不能用反射解决一下问题，对于这种特殊的场景做一个通用一点的转换方法，于是花了一个下午，以下代码应运而生：

func Copy(src interface{}, dstType interface{}) interface{} {
    if src == nil {
        return nil
    }
    cpy := reflect.New(reflect.TypeOf(dstType)).Elem()
    copyRecursive(reflect.ValueOf(src), cpy)
    return cpy.Interface()
}
 
func copyRecursive(src, dst reflect.Value) {
    switch src.Kind() {
    case reflect.Ptr:
        originValue := src.Elem()
        if !originValue.IsValid() {
            return
        }
        // 允许 src 为 ptr 而 dst 为非 ptr
        if dst.Kind() == reflect.Ptr {
            dst.Set(reflect.New(dst.Type().Elem()))
            copyRecursive(originValue, dst.Elem())
        } else {
            dst.Set(reflect.New(dst.Type()).Elem())
            copyRecursive(originValue, dst)
        }
    case reflect.Interface:

func Copy(src interface{}, dstType interface{}) interface{} {
    if src == nil {
        return nil
    }
    cpy := reflect.New(reflect.TypeOf(dstType)).Elem()
    copyRecursive(reflect.ValueOf(src), cpy)
    return cpy.Interface()
}
 
func copyRecursive(src, dst reflect.Value) {
    switch src.Kind() {
    case reflect.Ptr:
        originValue := src.Elem()
        if !originValue.IsValid() {
            return
        }
        // 允许 src 为 ptr 而 dst 为非 ptr
        if dst.Kind() == reflect.Ptr {
            dst.Set(reflect.New(dst.Type().Elem()))
            copyRecursive(originValue, dst.Elem())
        } else {
            dst.Set(reflect.New(dst.Type()).Elem())
            copyRecursive(originValue, dst)
        }
    case reflect.Interface:
        if src.IsNil() {
            return
        }
        originValue := src.Elem()
        copyValue := reflect.New(dst.Type().Elem()).Elem()
        copyRecursive(originValue, copyValue)
        dst.Set(copyValue)
    case reflect.Struct:
        // time.Time 需要特殊处理
        t, ok := src.Interface().(time.Time)
        if ok {
            dst.Set(reflect.ValueOf(t))
            return
        }
        if dst.Kind() == reflect.Ptr {
            // 目标类型是指针而源类型不是指针
            copyValue := reflect.New(dst.Type().Elem()).Elem()
            copyRecursive(src, copyValue)
            dst.Set(copyValue.Addr())
            return
        }
        for i := 0; i < dst.NumField(); i++ {
            if dst.Type().Field(i).PkgPath != "" {
                // 不可导出的字段不拷贝
                continue
            }
            field := src.FieldByName(dst.Type().Field(i).Name)
            if !field.IsValid() {
                // 源字段不存在，忽略（目标自动零值）
                continue
            }
            copyRecursive(field, dst.Field(i))
        }
    case reflect.Slice:
        if src.IsNil() {
            return
        }
        dst.Set(reflect.MakeSlice(dst.Type(), src.Len(), src.Cap()))
        for i := 0; i < src.Len(); i++ {
            copyRecursive(src.Index(i), dst.Index(i))
        }
    case reflect.Map:
        if src.IsNil() {
            return
        }
        dst.Set(reflect.MakeMap(dst.Type()))
        for _, key := range src.MapKeys() {
            value := src.MapIndex(key)
            copyValue := reflect.New(dst.Type().Elem()).Elem()
            copyRecursive(value, copyValue)
            copyKey := Copy(key.Interface(), reflect.New(dst.Type().Key()).Elem().Interface())
            dst.SetMapIndex(reflect.ValueOf(copyKey), copyValue)
        }
    default:
        // 源类型是基础类型
        // 类型不一致但底层类型一致的基本类型，需要强转
        if dst.Kind() == reflect.Ptr {
            // 目标类型是指针而源类型不是指针
            copyValue := reflect.New(dst.Type().Elem()).Elem()
            copyRecursive(src, copyValue)
            dst.Set(copyValue.Addr())
            return
        }
        dst.Set(src.Convert(dst.Type()))
    }
}

核心在于 copyRecursive 方法，它支持处理结构体、Slice 和 Map 的深拷贝，并且支持从指针类型向非指针类型、非指针类型向指针类型的拷贝，唯一的要求就是拷贝结构体时，目标类型结构体中的所有字段都必须在源类型结构体中有同名且底层类型相同的字段，这样才能完成递归深拷贝。

具体代码原理不细细讲解，但是我还是要说一句：

反射确实很牛逼

20220820 update：支持拷贝到源结构体中不存在同名字段的结构体，当源结构体不存在同名字段时，目标结构体的字段会被赋零值（指针为 nil，结构体为空结构体）

Java 中 this 关键字导致编译期常量传播优化失效的问题

Fri, 15 Apr 2022 16:01:28 GMT

名字起的有点长了，但是这确实是个挺有趣的问题。如下代码：

public class Test {
    final static String s = "a";

    public void test() {
        String cmp = "ab";
        String ab1 = s + "b";
        String ab2 = this.s + "b";
        System.out.println(ab1 == cmp);
        System.out.println(ab2 == cmp);
    }

    public static void main(String[] args) {
        new Test().test();
    }
}

我们先来猜一猜输出结果，第 7 行的 s 和第 8 行的 this.s 都是指的同一个变量，就是那个 final 静态变量 s。那么就算我们不知道结果，这两个输出应该也是一样的。但实际上的输出是

true
false

我们先用 javap 将生成的字节码反汇编出来，test() 部分如下：

  public void test();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=3, locals=4, args_size=1
         0: ldc           #7                  // String ab
         2: astore_1
         3: ldc           #7                  // String ab
         5: astore_2
         6: aload_0
         7: pop
         8: ldc           #11                 // String a
        10: invokedynamic #13,  0             // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
        15: astore_3
        16: getstatic     #17                 // Field java/lang/System.out:Ljava/io/PrintStream;
        19: aload_2
        20: aload_1
        21: if_acmpne     28
        24: iconst_1
        25: goto          29
        28: iconst_0
        29: invokevirtual #23                 // Method java/io/PrintStream.println:(Z)V
        32: getstatic     #17                 // Field java/lang/System.out:Ljava/io/PrintStream;
        35: aload_3
        36: aload_1

  public void test();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=3, locals=4, args_size=1
         0: ldc           #7                  // String ab
         2: astore_1
         3: ldc           #7                  // String ab
         5: astore_2
         6: aload_0
         7: pop
         8: ldc           #11                 // String a
        10: invokedynamic #13,  0             // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
        15: astore_3
        16: getstatic     #17                 // Field java/lang/System.out:Ljava/io/PrintStream;
        19: aload_2
        20: aload_1
        21: if_acmpne     28
        24: iconst_1
        25: goto          29
        28: iconst_0
        29: invokevirtual #23                 // Method java/io/PrintStream.println:(Z)V
        32: getstatic     #17                 // Field java/lang/System.out:Ljava/io/PrintStream;
        35: aload_3
        36: aload_1
        37: if_acmpne     44
        40: iconst_1
        41: goto          45
        44: iconst_0
        45: invokevirtual #23                 // Method java/io/PrintStream.println:(Z)V
        48: return

常量表中的 #7 为：

   #7 = String             #8             // ab
   #8 = Utf8               ab

我们先来看第一个 true，这个大家应该基本都知道原因。编译器在将源码编译为 class 字节码文件时，会将当前类的方法中出现的 final 常量替换为字面量，于是 Java 代码第 6 行的 String ab1 = s + "b"; 就变为 String ab1 = "a" + "b";，进一步，由于 ab1 是由两个字面量直接拼接的，编译器就直接帮其完成拼接，最终的结果，这条语句等价于 String ab1 = "ab";。于是 cmp 和 ab1 都指向常量池的"ab"字符串，所以 cmp == ab1。反汇编的字节码中，第 0 行和第 3 行是完全一样的，ldc（Load Constant）的参数都是 #7。

字节码的 8~15 行是准备字符串 ab2 的过程，可以看到这里执行了一个动态方法调用，调用的是方法 makeConcatWithConstants，这个方法是 Java 的一个引导方法，用于处理 Java 中对 String 进行“+”拼接。这个方法会在堆中创建一个新的字符串变量，这就是 ab2 != cmp 的原因。

BTW，makeConcatWithConstants 这个方法在 JDK 9 中被引入用于处理字符串“+”操作，在 JDK 8 之前，javac 一直是用 StringBuilder 类来处理的。

那么是什么导致了这个差异呢？显然，问题在这个 this 关键字上。Java 在编译时，会隐式在所有成员方法中添加一个指向当前实例的引用 this，这个 this 在字节码中是作为方法参数传递给方法的，这就是为什么 void() 方法没有参数，字节码第五行中 args_size 却等于 1。对于一个对象引用的变量（无论是类变量还是成员变量），Java 编译器仅仅是很粗暴地关闭了这个优化。如果将这里的 this.s 改为 Test.s，那么这里输出的结果就是 true 了。

《三体》中的“大多数人”

Sun, 10 Apr 2022 16:13:13 GMT

如果哪天中国搞民主了，那肯定是人间地狱，我肯定第二天就逃离中国。

——刘慈欣，2019 年接受《纽约客》采访

大刘在很多场合都表达过他对西式民主的不信任对态度，对于让大多数人自决命运的一种悲观。大刘的很多小说所表现出的这种政治倾向是十分鲜明的。他的《三体》，也在无数次地传达他的理念。

整部《三体》描绘的地球往事编年史：从公元 1453 年到公元 18906416 年（银河纪元 18904136 年）再到 647 号小宇宙到第二年为止，这上下近两千万年的浩瀚历史，无不印证着这么一句话：

人民群众是历史的创造者。

当然，不是什么乐观的印证。

这两千万年，自然也出现过无数英雄豪杰——章北海、罗辑、云天明、托马斯维德……他们也都曾在关键时刻怒挽狂澜，无数次做出能够挽救全人类命运的举动，却最终都化为泡影。

很有趣的是，《三体》的故事是从文化大革命开始说起的，《三体一》的开篇，叶文洁的父亲叶哲泰就被红卫兵们批斗致死。我不知道这里大刘是否加了某种隐喻在里面，甚至直到写这篇读后感时，我才意识到，这里似乎是隐含了一种贯穿全书的很隐蔽的冲突：个别的精英人物对平庸的普罗大众的冲突，或者说，理性对感性的冲突。而叶哲泰的死，仿佛也暗合了这一系列冲突的结果：感性的胜利。书中的人类相较于三体人，很大的一个优势就是，他们会去爱，有更加丰富的情感，而不是冷冰冰的命令执行者，而类似于欺骗之类的其他特性，也可以说是情感的一种衍生品。这当然可以说是人类的幸运，但也注定了人类会走向的最终的悲剧。这不知道是不是一种过度解读，但是确实算得上一个巧合。

《三体》三部曲没有写成编年史的形式，而是每一部选取了一个或几个关键性的人物——第一部的汪淼、第二部的章北海和罗辑、第三部的程心，用很大的笔墨从这些人的视角，描绘整个大时代，很巧妙地用“休眠”这个特性，使得每个人物不仅仅可以参与一个很小范围（几十年）的事件，而能在一个更大的时间跨度上去参与历史。很可惜的是，很多小说花费大笔墨描写的、无数人的血汗换来的构思布局经营谋划，都被小说中一笔带过的休眠过程中所发生的种种情况，或是一些无足轻重（相对来说）的小事，轻描淡写地推翻破灭了，很有一种讽刺感。

人类最初和三体人对抗的情形，无疑是绝望的。智子对人类基础科技发展的锁死和对人类社会的监视，使得人类在与三体人的作战中不具有任何技术和战略上的优势。于是，人类利用自己唯一的优势：伪装和欺骗，开启了面壁计划。罗辑在领悟黑暗森林理论后将恒星 187J3X1 的坐标广播，并进入休眠等待理论的验证。然而罗辑没有在休眠中等到咒语被验证就被匆匆唤醒：太阳系舰队联席会议以全票通过的结果废除了面壁计划，于是人类丧失了唯一的优势。无数先人前赴后继耗资巨大的项目，因为那个时代人们的狂妄自大，完全化为了泡影。只有少数几个人意识到了不对劲，如丁仪：“我两个世纪前的人了，现在居然还能在大学里教物理。”

而面壁者雷迪亚兹的故事，就更为这种讽刺蒙上了一种悲情色彩。罗辑说：“四位面壁者都是伟大的，他们在战争一开始就看到了人类必败的结局。”然而不知道是否是大刘刻意安排的冲突，面壁计划就正好选中了这四颗世界上最聪明的脑袋，加上一个章北海，整部书中就只有这五个人对人类的未来具有最清晰最正确的认知。暂且不论这种安排的合理性，坚信人类必败的几人，最开始就知道他们只有两种选择，押上全部家底、摆出同归于尽的架势去威慑，或者逃亡主义。雷迪亚兹的计划，民众只聚焦在会毁灭地球这一个点上，而没有人去思考它的战略威慑意义。在计划败露后，雷迪亚兹回到了他热爱的祖国玻利维亚，被他亲爱的人民用石头砸死。雷迪亚兹死前在飞机上说：“人类生存的最大障碍其实来自自身”，这不仅是雷迪亚兹的悲剧的原因，也是整个人类悲剧的根源。雷迪亚兹的命运，有一种尼采的超人哲学的意味，而超人往往死于他们所保护的人。

不知是否是太阳系舰队全灭调高了人类的阈值，在罗辑继承了雷迪亚兹的计划，建立了类似的威慑系统后，面临着灭顶之灾的人类把他当作守护神。罗辑在威慑形成时与智子的对话中提到：“奇怪，我现在感觉自己不是人类的一员了”，在罗辑卸任执剑人时，人类甚至想以世界灭绝罪审判罗辑。然而，即使是罗辑几乎用命换来的威慑局面，也在区区六十年后，在有多名至少看起来是合格的候选人的情况下，被人类民主投票选出的新执剑人程心打破，人类在这场几十年的对峙中，率先放松了警惕。也诚然，相对于冷冰冰地、动动手指就能摧毁两个文明的罗辑，高颜值高学历亲和散发着母性光辉的程心，在这个女性化特质强烈的时代，显然是个比粗鲁的公元人更好的选择。

威慑失效后万有引力号代替程心发出了引力波广播，完成了威慑的最后一步，人类和三体人开始各自找寻存活的机会。托马斯维德建立的星环集团开始研究光速飞船，这项技术被联邦政府认定为逃亡主义而非法，人类害怕在死亡面前的不平等。维德唤醒了程心，于是星环集团被政府接管，维德也被处死。继承了章北海、希恩斯逃亡主义的最后一点尝试也宣告失败，人类最终难逃灭绝的命运，有远见有魄力的少数人最终覆灭于无远见的绝大多数人。

对《三体》的诸多评价，都痛斥程心为圣母婊，她的“圣母心”搞砸了两个可以挽救人类的计划。这自然是站在上帝视角的我们可以随意去评判的。但事实上，程心只是大刘描述的那个时代下，无数抽象的普通民众的一个具象化代表，换言之，是大刘专门立的一个靶子用来打的。不过程心算得上一位完美的圣母，程心的所作所为与所思所想是一致的，她的一切行为，都是心存善意的。在光粒打击误报时，她不愿意牺牲普通民众的性命换取她自己的存活。她的最大错误，也是认为心存善意就能解决一切问题。所以更严谨地说，程心是无数抽象的普通民众的善意的一个具象化代表，所以小说能展显的只是她的短视，而不是恶意。

水滴攻击地球前的混乱和广播纪元 8 年光粒打击的误报，则是整部小说中集中展现了人性的恶的一部分：人们为了不让假想的少数人逃离用激光手枪照射太空电梯，以及少数人为了逃离不顾其他人性命强行启动聚变发动机。无论是人性的善还是人性的恶，在大刘笔下似乎都没有带来什么很好的结果。

于是，托马斯维德说：“失去人性，失去很多；失去兽性，失去一切。”他只想“前进！不择手段地前进！”而民众往往不这么想，就像程心说的：“我选择人性。”他们看不到整体，只能看到眼前失去的东西。于是雷迪亚兹和维德都被人类处死了，泰勒被逼自尽，罗辑被妖魔化，程心成为执剑人，太阳系被二向箔拍成饼。大刘在暗戳戳地说：“你们这么人性，这就是下场。”

总的来说，在《三体》中，所谓的“民主”给我们带来了一个一个的笑话和恨铁不成钢感觉，让少数睿智但不懂得（或不屑于）讨好广大民众的人的呕心沥血的努力最终成了泡影，这算是对这种所谓的“民主社会”的一种很有感染力的讽刺。

可以联想到最近乌克兰的局势。当年乌克兰就是在民主的感召下，一步步地走到今天这步田地。在泽连斯基胜出的那场总统大选中，面对着有政治经验的波罗申科和毫无经验的喜剧演员，民众纷纷将票投给泽连斯基，大部分人的理由是他在他的喜剧中扮演了一名好总统。这是一个典型的例子：“西式”民主无法避免的政客明星化和民众的短视。大刘在另一部小说《中国 2185》中，设立了一位女主席，也是对“民主”下政客明星化的一个体现。

在《三体》的最后，在归零者要求归还小宇宙的质量以重启大宇宙时，虽然程心前脚还在说：“如果所有小宇宙中的人都那么想，那大宇宙肯定死了”，后脚就“还可以再留下五公斤吗，大宇宙不会因为这五公斤就不坍缩了”。最后是留了一个开放式的结局，没有说最终宇宙是否因为这些质量而死亡。小说自己也提到：“因为在那无数文明创造的无数小宇宙中，肯定有相当一部分不响应回归运动的号召”，所以最后宇宙很可能是陷入了沉寂，没能重启。大刘成功将人性的弱点扩展到了宇宙中不同文明的芸芸众生上。

有人认为大刘的黑暗森林理论是大刘对那场十年动乱中人与人之间关系的感悟，我不置可否。但是大刘笔下的人物，却展现出了人内在的神性、人性和兽性。神性体现在自我实现，如章北海、罗辑；人性体现在社会现实中人与人之间的妥协，即道德或者法律，如程心。而《三体》则直击兽性：生存永远是文明的第一要务。于是在黑暗森林中，人类因为人性得以存活，也最终因为不舍得抛弃人性陷入了毁灭。

人性没有错，大刘只是将血淋淋的现实抛了出来。他没有在讽刺谁，或者说，他讽刺了所有人。

6.5840 实验一 —— MapReduce

Thu, 20 Jan 2022 14:29:00 GMT

前言

实验一是要实现一个 MapReduce 系统，基本就是两个部分：实现 master 程序和实现 worker 程序。这个实验基本就是劝退怪了，一来是对 golang 的 rpc 和并发的使用要比较熟悉，二来就是要对 MapReduce 的整个流程机制要比较熟悉。其实有一个小秘诀，就是拼命看论文中的这张图，再拼命看下面的流程讲解：

mapReduce 执行流程

这个实验我实现了两个版本，主要是并发控制的方式有些不同。最初是基于 mutex 锁的版本，后来重构成了基于 channel 的无锁版本。无锁版本的实现比较优雅，所以讲解也主要基于无锁版本。

实验讲解

做实验之前，首先需要读懂实验。说明书在：https://pdos.csail.mit.edu/6.824/labs/lab-mr.html。主要这个实验需要在 Linux 环境下进行，因为进程通信基于 unix socket，MacOS 原则上来说也可以，但是据说还是会有些小问题。

代码中已经提供了一个单线程串行版的 MapReduce，代码在 src/main/mrsequential.go。这个版本很重要，建议先阅读一遍，可以大致了解整体的流程。有一些内容的处理也可以直接从中 copy。

并行版本的 master 程序入口在 main/mrcoordinator.go，worker 程序入口在 main/mrworker.go。实验需要实现的有三个文件，分别是 mr/coordinator.go、mr/worker.go、和 mr/rpc.go，分别描述了 master 的处理代码、worker 的处理代码以及它们之间通信的 rpc 结构。

mrcoordinator 会调用 mr/coordinator.go 中的 MakeCoordinator 函数，来构建 master 的结构，并启动 socket 监听，在返回后，主协程会不断调用 Coordinator.Done 方法，来检查是否已经完成整个 MapReduce 任务，确认完成后才会退出主协程。所以，在 MakeCoordinator 中，不应当有操作阻止函数返回，否则会阻塞后续操作。相关的监听等工作应当通过新协程实现。

mrworker 的处理就很简单了，只有一个主协程，直接调用了 mr/worker.go 的 Worker 函数，在这里处理即可。一般可以直接实现成单协程程序。

测试脚本为 src/main/test-mr.sh，它会将两个现成的 MapReduce 程序：wc 和 indexer 通过你的框架执行，并与串行执行的结果相比较。它同时还会检查并行运行相同的 Map 或 Reduce 任务、甚至 worker 执行任务期间发生 crash 时，最终是否能得到正确的结构。通常它会启动一个 master 进程和三个 worker 进程。如果在运行期间发生错误不退出时，可以通过 ps -A 命令，找到 mrcoordinator 进程的 pid，并 kill 掉即可。普通的 ctrl + c 可能无法完全退出，会影响后续的测试。

最后，请多阅读几遍实验指导书。

实现思路

整体流程

workers 会首先执行完 map 任务，生成很多中间文件“mr-X-Y”，其中，X 是 map 任务的 id，Y 是对应的 reduce 任务 id。接着 reduce 会收集所有 Y 等于 reduce 任务 id 的文件，读取并进行 reduce 操作，并将结果输出到“mr-out-Y”中。

master 实现

无锁思路

由于是一个无锁的实现，要避免多协程数据冲突，所有对主要数据结构的操作应当收敛到一个协程中，这里可以称为调度协程。在 worker 通过 rpc 请求 master 时，例如获取一个 task 或者汇报完成工作，master 会通过一个自动创建的协程处理 rpc 请求，由于对主要数据结构的操作已经收敛，这个 rpc 协程就必须通过 channel 要求调度协程代办，以保证没有数据竞争。由于 worker 和 master 之间可能有多种消息，这意味着调度协程必须同时管理多个 channel。这里可以运用 golang 的 select 结构：

// 只在这个 goroutine 中操作结构
func (c *Coordinator) schedule() {
    for {
        select {
        case msg := <-c.getTaskChan:
            c.getTaskHandler(msg)
        case msg := <-c.doneTaskChan:
            c.doneTaskHandler(msg)
        case msg := <-c.timeoutChan:
            c.timeoutHandler(msg)
        case msg := <-c.doneCheckChan:
            c.doneCheckHandler(msg)
        }
    }
}

假设这时候有一个 worker 需要获取一个 task 来执行，请求 master 的 GetTask，GetTask 处理如下：

func (c *Coordinator) GetTask(_ *GetTaskReq, resp *GetTaskResp) error {
    msg := GetTaskMsg{
        resp: resp,
        ok:   make(chan struct{}),
    }
    c.getTaskChan <- msg
    <-msg.ok
    return nil
}

在向 getTaskChan 中，不止传入了 resp（getTask 不需要请求参数），还传入了一个 chan struct{} 类型的管道，这个管道是协调协程用于通知 rpc 协程处理完成的通道：当处理完成后，就会向 msg.ok 中写入一个 struct{}，rpc 协程就会返回。

Coordinator

整个 Coordinator 结构如下：

type Coordinator struct {
    nMap    int
    nReduce int
    phase   TaskPhase
    allDone bool
 
    taskTimeOut map[int]time.Time
    tasks       []*Task
 
    getTaskChan   chan GetTaskMsg
    doneTaskChan  chan DoneTaskMsg
    doneCheckChan chan DoneCheckMsg
    timeoutChan   chan TimeoutMsg
}

phase 记录了当前任务执行的阶段，由于 reduce 任务必须在所有 map 任务结束后才能进行，所以 TaskPhase 分为 Map 和 Reduce 阶段，每个阶段中，tasks 切片只有对应阶段的任务。

taskTimeOut 记录了当前正在执行的任务的开始时间，会有一个协程定时去扫描这个 map，找出其中运行时间大于十秒的任务（超时），将对应的任务状态设置为未开始，以进行下一次调度。当然这个扫描操作也需要通过协调协程进行。超时 map 中也只有当前阶段正在执行的任务，在切换阶段时会清空超时 map。

tasks 切片保存了当前阶段所有的 Task，以及相关的状态：

type ReduceTask struct {
    NMap int
}
 
type MapTask struct {
    FileName string
    NReduce  int
}
 
type TaskStatus int
 
var (
    TaskStatus_Idle     TaskStatus = 0
    TaskStatus_Running  TaskStatus = 1
    TaskStatus_Finished TaskStatus = 2
)
 
type Task struct {
    TaskId     int
    MapTask    MapTask
    ReduceTask ReduceTask
    TaskStatus TaskStatus
}

这里可以看到任务的状态被分成三个，分别是待执行、执行中以及执行完成。同时冗余保存了 MapTask 和 ReduceTask，具体使用哪个结构体由当前阶段来判断。

具体操作

根据 Coordinator 中的管道，可以看出有四种情况需要和协调协程通信以进行操作。

当 worker 请求一个任务时，可能获取到的任务类别有四种：

type TaskType int
 
var (
    TaskType_Map    TaskType = 0
    TaskType_Reduce TaskType = 1
    TaskType_Wait   TaskType = 2
    TaskType_Exit   TaskType = 3
)

master 首先遍历所有的 tasks，找出其中的状态为未执行的状态，并根据当前的阶段，返回 Map 或者 Reduce 任务。如果当前没有空闲任务的话，又分为以下两种情况。当前为 Map 阶段，这时需要返回 TaskType_Wait 任务，要求 worker 等待，Map 阶段结束后还需要进行 Reduce 任务；当前为 Reduce 阶段，这时所有任务已经完成，返回 TaskType_Exit 要求 worker 退出。

当 worker 完成时，会通知 master 任务完成。传递的信息中会带有任务的类型和任务的 Id。master 会忽略掉非当前阶段的任务，根据 taskId 修改 tasks 中的任务状态为 finished（忽略当前任务状态，直接改为完成），并删除 timeout 中的对应结构。

func (c *Coordinator) doneTaskHandler(msg DoneTaskMsg) {
    req := msg.req
    if req.TaskType == TaskType_Map && c.phase == TaskPhase_Reduce {
        // 提交非当前阶段的任务，直接返回
        msg.ok <- struct{}{}
        return
    }
    for _, task := range c.tasks {
        if task.TaskId == req.TaskId {
            // 无论当前状态，直接改为完成
            task.TaskStatus = TaskStatus_Finished
            break
        }
    }
    // 删除 timeout 结构
    delete(c.taskTimeOut, req.TaskId)
    allDone := true
    for _, task := range c.tasks {
        if task.TaskStatus != TaskStatus_Finished {
            allDone = false
            break
        }
    }
    if allDone {
        if c.phase == TaskPhase_Map {

func (c *Coordinator) doneTaskHandler(msg DoneTaskMsg) {
    req := msg.req
    if req.TaskType == TaskType_Map && c.phase == TaskPhase_Reduce {
        // 提交非当前阶段的任务，直接返回
        msg.ok <- struct{}{}
        return
    }
    for _, task := range c.tasks {
        if task.TaskId == req.TaskId {
            // 无论当前状态，直接改为完成
            task.TaskStatus = TaskStatus_Finished
            break
        }
    }
    // 删除 timeout 结构
    delete(c.taskTimeOut, req.TaskId)
    allDone := true
    for _, task := range c.tasks {
        if task.TaskStatus != TaskStatus_Finished {
            allDone = false
            break
        }
    }
    if allDone {
        if c.phase == TaskPhase_Map {
            c.initReducePhase()
        } else {
            c.allDone = true
        }
    }
    msg.ok <- struct{}{}
}

如果是在 Reduce 阶段发现所有任务都完成了，还会设置一下 allDone 标志位。

Coordinator 在初始化时，还会启动一个协程，这个协程每秒请求一次协调协程，检查 timeoutMap 是否有超时任务，如果超时，就将其状态置为未开始，这样在下一次 worker 请求任务时就可以调度执行了。

func (c *Coordinator) timeoutHandler(msg TimeoutMsg) {
    now := time.Now()
    for taskId, start := range c.taskTimeOut {
        if now.Sub(start).Seconds() > 10 {
            for _, task := range c.tasks {
                if taskId == task.TaskId {
                    if task.TaskStatus != TaskStatus_Finished {
                        task.TaskStatus = TaskStatus_Idle
                    }
                    break
                }
            }
            delete(c.taskTimeOut, taskId)
            break
        }
    }
    msg.ok <- struct{}{}
    return
}

最后还有一个完成状态检查，是主线程调用 Coordinator.Done 进行的，请求协调协程时，只需要检查 allDone 标志位即可。

worker

worker 只有单个协程，循环从 master 处获取任务执行：

func Worker(mapf func(string, string) []KeyValue,
    reducef func(string, []string) string) {
    for {
        resp := callGetTask()
        switch resp.TaskType {
        case TaskType_Map:
            handleMapTask(resp.Task, mapf)
        case TaskType_Reduce:
            handleReduceTask(resp.Task, reducef)
        case TaskType_Wait:
            time.Sleep(time.Second)
        case TaskType_Exit:
            return
        }
    }
}

map 和 reduce 的操作，可以参考串行单线程的实现。有一点注意是，由于可能有多个进程同时执行同一个任务，也可能会出现执行到一半崩溃的情况，遗留下的文件可能会导致后续 worker 重新执行时发生错误。所以创建输出文件时，可以通过 ioutil.TempFile 函数创建一个临时文件写入，等到写入完成后通过 os.Rename 重命名为目标文件，这样即可保证最后的输出文件一定是完整的。

MapReduce 论文阅读

Sun, 16 Jan 2022 09:32:00 GMT

前言

MapReduce，是 Google 早年提出了一种软件架构模型，支持大规模数据集的并行运算。现在这个概念被运用在大量分布式系统中。

相关的理论由 Google 在 2004 年发表在论文《MapReduce: Simplified Data Processing on Large Clusters》中，可以在这里阅读全文。13 页的小论文，信息密度比某些小论文不知道高到哪里去了。

由于本文是边阅读论文边记录下来的笔记，所以内容可能比较混乱。

编程模型

MapReduce 是一个很简单的并行处理模型，使用 MapReduce 框架，用户只需要指定两个函数：

Map 函数，负责将一个键值对处理成一系列中间键值对
Reduce 函数，负责将所有具有相同 key 的中间值合并

剩下的，就由框架自行处理，包括数据分发、任务分发、错误处理、负载均衡等等细节。用户无需掌握这些细节，更能关注于业务逻辑。

一个大致的处理流程是这样的：

Map 接受一个输入键值对，产生一系列中间键值对。MapReduce 框架将所有具有相同的中间 key 的中间值组织到一起，传递给 Reduce 函数。Reduce 函数，接收一个中间 key 和一系列中间值，函数通常将这些值聚合成一个较小的集合，有时每次 Reduce 函数调用只会产生一个结果值，甚至不产生结果。

以大规模文本单词计数为例：

map(String key, String value):
    // key：文章名称
    // value：文章内容
    for 单词 w in value:
        增加中间计数 (w, "1")
 
reduce(String key, Iterator values):
    // key：一个单词
    // value：一系列计数
    int result = 0;
    for v in values:
        result += ParseInt(v);
    输出 (ToString(result))

实现

执行流程

MapReduce 作为一种编程模型或者说编程思想，实现方式可以有很多。Google 在论文中给出了一种实现方法，用于局域网内互相连接的大量机器。执行流程如下图：

mapReduce 执行流程

MapReduce 框架首先将输入文件划分为 M 片，每片通常为 16MB 到 64MB 大小。随后会启动集群中的机器（进程）。
集群中的一个进程是一个特殊的 master 进程。剩余的 worker 进程都由 master 分配任务。一共有 M 个 map 任务和 R 个 reduce 任务需要分配。master 会挑选空闲的 worker，一次分配一个 map 任务或者一个 reduce 任务。
被分配到 map 任务的 worker 读入对应分片的输入，从输入中解析出键值对，并分别将其传给用户定义的 map 函数。map 函数返回的中间键值对会被暂时缓存在内存里。
worker 内存中缓存的键值对，会被分片函数分成 R 个分片，并周期性地写进本地磁盘。这些键值对在磁盘上的位置会被发生给 master，master 负责将位置发送给被分配到 reduce 任务的 worker。
当一个 reduce worker 接收到 master 发送的这些位置，它会向保存这些内容的 map worker 发送 RPC 请求来读取这些内容。当一个 reducer worker 读取完所有的中间数据，就会将其根据 key 进行排序，这样所有相同 key 的数据就会聚合在一起。这种排序是必要的，因为通常许多不同的 key 会由同一个 reduce 任务处理。如果数据过大，可能会使用外部排序。
reduce worker 遍历有序的中间数据，对遇到的所有 key，都会将 key 和对应的值集合传给用户定义的 reduce 函数。reduce 函数的输出会被追加到一个最终的输出文件（每个 reduce 分片一个）。
当所有的 map 任务和 reduce 任务都完成后，MapReduce 的任务也就完成了。

运行结束后，MapReduce 的运行结果保存在 R 个输出文件中，通常这些文件会被用作下一个 mapreduce 任务的输入。

容错

这里只考虑 worker 挂掉的情况，不考虑 master 挂掉的情况，因为这可能涉及选举共识等复杂情况。

master 和 worker 会维持一个心跳，如果一段时间没有收到 worker 的回应，就会认为这个 worker 挂掉了。所有由这个 worker 完成的 map 任务都会被重新变成未开始状态，会被重新分配给其他 worker 执行。所有挂掉时正在进行的 map 或者 reduce 任务会被标记为未开始。

已完成的 map 任务需要重新执行是因为它们的结果存储在已经挂掉机器的本地硬盘上，而已经完成的 reduce 任务无需重新执行，reduce 任务的结果被放在全局的文件系统上。

如果一个 map 任务最初由 A 执行，后来 A 挂掉了，被重新分配给 B 执行，这个消息会被通知到所有执行 reduce 任务的 worker。所有还没有从 A 中读取数据的 reduce 任务会转而选择从 B 读取数据。

有时，会出现这种情况：部分机器的性能很低，但是由于网络通畅，不会被判定为挂掉，这种机器就会成为整个系统的短板，整个系统不得不等待慢速机器慢吞吞地执行完他们的任务。对于这种情况，Google 的实现采用的一种机制来提升：在整体 MapReduce 操作快要结束时，master 会将所有仍然在进行的任务分配给其他空闲的 worker 执行。无论是原来的 worker，还是二次分配的 worker 完成了任务，这个任务都算是成功完成。

性能提升与小优化小扩展略去。