Hi, 我是 W10N

魔法线路的一次重建 我有三条魔法线路，这周状态都不太好：炸掉了一条，另外一条流量超了配额，还有一条延迟很大。索性新建了一条顶上。 配置新线路的过程中，顺带发现之前配的延迟检测不准，干脆一起修了。这一修就牵出一串：kube-prometheus-stack 里 additionalScrapeConfigs 字段名写错了；把 R 线路上的 X 从 split-updown 架构切回了普通方案，本想验证问题是不是出在这个架构上，结果发现并不是；J 线路也重新调了一遍，接进了 Grafana 监控。 本来只是想补一条线路，结果顺手把观测这块积了一阵子的旧账清了一遍。 重新拾起 QuantDinger 重新研究 QuantDinger，顺带整理自己的 enx 项目。 隔了一段时间没跟，上游已经升了很多个版本，还有一次大版本更新——MT5 整个模块被删掉了，看代码仓库，主线现在主要在更新数字货币和股票相关的模块。我跟着更新了指标（indicator）相关的一批代码。 也跑了一单测试，赚了 0.02866，差不多两毛钱——这也算是有正向现金流了 -_-。 面试复盘 上一次面试还没有后续 比起纠结结果，我更想把遇到的问题梳理清楚。已经整理了一部分，下周找时间继续，从 blog 里挖了一些相关的文档再整理一遍，下周接着弄。 女儿的一支舞，和被传染的一家 上周提到女儿在排练一支舞，这周演出了。 她上的是小班，周五这场是幼儿园大班的毕业典礼，小班出了几个小朋友排练了一支舞蹈，去典礼上表演。表演当天她的状态不错——一周前感冒过，到那天体温已经正常一两天，算是在恢复中，只剩一点点咳嗽，不影响跳舞，整支舞完整跳完了。 感冒倒是在家里转了一圈。她把病毒传给了妈妈，周六晚上老婆开始发烧。那天我全天带娃在外面上课、玩，回到家就成了半个病房。我目前还好，没有中招的迹象——但也不敢太乐观。 周日的三件不相干的小事 周日修了三件事，彼此没什么关联，凑巧都在这天： 蓝牙：偶然发现开机后蓝牙不能自动启用，是 Linux 启动过程中的时序问题，调了一下。 时区：为了能在这台机器上用 Claude Code，把时区问题处理了。 tekton-pipelines：把 PodSecurity 放宽到 baseline，是为了能在 homelab 上部署 enx 的 Java API。 两个小工具上的调整 Running page 换了数据源：Strava 的 API 改成了订阅模式，就把数据源换成了 Keep。 装了 Squirrel（鼠须管）：macOS 自带的五笔输入法没有造词功能，换成了 Squirrel。

什么是 COSMIC COSMIC（“Computer Operating System Main Interface Components”）是 System76（Pop!_OS 的厂商）用 Rust + iced 从零重写的新一代桌面环境，用来替代 Pop!_OS 之前基于 GNOME Shell 深度定制的 Pop Shell。 Compositor：cosmic-comp，基于 Smithay（Rust 的 Wayland compositor 库），只支持 Wayland，不支持 X11。 UI 工具包：iced（Rust 原生 GUI 库），不依赖 GTK 或 Qt。 特点：内置类似平铺窗口管理器的窗口平铺/浮动切换，风格上介于 GNOME 的简洁与传统桌面（面板 + 应用列表 + 系统托盘）之间。 现状（2026-07）：Arch extra 仓库已提供稳定打包（当前 1.2.0-1），可通过包组 cosmic 一次性安装。 KDE Plasma 对比 COSMIC 维度 KDE Plasma COSMIC 实现语言/工具包 C++ / Qt + QML Rust / iced 显示协议 X11 + Wayland 双支持 仅 Wayland（cosmic-comp 基于 Smithay） 项目历史 1996 年至今，成熟度极高 2022 年立项，2024~2025 年逐步稳定，仍在快速迭代 窗口管理风格 浮动窗口为主，插件式支持平铺（如 KWin 脚本、Bismuth） 原生内置平铺/浮动切换，无需插件 可定制程度 极高：几乎每个组件（面板、快捷键、主题、特效）都可深度配置 目前较克制，配置项比 Plasma 少很多，走"够用即可"路线 默认发行版 Kubuntu、openSUSE、Arch 等（无绑定） Pop!_OS（System76 主推，未来默认桌面） 资源占用 中等，特效多时略高 更轻量，Rust 实现 + 无 Qt/GTK 依赖 应用生态 庞大（KDE Applications 套件：Dolphin、Kate、Okular、Konsole 等） 尚在建设中（cosmic-files、cosmic-terminal、cosmic-text-editor 等基础应用刚起步） 主题/外观定制 支持第三方主题、图标包、Global Theme 一键换肤 目前主题选择有限，风格由官方统一把控（类似 GNOME 的"少即是多"哲学） 登录界面集成 SDDM（KWallet 自动解锁等深度集成） cosmic-greeter（greetd），风格与桌面统一，但生态集成不如 SDDM 成熟 适合人群 想要高度自定义、功能全面、多年验证的稳定桌面 想尝鲜 Rust 生态新桌面、偏好简洁一致设计、愿意接受少数功能还不完善 一句话总结：Plasma 是"功能全面、可深度定制"的成熟老牌桌面；COSMIC 是"简洁统一、技术栈新颖"的年轻桌面，目前更适合尝鲜和轻量使用，还不建议完全替代 Plasma 作为主力日常桌面。 ...

macOS Apps 跨平台常用软件统一维护于 my apps，本文只记录 macOS 专属工具。 说明 brew — brew install <name> cask — brew install --cask <name> Essentials 跨平台工具见 my apps，以下为 macOS 专属推荐： app install notes iterm2 cask:iterm2 功能强大的 terminal stats cask:stats 任务栏系统资源监控 itsycal cask:itsycal 任务栏日历（显示周数） tunnelblick cask:tunnelblick OpenVPN GUI 客户端 Logi Options+ cask:logi-options-plus Logitech 键鼠配置工具 Ice cask:jordanbaird-ice@beta 菜单栏图标管理、隐藏与分组 Input Method app install notes 豆包输入法 — AI 语音输入，详见 豆包输入法 Squirrel（鼠须管） cask:squirrel RIME 引擎输入法，详见 Squirrel（鼠须管） brew install --cask doubao 安装的是豆包 AI 聊天客户端，不是输入法。 Productivity app install notes CleanMyMac X — 系统清理（官网购买） Bob cask:bob 翻译/词典 Shottr cask:shottr 截图+标注+OCR，轻量快速 Monosnap cask:monosnap 截图+标注 RealVNC Viewer cask:vnc-viewer 远程桌面 Terminal app install notes iterm2 cask:iterm2 macOS 最流行的 terminal VPN app install notes Tunnelblick cask:tunnelblick OpenVPN GUI，macOS 专属 Graphics / Design app install notes Sketch — 矢量绘图（官网购买） References Homebrew 维护记录 时间 修改内容 原因 2026-07-09 新增 Squirrel（鼠须管）输入法条目及安装/五笔配置说明 补充 RIME 输入法方案，与豆包输入法并列 2026-07-10 豆包输入法、Squirrel（鼠须管）详细内容拆分至独立文档；移除 Productivity 中重复的 Itsycal、Stats 条目；将 my apps 站内链接改为相对 .md 路径 保持本文简短，避免重复推荐，并统一站内链接写法

本文记录这个博客的搭建方式，从买域名到发布一个静态站点。技术选型和步骤与本站的实现保持一致。 这套技术栈长什么样 一句话概览：用 Hugo 把 Markdown 编译成静态页面，源码在 GitHub，Cloudflare Pages 连接 GitHub 仓库并在 Cloudflare 侧构建、托管，域名解析和 CDN 也在 Cloudflare。 各部分的分工： 组件 作用 Hugo 静态站点生成器，把 content/ 下的 Markdown 编译成 HTML GitHub 存放源码，作为部署的触发源 Cloudflare Pages 连接 GitHub 仓库，执行 hugo --minify 构建并托管产物 Cloudflare DNS 域名解析，把自定义域名指向 Pages 项目 Cloudflare CDN 边缘缓存与加速，Pages 默认自带 整个流程没有用 GitHub Actions，也没有容器化构建，构建这一步完全由 Cloudflare Pages 在它自己的环境里完成。基础站点的构建命令就是一句 hugo --minify；本站为了顺带生成搜索索引，把它包成了一个很短的脚本（见下文进阶模块），思路一样。 基础模块 这一部分从 0 到「能访问」。 买域名 域名可以在任意注册商购买，我最早是在 GoDaddy 买的。以 GoDaddy 为例： 打开 godaddy.com，在搜索框里输入想要的域名，看是否可注册。 选一个后缀（.com、.dev 等），加入购物车，结账。注意第一年常有促销价，续费价通常更高，下单前看清续费价格。 结账时可关掉 GoDaddy 自家的一堆增值服务（邮箱、隐私保护等），后面把 DNS 切到 Cloudflare 后这些大多用不上。 Cloudflare 自己也能直接注册域名（Cloudflare Registrar，按批发价、免费 WHOIS 隐私保护），但支持的后缀有限。如果想要的后缀在它的列表里，直接在 Cloudflare 买、省去后面改 Nameserver 的步骤也可以；后缀不在列表里就按上面的思路在别的注册商买，再把 DNS 切过来。 ...

在 Cloudflare 后台点几下就能建好一个 Pages 项目、绑好域名。想把这些配置变成可版本化、可复现的代码，就用 OpenTofu 来管理。本文只讲 Cloudflare 场景的具体写法，Provider、Resource、State 这些基础概念见 OpenTofu 入门。 目标 用 OpenTofu 声明式地管理三样东西： 一个连接 GitHub 仓库的 Cloudflare Pages 项目（含构建命令、产物目录、环境变量） 项目绑定的自定义域名 指向 Pages 的 DNS 记录 准备 需要两个 Cloudflare 侧的标识和一个 API Token： 变量 从哪来 Account ID Cloudflare 后台任意页面右侧栏，或 Workers & Pages 概览页 Zone ID 域名的 Overview 页面右侧栏 API Token My Profile → API Tokens → Create Token，授予 Pages 编辑和 DNS 编辑权限 Token 属于机密，不要写进代码，用环境变量注入： export TF_VAR_cloudflare_api_token="your-token-here" Provider 配置 terraform { required_providers { cloudflare = { source = "cloudflare/cloudflare" version = "~> 4" } } } variable "cloudflare_api_token" { type = string sensitive = true } variable "account_id" { type = string } variable "zone_id" { type = string } provider "cloudflare" { api_token = var.cloudflare_api_token } Pages 项目 cloudflare_pages_project 对应后台的一个 Pages 项目，source 块声明连接哪个 GitHub 仓库，build_config 对应构建命令和产物目录，deployment_configs 里可以设环境变量（例如 HUGO_VERSION）。 ...

女儿上幼儿园的情绪课 这周女儿在排练小班毕业表演，舞蹈动作有点难，加上分离焦虑，早上去幼儿园成了每天要过的一关。周一那天她抗拒得厉害，做了近一个小时心理建设才送进去，迟到了一小时。 我试着用她熟悉的东西帮她面对情绪。她在玩《星之卡比》，一开始连第一关的兔子都怕，现在已经把卡比的装备升到四级了。我就问她：现在还怕第一关的兔子吗？她说不怕了。我说幼儿园跳舞也一样，你手里的"冰淇淋"（舞蹈道具）现在是几级装备？她说是一级。我说今天带着它去跳舞，明天就升到二级，跳舞就没那么难了。她点点头，跟妈妈说了再见，蹦蹦跳跳去幼儿园"升级装备"了。 后面几天肉眼可见地在进步。周三到门口离开妈妈还会有点不开心，安抚一会儿就自己跑进去了。周四早上我在路上问她冰淇淋几级了，她说二级；我说今天再升一级，她纠正我：不对，上午能升一级，下午还能再升一级。大概她的神经网络已经把跳舞和打怪升级关联起来了。 比起替她扛下情绪，更想让她自己有面对情绪的办法。这套比喻能不能一直管用不好说，但这周是有效的。 周六全天带娃，出门时她的"小怪兽钱包"里有些现金。到星海广场，她自己花十块买了一袋海鸥食，又花三十坐了小火车，接着想玩旋转木马，翻钱包发现只剩十三块六了。她开始琢磨：游乐场都是收费三十吗？我说我们去找找十三块能玩哪个。绕了一圈，路过一个转飞船的场地，工作人员大姐答应十三块让她上去坐一圈。让她花自己的压岁钱，她就开始比较各种东西的价格了。 求职 周二收到了一家公司的面试邀请，周五去参加，过程还算顺利，有些问题答得还好，有些答得一般。目前结果未知。 咖啡：蒸气奶测试 某天中午送老婆去公司后，我又带电脑在她楼下的星巴克找了个座位。那天出门晚，担心喝咖啡影响睡眠，又不好久占座位，翻了半天菜单，看到一项叫"蒸气奶"。跟 AI 确认了一下，蒸气奶大致等于拿铁去掉咖啡。之前喝拿铁不会触发乳糖不耐，蒸气奶应该也安全。选项里有牛奶也有燕麦奶，我选了普通牛奶——顺便测试一下：蒸气乳化的过程据说能分解一部分乳糖，气泡也可能减缓乳糖进入肠道的速度。结果跟之前喝拿铁一样，喝完没有触发乳糖不耐的症状。

enX GitHub 仓库：wiloon/enx 开发环境 vscode 本地测试 在 Chrome 里打开 Manage Extensions: chrome://extensions/ Reload enX 在 Chrome 里打开 InfoQ 里任意一篇文章 点击扩展栏里的 enX enX 会标记文章正文部分的英文词 unit test cd /Users/wiloon/workspace/projects/enx/chrome-enx npm run test -- infoq.test.js deploy api to local vm commit and push enx to GitHub go to jenkins run deploy env DNS: 192.168.50.1:53, dnsmasq Nginx: 192.168.50.130 api: 192.168.50.36:8080 https://github.com/wiloon/enx/blob/main/enx-api/deploy.sh 维护记录 时间 修改内容 原因 2026-07-01 顶部加 GitHub 仓库链接 供 open-source-dictionaries.md 站内链接跳转到本文后，能继续跳到 GitHub 仓库

enx 加 Java 后端 最近投了 Java 方向的职位，这段时间在回忆和熟悉 Java/Spring，也在整理 blog 里之前攒下的资料。但只看文档、不动手，理解很有限。过去做 Java 项目时训练过的"生物神经网络"痕迹应该还在，细节被修剪掉了，主要的连接还在，得花点时间把细节重新接上。 enx 是我写的一个英文学习工具，也是技术栈的 playground。这周给 enx 加了一个 Spring Boot 后端，把一个简单的 API 迁了过去，依赖走 Homelab 里的 Nexus Maven 私服，构建和部署接到现有的 Tekton + k8s 流水线上：推代码后 Tekton 自动打镜像、更新到集群。这样一个最小闭环先跑起来，后面再慢慢补。 梳理 Java/Spring 文档 接着 W25 的节奏，继续整理 blog 里的 Java 文档，这周重心移到 Spring 和 JVM 周边。大脑像是索引和内存，blog 像是外部存储；脑子里的东西大概是 blog 内容的一个子集加上索引，有交叉，但也不是所有东西都写进了 blog。整理的过程就像是顺着索引把外存里的细节重新梳理一下。 这几个文档是本周动过的，方便以后自己回溯：classloader、Spring IoC 与 Spring Boot、graalvm native image、HotSpot，以及顺手补的 SPI / ServiceLoader 和 YAGNI。 公司：领照、刻章、开户 W24 注册了公司，这周把领营业执照、刻章办了，银行开户排到了下周。本来 6 月 24 日计划去领照，车启动打开导航才发现当天大连有达沃斯论坛限行，只好折回，在家准备面试和注册材料。第二天才正式跑完一圈。 ...

本文是一条故障记录。 最近两天 wiloon.com 看起来像是“停更”，停在6月28号。但其实 blog 仓库是有更新的，也提交了，只是没能发布出来——博客有大约两天卡在一次构建失败上，而我自己一直不知道。 不是停更，是没发布出去 现象很简单：本地写好、git push 之后，wiloon.com 上看不到新内容。一开始我以为是 CDN 缓存或者部署延迟，没太在意。后来才发现是构建一直在失败——新提交根本没被发布出去。 怎么坏的 原因是文章标题里的一个冒号。 博客用 Hugo，文章开头的 front matter 是一段 YAML。我有几篇 Java/Spring 的文章标题是英中混写的，里面带了「冒号 + 空格」，比如： # breaks the build: ": " makes YAML parse it as a mapping title: Spring WebFlux: 响应式 Web 框架 在 YAML 里，: （冒号加空格）是 key/value 的分隔符。没加引号时，解析器会把这一行当成一个嵌套映射来读，于是报错、Hugo 构建中止。一篇的 front matter 解析失败，整站就一个页面都不生成。 修复其实只要把整个标题值用引号包起来： # fixed: quote the whole value so the colon is just text title: "Spring WebFlux: 响应式 Web 框架" 加上引号之后，构建立刻就恢复了。 ...

上一份工作在一家外企。公司近期裁员，我的 last day 是 2026 年 4 月 24 日。公司给了数月赔偿，算是接下来一段时间的生活缓冲。 公司曾宣布全球裁员约 4000 人；大连这一轮是老板加员工、整个项目分批裁，我认识的就有 20 多人；其它组、其它部门也有裁员，具体人数不详。 裁员之后，我计划着继续或者回归远程工作这条路线。四年前就想找一个远程职位，但当时有朋友推荐，进了本地的这家外企；公司推行混合办公，每周有 N 天可以在家远程，也算一定程度体验过远程工作。 最近偶尔有朋友推荐大连本地职位，我也投了几家——理想的 offer 还没落定。 一个问题 早上跑完步，在回家的路上，想到一个问题： 裁员之后，下一个理想的 offer 还没落定——我是不是应该趁这段缓冲期，测试一下：我自己加上 AI，能不能创造出一些价值（赚到钱）？ 不一定默认回到「找工作 / 打工」这种状态。 为什么叫 Exploration 回到家，我打开 TickTick（一个待办应用），新建了一个"倒数日"——从 last day 起，记录这段日子过去了多少天。 给这个"倒数日"取名时，直觉想填「失业」——字面上没错，指的就是「裁员到下一个 offer 之间」这段日子；但是看起来有点奇怪：它只描述 失去什么，不描述 要做什么。 后来选了 Exploration。每天打开 TickTick，能看到日期的累加；这个词中性一些，也更贴近我接下来想做的事——不是停在「没了什么」，而是试着看看「我 + AI」能做出什么。 实验要回答什么问题 我能不能在真实场景里创造价值？（不只是写 demo，而是有人愿意用、能省时间、能复用。） 这种价值能不能部分转化成收入？（工具、咨询、小产品、开源项目的可持续性等。） 若答案偏 yes，是否足够支撑日常开销？ 如果几个月后数据不好看，再去找工作也不迟。 已有的小实践 帮一位朋友开发了一个文档格式和内容的批量校验工具——过去同类文档的人工核对要花几小时，现在批量跑一遍只要几秒，后续项目也可以复用。 这事说明： 几小时级别的投入，可以节省别人未来 N 个小时的时间； 场景是真实的、可交付的，不是玩具； AI 在这里是搭档，负责生成和迭代，我负责需求、验收和边界。 这是这段探索里第一个可以写进笔记的点。 接下来的方向 缓冲期有限，我会按「可演示、可复用、能记账」来排优先级，而不是散点学技术。 贴近真实需求、容易形成复用 继续找真实需求里规则清晰、重复劳动多的环节（校验、一致性检查、格式处理等），做类似「几小时 → 几秒」、可复用的小工具。 自己的长期项目 开源项目：ENX 等 —— 在 runway 内推进到能讲清「对谁有什么用」。 若干私有仓库里的想法 —— 验证能否形成稳定用法，或小规模地「创造价值」。 每周复盘 这周创造了什么？（钱、省下的时间、可演示的功能、开源进展都算，但要写实。） 哪件事离「可重复」最近？ 下周只押注一件事是什么？ 和「找工作」之间的关系 若这几个月能证明「自己 + AI」可以持续交付价值，甚至覆盖一部分生活成本，就多一条值得走的路线；若证明不了，履历和作品集也会更清晰，回去职场同样是加分项。 ...

这篇周记是在 W25 补写的——W24 周末两天全天带孩子，没有空闲时间写。 咖啡店 WiFi 与 Netbird 6 月 6 日，周末，外面下雨，家里嘈杂(娃没法出去玩)，早上出门找了家本地连锁咖啡店。连上 WiFi 之后发现网络有点不对——不开 WireGuard 时网页响应很快，一开 WireGuard 就开始严重丢包。初步判断是咖啡店的网络对 UDP 有限制，可能是为了防止 P2P 下载之类的流量。 这一折腾就是一整天。WireGuard 走不通，魔法工具也依赖家里 HomeLab 的出口，整个链路都受影响。换运营商热点、尝试不同连接方式，绕了一圈之后结论是：需要一条在 UDP 被封时能自动回退 TCP 的内网穿透方案。 最终选了 Netbird。P2P 优先，UDP 不通时自动走 TURN relay，可以走 TCP 443。同时支持 Subnet Router，HomeLab 里只需要一台节点宣告内网网段，不必给每台机器装 client。详细的部署记录见 Netbird 自建笔记。 另一件顺带记录的小事：不同咖啡店的拿铁，各家的成分不同，对乳糖不耐体质的影响有明显差异，这个已经单独记录了一下：星巴克拿铁 vs 独立咖啡店。 Giscus 评论区 6 月 9 日早上打开邮件，收到了一个 GitHub Issue 通知——上一家公司同项目组的前同事，给我的 blog 仓库提了个 issue，希望我加一个评论区。挺有意思的，前东家大裁员、项目解散已经将近一个月了，结果还能从老同事那收到"需求"。只不过这次没有 PID（项目 ID），让我有点恍惚，感觉像是又收到了项目上的客户反馈。 最后选了 Giscus，基于 GitHub Discussions 实现，隐私和管理都在自己手里。集成过程大部分可以自动化，只有 Giscus 的 category ID 需要手动获取。 ...

本站主要是个人使用的读书笔记，因为早期使用了 Wordpress 所以申请了域名，转到 Github + Markdown 后也保留了公开访问， 本人使用频率比较高的技术文档都有仔细整理和验证过，希望能帮助到有需要的同学。当然……也有大量的转载未整理的内容，在不断完善整理中…… 这个文档的由来 2021 年我参加了电鸭社区的英语练习俱乐部。当时教练 CJ 看了我的 blog，问我：「这些文档都是你自己写的吗？」我说不是，主要是我收集的技术资料，是我接触过的知识的一个集合。CJ 建议最好加一篇说明，写清楚哪些内容是转载的、哪些是自己写的，免得被人误会成抄袭。于是我就写了现在这个文档。 感谢 CJ。写之前我确实缺少版权意识，后来也更注意引用来源和共享协议了；下面三节按 front matter 里的 tags 划分：reprint、remix、original。 收集综合症/转载（tag: reprint） 基本上是我接触过的知识的一个集合 大部分内容是转载的 70%+ 一般第一次接触的知识会找质量比较好的或者能解决问题的文档收集进来 有一部分原因是防止源站消失（比如……已经消失的一个站点http://www.yining.org/2010/05/04/http-get-vs-post-and-thoughts/），还有方便查找，省掉重新 Google 的过程 有仔细读过的会修正 typo 日常遇到问题会逐渐整理，也会补充其它引用来源 有明显整理痕迹的都是仔细读过的，比如有段落标题，有代码语法高亮 会有合并摘抄 一个文档可能有多个引用来源，对同一个问题也有可能有相互矛盾的来源，会补充验证后的结果 前期不太注意知识共享协议，最近在有意识的识别有共享协议的文档并按协议转载 没有明显的知识共享协议的文档会逐渐转移到私有仓库 Obsidian + AWS S3 转载内容的 Author 会标记为 “-” front matter 的 tags 含 reprint（旧文仍在逐步补标） 会不定期删除本人使用频率低的内容，比如早期接触过的 ASP.net, Wordpress, PHP…… 本站点对应的 GitHub 仓库：https://github.com/wiloon/blog 转载内容有侵权可以随时联系我删除 整理过的（tag: remix） 在转载的基础上整理过的 记录了一部分常用的命令 平时经常使用的工具、命令、脚本，使用过程中遇到问题，解决问题的过程中会频繁修改，会补充命令的示例 一般会有语法高亮 有段落标注 可能有 N 个引用来源 front matter 的 tags 含 remix — 逐渐整理中，要花些时间从收集的文档里捞出来。 日常记录（tag: original） 少量的原创或原创比例比较高的文档 日常遇到的问题和解决过程 2026 年 5 月起写原创日常记录，从 exploration 开始；之后改为周记，记录每周做了什么；目前偶有延迟，目标是尽量每周一篇，能不能持续还在试，尽力而为 周记也算日常记录这一类 front matter 的 tags 含 original — 逐渐整理中 Author 会标记为 “w1100n” Blog 实现 Markdown GitHub GitHub Action Hugo PaperMod theme Cloudflare Pages 关于我 王越 ...

本周一（6 月 16 日）补写了 2026 W24 周记。下面记 W25 自己的事。 投递邀请与简历准备 6 月 15 日收到一份投递简历的邀请。这周主要修改简历和可能的面试准备，homelab 改造、公司刻章之类都先往后放。 写简历时沿用平时写代码、写 blog 用的 SDD 思路：先和 AI 写一份 spec，对照旧简历与新职位描述列出差异；再按差异到个人 profile 里挖过往项目的故事；回到 spec 标注每条差异可以引用哪些素材；最后让 AI 根据 spec 生成新一版简历。因为此前投过类似方向的岗位，很多段落可以复用，这个流程既有结构又省时间。6 月 17 日跟前同事聊 AI 用法时，才突然意识到 SDD 不只适用于代码和文章——简历同样适用。 挖素材的过程中，我把一些早年做过但没在简历里展开的项目重新整理成文，例如 车联网平台第三方数据推送集成。有些事只是做过、学过，和跟别人讲过一次之后，大脑里留下的关联是不一样的；输出过一遍，需要的时候更容易想起来。 PDF 导出是另一条线。以前用 VS Code / Cursor 的 Preview 在浏览器里打开再打印 PDF，软件更新后这条路走不通了。跟 AI 聊了几轮，第一次正经用排版工具链：Markdown 经 Pandoc + XeLaTeX 出 PDF，定制了 LaTeX 模板和一键脚本。流程稳定后另写了一篇技术记录：Markdown to PDF: Pandoc + XeLaTeX 简历导出实践。 看职位描述时还记下一个概念 Speed over Perfection，顺手写进了 agile 笔记。 梳理 Java 文档 简历主体定稿后，重心转到 blog 里攒了很久的 Java 笔记。这次投的是 Java 方向，正好借机把零散文章理顺：拆大篇、补版本脉络、把 JVM 和 HotSpot 分开写。日历上这几天和简历收尾有重叠，但主线已经换成「整理文档」。 ...

背景 我把自己的职业和生活当作一人公司来经营（详见 一人公司：我对个人运营的理解），公司运营本质上就是个人运营。我需要一个看板工具来管理： 日常任务和待办事项 项目进度追踪 个人运营规划 我熟悉 Jira，也知道 Trello，但想在选型时认真考虑 AI 集成能力（MCP/CLI/API），因为工作流中越来越多地用到 AI 工具。 候选工具 排名 工具 AI/MCP 集成 UI 直观度 适合一人公司 1 Linear 官方 MCP server，REST API 完善 极简优雅 ✅ 2 Notion 官方 MCP server，API 完善 灵活但需配置 ✅ 3 Height API + 内置 AI 功能 现代，接近 Linear ✅ 4 Todoist 社区 MCP，REST API 简洁直观 ✅ 5 Obsidian 社区 MCP 插件，本地控制好 Markdown，需适应 ⚠️ 6 Trello 有 MCP，API 可用但功能有限 看板直观 ⚠️ 7 Jira Atlassian MCP，API 完善 功能丰富但偏重 ❌ 8 Things 3 几乎无 API 最美 macOS 体验 ❌ Linear vs Jira 详细对比 日常使用笔记见 Linear 使用笔记。 ...

今天在大连一家本地连锁的咖啡书店里点了杯热拿铁，喝完跑了两次卫生间。 我知道自己有乳糖不耐，但喝星巴克的热拿铁从来没出过这种事。之前也没深想过原因，甚至隐约觉得可能是牛奶和咖啡一起喝进去，咖啡能有某种神奇的作用帮助身体分解乳糖。今天的事完全排除了这个猜测——同样是热拿铁，星巴克没事，这家本地连锁却出了问题，咖啡本身不是变量。 直到坐在商场卫生间的隔间里，我打开豆包问了这个问题：为什么喝星巴克拿铁从来没有乳糖不耐的症状，换成本地连锁就拉肚子？ 豆包的回答给了一个方向，但经过进一步推敲，实际情况比那个答案复杂一些。 豆包的答案：高温分解乳糖 豆包的解释是：核心原因在于奶源和灭菌工艺。星巴克用的是 UHT 超高温灭菌乳（135°C 瞬时高温），高温把乳糖部分裂解成葡萄糖和半乳糖，不需要肠道乳糖酶分解，大幅降低了乳糖不耐的刺激。而独立小店多用 72~85°C 低温巴氏鲜奶，乳糖完整没有拆分，乳糖酶不够就直接进大肠发酵，出现腹胀腹泻。 这个解释方向没有错，但"大幅降低"四个字有些夸大。 UHT 到底分解了多少乳糖 UHT（超高温灭菌）是牛奶工厂的一种生产工艺，用 135°C 瞬时高温灭菌后无菌灌装，出厂就已经是这种状态，星巴克采购的就是这种奶。店内的蒸汽棒打发是另一道工序，两者是不同阶段的事。 UHT 工艺的主要目的是灭菌，高温对乳糖的裂解只是附带效果。原料鲜奶的乳糖含量约为 4.8g/100ml，经过 135°C 超高温灭菌处理后，降至约 4.24.5g/100ml，实际只降低约 515%——和处理前相比差距不大，远不是低乳糖奶。 相比之下，真正的零乳糖奶（酶解奶）是在生产时专门加入乳糖酶把乳糖水解掉，乳糖含量降至 0.1g/100ml 以下，两者完全不是一个量级。 蒸汽打奶是制作拿铁的标准工序，星巴克和本地连锁都会做这一步，区别在于工艺细节：星巴克有标准化 SOP，要求将牛奶加热至 6065°C，控温严格；本地连锁则因咖啡师经验和设备不同，打发温度和时间差异较大，有的偏低有的偏高。但无论哪家，蒸汽棒温度约 100°C，牛奶实际温升只到 6070°C，靠热力裂解乳糖的效率极低，这个阶段乳糖含量再降约 13%，从约 4.24.5g/100ml 降到约 4.0~4.4g/100ml。 两个高温环节加起来，总共也只降低约 10~20% 的乳糖。 那为什么星巴克真的没问题 把个体变量排除之后，问题变得更清晰：我喝星巴克也有空腹的时候，喝的速度大概固定，星巴克和本地连锁都是热拿铁、都有咖啡因，这些都不是造成差异的原因。 真正的差异来自两点，而且可以量化。 以中杯（约 470ml）为例估算： 场景 液态奶 乳糖浓度 总乳糖 星巴克（奶泡约 25%） ~350ml 4.2g/100ml ~14.7g 本地连锁（奶泡约 10%） ~423ml 4.8g/100ml ~20.3g 两杯相差约 5.6g 乳糖，差距来自两个因素： 星巴克拿铁的奶泡厚，约占杯子体积的 25%，实际喝进去的液态奶少了约 73ml，对应少摄入约 3.1g 乳糖，占两杯总差距的 56%。本地连锁奶泡薄，实奶加得多，乳糖总量就上去了。 另外，星巴克用的 UHT 奶乳糖浓度本身略低于巴氏鲜奶，同等奶量再节省约 2.5g，占差距的 44%。 ...

上次在同一家店点热拿铁，喝完跑了两趟卫生间。有那次教训，这次我改点了冰美式。同样是浓缩咖啡，少了一大杯奶，身体反应却完全不一样：心跳明显加快，有点「突突的」，但脑子又格外清醒，整理思路时顺得多。我一个月大概只喝一两次咖啡，耐受很低，所以对这类变化格外敏感。 冰美式为什么比拿铁更「冲」 直觉上，拿铁和冰美式用的都是浓缩，咖啡因剂量差不多，体感却差很多。查下来，差别不只在「有没有奶」，还在奶怎么拖慢吸收。 两者看起来都是液体，但胃并不把它们同等对待——排空快慢不只看是不是液体，更看营养负荷。冰美式几乎是清液体，排空快；拿铁里大量牛奶含脂肪、蛋白质，整体在胃里停得更久。具体机制我写在文末补记。 拿铁里大量是牛奶。脂肪、蛋白质（主要是酪蛋白）和乳糖都要在胃里消化一阵，胃排空变慢，混在其中的咖啡因也就跟着滞留在胃里，再分批进入小肠。咖啡因主要在小肠吸收——所以「拿铁里有牛奶，小肠吸收咖啡因会慢一些」这个理解是对的：慢的不只是牛奶本身，而是咖啡因随拿铁一起在胃里多停了一会儿，进入小肠的批次更分散。 整体像缓释：血液里咖啡因浓度升得慢，峰也没那么陡。冰美式则几乎是浓缩加水加冰，胃很快把它送进小肠，咖啡因进血液也快。药代动力学里会讲达峰时间（Tmax）更短、峰值（Cmax）更高；落到体感上，就是更猛、更突然的一下。 上次写拿铁那篇 里提到过，厚奶泡也会轻微延缓胃排空，让乳糖分批进小肠——机制和这里同一类，只是拿铁里奶更多，对咖啡因的「拖慢」更明显。 还有一个个人的因素：我这次是正常速度喝完的，但冰美式比热拿铁好入口，同样时间内进肚子的量还是会多一些，单位时间里的咖啡因也会更集中一些。 补记：拿铁和美式的胃排空为什么不一样 正文里把差异概括成「拿铁在胃里停更久、咖啡因进小肠更慢」。事后我又查了查：为什么两种都是液体，胃排空却会不同？ 胃更像带阀门的缓冲池，不是漏斗。排空快慢不只看形态，更看进入十二指肠的营养负荷。Horowitz 等人的综述（The Gastrointestinal Tract as an Integrator of Mechanical and Hormonal Response to Nutrient Ingestion）里提到：非营养性液体排空快，热量越高排空越慢——不是被动漏下去，而是胃在调节向小肠输送的速率。冰美式主要是水、浓缩和冰，几乎不含脂肪和蛋白质，热量很低，十二指肠负担小，胃很快就把它送下去。拿铁里大量牛奶含脂肪、酪蛋白和乳糖，食糜进入十二指肠后，会通过激素和神经反馈让胃慢下来——脂肪的影响尤其明显。所以差别主要不是「液体一定比固体快」，而是清液体和含营养素的液体，在排空速率上就不一样；蛋白奶昔也是液体，照样可以排空很慢。 这也纠正了我一开始的一个误解：不完全是「牛奶必须先消化完，咖啡因才能走」；更准确的说法是，含奶的拿铁会触发十二指肠对胃的负反馈，整体排空被调慢，混在其中的咖啡因也就更晚、更分批地进入小肠。和我「拿铁里有了牛奶，小肠吸收咖啡因会慢一些」的直觉是一致的。药代研究里常用咖啡因吸收来反映胃排空：Koziolek 等人 2023 年（Pharmaceutics）观察到，空腹时咖啡因随液体较快进入小肠；若与食糜混合，胃内停留延长，吸收达峰也会变慢——拿铁和冰美式的差别，可以在这个框架下理解，虽然我没有找到专门针对这两种饮品的对照实验。 相关阅读 为什么我喝星巴克拿铁没问题，换成本地连锁却会乳糖不耐

背景 2020 年前后，我在大连 R 公司负责车联网平台协议解析层的开发和维护。R 平台是一套部署在公有云上的 IoT 平台，接入大量在线车载设备，实时处理车辆上报的行车数据。 那时平台有一项新的合作需求：一家做共享汽车业务的公司（以下简称 M 公司）采购了 R 公司的车载设备，安装在共享汽车上，希望通过接口从 R 平台获取这些车辆的实时行车数据，再通过自己的 App 提供给用户查询车辆状态和行驶记录。 我负责这次集成的开发工作，包括改造行车数据服务的分流逻辑，以及独立开发一个面向 M 公司的数据推送服务。这也不是我第一次做类似的事，R 平台之前也有过给其他第三方提供数据接口的项目，但 M 公司是其中规模比较大的一家。 技术方案 行车数据服务本身改动不大。原来的逻辑是收到设备上报的数据后直接写入平台内部各个下游。这次只是加了一段分流逻辑：根据车辆底盘号（VIN）查询 Redis 中的客户映射关系，如果这辆车属于 M 公司，就把这条数据额外发送到一个专用的 Kafka topic。 Kafka topic 的另一侧是我新写的 Go Kafka consumer，消费消息后做数据格式转换，处理鉴权，再通过 HTTP POST 批量推送给 M 公司的接口。推送时有一个打包策略：收到 N 条数据就打包发出，或者超过一定时间没有新数据也把当前这批发出，每次 HTTP 请求可能包含多条记录。 VIN 到客户的映射关系存储在 Redis，由业务侧维护，数据服务只做读取。 工程细节 可观测性 对接第三方的接口，出问题时的排查成本比内部服务高很多——双方都需要对齐日志，搞清楚是哪一侧的问题。 我在这个服务里做了几件事： 每一批次数据带一个唯一的 trace ID，日志里记录发送时间、trace ID、完整 payload、M 公司 API 的响应时间和状态码。在调试阶段和试运行阶段，日志级别调到 debug，把 payload 全量打印出来，方便排查数据是否正确、格式是否符合对方预期。 除了日志，我还在服务里埋了监控指标，记录推送并发量和调用对方 API 的响应时间，接入 R 平台已有的 Grafana 看板，可以直观看到推送量和延迟的变化趋势。 ...

每个人本质上都是一人公司 每个人都相当于一家一人公司，其他所有人都可以理解为这家公司的客户或合作方，包括家人、朋友、子女。这不是一个商业概念，而是一种视角——把自己的人生当作一个需要经营的主体来对待。 4 月上一家公司裁员，从那之后进入了一段空窗期。6 月去工商局办了手续，注册了自己的公司，拿到了营业执照，目前是个空壳，只有我一个人，没有在跑的业务。注册之后，感觉看问题的视角有些变化，这篇就是记录一下目前的理解。 个人运营的范围 个人运营不只是下班后的副业或兴趣，它覆盖我所有的时间和行为： 早上上班前的跑步，是在维护最核心的资产——身体和精力 晚上陪孩子、给孩子讲故事，是生活这部分的经营 下班后做开源项目、写作、学习，是在拓展能力边界 日常的个人项目的管理和任务追踪，是运营的基础设施 这些都属于同一个主体在运营，只是时间段和服务对象不同。 白天 8 小时的位置 如果未来和某家公司签了劳动合同，白天的 8 小时相当于我的一人公司启动了一个子项目，这个时段按合约把精力交付给签约公司。 关于注册公司 空窗期这段时间，我一边在推进个人的开源项目，一边也在看其他可能性。注册公司来自两个方向：一是开源项目需要一个主体来运营；二是最近出现了一个潜在的机会，对方要求走公对公结算，需要有对公账户。 对于未来跟大公司签长期劳动合同，我是开放的。如果走到最后跟 HR 谈，我会如实告知名下有注册公司这件事，也会直接问对方的态度。如果对方对此有顾虑，配合注销或做其他调整都可以谈。 虽然说可以注销，但光是给这家公司取名字，前后花了差不多半天加一个晚上，第二天早上又跟 AI 聊了两三个小时才最终确定，然后去工商局提交审核。目前没有业务在跑更谈不上像孩子，但的确付出了些精力。如果真的因为某个足够好的机会而必须注销，会有一点遗憾。不多，但有。 关于我用于管理个人运营的工具选型，见 看板工具选型。

这篇周报合并了第 22、23 两周，因为上篇 裁员之后，我的一些探索 发布后一直没写新的，正好把两周攒在一起记录一下。 W22：研究 QuantDinger，部署量化交易环境 这两周主要在折腾 QuantDinger，一个开源的量化交易平台。 为什么要改造 MT5 接入方式 QuantDinger 原本直接通过 Python 库调用 MT5，但 MT5 只能运行在 Windows 环境里，而我的 homelab 主力是跑在 k8s 上的 Linux 容器。直接依赖 MT5 Python 库意味着后端必须跑在 Windows 上，这和 k8s 部署的思路不兼容。 于是我 fork 了上游仓库，在 feat/mt5-thin-gateway 分支上做了一个改造：把后端对 MT5 的直接函数调用拆成 RESTful API——新增了一个独立的 mt5_gateway 服务（Python + Flask），部署在 Windows PC 上，和 MT5 进程跑在同一台机器；k8s 里的后端通过 HTTP 调用这个 gateway，不再直接依赖 MT5 环境。 主要改动集中在几个地方： 新增 mt5_gateway/ 目录，包含独立的 Flask 应用和访问日志模块 后端新增 gateway_client.py，封装对 gateway 的 HTTP 调用 execution.py、factory.py 等调用路径对应调整 补充了若干单元测试（test_mt5_factory_gateway.py 等） 目前 homelab 部署已经跑通，可以正常下单。策略部分还在调试——外汇交易有不少领域知识我不熟悉，接下来打算补一补这块。如果 homelab 测试稳定，计划向上游提 PR。 ...

此文用于记录在 AI 时代到来之前我手搓的最后一个复杂模块. 这个 conflict check 模块的重写是在 2024 年，历时约 3 个月，当时我还没有开始大规模使用 AI 辅助编程。重写的时候注意力都在功能需求上，并没有想「要用哪种设计模式」，只是在纠结怎么把问题拆清楚、用面向对象的方式把责任分开、把可能变化的部分封装起来。Redis 里的缓存数据是嵌套的树形结构，解析时写了几个递归调用——当时认为是最复杂的几个函数。 这个文档写于此后。某次和一个朋友聊天，对方问起对设计模式有没有了解，当时长期没有专门研究过，没说出个所以然。后来那个问题偶尔还会浮上来，然后有一天和 conflict check 关联到了起来, 然后用 Copilot + Claude Sonnet 4.6 分析了一下 — 有些设计模式接近标准实现，有的因业务结构或 Python 语言特性而有所偏差，还有两个（Builder 和 State）目前只是符合模式意图、需要重构才能达到标准结构。整理的过程中还发现了有性能优化空间的地方。 背景 防火墙策略在应用到设备之前，需要先在缓存中进行冲突检测。“网络编排器” 将每台设备的数据缓存在 Redis 中，每份 profile 包含三类数据：地址对象和分组、服务对象和分组，以及策略列表。 每条策略的关键字段： src：源地址数组，每个元素是一个 address object name 或 address group name dst：目标地址数组，结构与 src 相同 service：服务数组，每个元素是一个 service object name 或 service group name 地址对象和服务对象共用同一种数据结构，各自包含两种角色： object：基础对象，value 是实际 IP 地址/CIDR 网段（address）或协议/端口（service）的数组 group_object：分组对象，value 是 object name 或另一个 group_object name 的数组 group 和 object 形成嵌套结构：一个 group 的 value 列表里，既可以直接引用 object，也可以引用其他 group，形成递归树。地址对象和服务对象结构相同，因此 PolicyObject 类可以统一表达这两种类型，同时处理 src、dst、service 的解析。 ...