小生说大声讲

用 Hammerspoon 搞定远程锁屏与 SMB 动态挂载

2026-08-15T14:20:00+08:00

01 我的双 Mac 工作流与两个真实痛点

我的日常工作流由两台 Mac 组成： * 一台 M4 Mac mini：放在工位充当算力中心，常驻跑一些耗时较长的 AI 任务与重型脚本，外挂了一块 2 TB 的高速 SSD； * 一台 M5 MacBook Air：主力移动设备，用来写方案、做设计、做决策，经常带去会议室或外出办公。

在工位时，两台设备通过一条 40 Gbps 的高速 USB-C 线直连（建立高带宽的 Direct IP 连接）；外出时，则通过 Tailscale 组网连接。

看似美好的双机流，在实际使用中却撞上了两个极度影响体验的痛点。

痛点一：Mac mini 远程屏幕共享——「人在不锁，人走即锁」

为了管理 Mac mini 上跑的 AI 任务，我经常在 MacBook Air 上通过 macOS 原生的 Screen Sharing（屏幕共享）连过去查看。

这时就出现了两难： 1. 保留系统默认闲置锁屏：远程查看着训练日志或思考方案，稍微停顿几分钟，远程桌面就黑屏锁定，必须重新键入密码解锁。一天下来要输几十次密码，体验非常割裂。 2. 彻底关闭锁屏密码：极其危险。万一哪天有人给 Mac mini 插上便携显示器，或者直接在物理机上操作，就能毫无阻拦地直通桌面。

核心诉求：只要我的屏幕共享连接着，就阻止锁屏；只要我一断开连接，立即恢复锁定。

痛点二：大文件跨机共享——告别 Git 冗余，动态挂载外挂盘

两台电脑之间必然存在数据同步需求： * 最初我习惯用 Git 做同步：Mac mini 这边跑完 git commit，MacBook Air 那边 git pull。 * 但很快遇到瓶颈：很多 AI 中间数据、方案设计素材体积非常大，且往往不到适合作为版本提交（commit）的时机。如果硬塞进 Git，会迅速吃光两台 Mac 宝贵的内置硬盘空间。

顺理成章的解法是：把 Mac mini 外挂的 2 TB 硬盘通过 macOS 自带的 SMB 共享出来，MacBook Air 直接挂载使用。

但这个方案带来了新的难题： 1. 多网络自动适应：在工位插着 USB-C 线时，我希望优先走 40 Gbps 极速直连通道（169.254.169.99）；带着 MacBook Air 移动办公时，又希望它自动切换走 Tailscale 的网络通道（mini 主机名）。 2. 安全与自动化的矛盾：如果用常规 Shell 脚本执行 mount_smbfs 命令，macOS 要求必须开启「Windows 文件共享」。开启时系统会明确警告「密码将以不安全的方式存储」。而 Finder（Cmd + K）之所以能免密秒进，是因为使用了两台 Mac 绑定的 Apple ID 凭据认证。 3. 断网卡死与弹窗骚扰：当网络未连通时，如果盲目执行挂载，macOS 会在后台阻塞等待 TCP 超时达数分钟，最后弹出烦人的系统错误对话框。

02 解决方案：Hammerspoon 小工具解决大问题

以前遇到这种需求，通常得写一堆复杂的 Shell 脚本配 launchd 守护进程，或者安装好几个臃肿的常驻软件。

直到用上了 Hammerspoon。它的定位是 macOS 系统的 Lua 胶水层，体积极小，能直接调用系统底层的电源管理、网络事件和 AppleScript 接口。用几十行 Lua 配置，就把两个难题彻底理顺了。

场景 1：精准控制 Mac mini 锁屏策略

在 Mac mini 端的 Hammerspoon 中，通过监听 5900 端口（macOS 屏幕共享的 VNC 端口）的连接状态，动态调用 hs.caffeinate 电源管理接口：

检测到 5900 端口有 ESTABLISHED 连接：激活 displayIdle 阻止屏幕变暗和锁屏。
检测到连接断开：释放 displayIdle，交还系统默认的锁屏策略。

-- ~/.hammerspoon/init.lua (运行在 Mac mini 上)
local connected = false

local function checkVNC()
    local output = hs.execute("netstat -an | grep '\\.5900 .*ESTABLISHED'")
    if output ~= "" then
        hs.caffeinate.set("displayIdle", true, true)
        if not connected then
            hs.notify.new({
                title = "Hammerspoon",
                informativeText = "Screen Sharing 已连接，防锁屏已启用"
            }):send()
            connected = true
        end
    else
        hs.caffeinate.set("displayIdle", false, true)
        if connected then
            hs.notify.new({
                title = "Hammerspoon",
                informativeText = "Screen Sharing 已断开，防锁屏已关闭"
            }):send()
            connected = false
        end
    end
end

-- 每 3 秒检测一次
hs.timer.doEvery(3, checkVNC):start()

这样既免去了远程操作时频繁输密码的烦恼，又保证了断开连接后即使物理接上显示器也是锁屏状态。

场景 2：USB-C 直连 / Tailscale 多通道智能挂载

在 MacBook Air 端的 Hammerspoon 中，实现了以下全自动逻辑：

445 端口 1 秒静默预检：在发起挂载前，先用 nc -z -w 1 测试目标的 445（SMB）端口。如果网络不通，1 秒内静默跳过，彻底避免系统弹窗与数分钟的线程阻塞。
复用原生 Apple ID 认证：通过 hs.osascript 调用 AppleScript 的 mount volume 命令。不仅免去在脚本中硬编码密码，还完全不需要开启不安全的「Windows 文件共享」，保持最高安全级别。
优先级与静默 Fallback：优先挂载 USB-C 高速直连通道（169.254.169.99）；若不通则静默回退到 Tailscale 节点（mini）。
内核事件监听：通过 hs.network.reachability 监听网络状态，插上网线或网络连通瞬间即刻自动触发挂载。

-- ~/.hammerspoon/init.lua (运行在 MacBook Air 上)
local servers   = { "169.254.169.99", "mini" } -- 优先 USB-C 直连，Fallback 到 Tailscale
local shareName = "TiPlus"                     -- Mac mini 外挂的 2 TB 共享名
local mountTimer = nil

-- 检查是否已挂载（兼容 /Volumes/TiPlus 及 TiPlus-1 等路径）
local function isMounted()
    local iter, dir_obj = hs.fs.dir("/Volumes")
    if iter then
        for file in iter, dir_obj do
            if file:sub(1, 6) == "TiPlus" then
                return true, "/Volumes/" .. file
            end
        end
    end
    return false, nil
end

-- 静默预检：1 秒内检测 445 端口，拦截系统报错弹窗
local function isPortOpen(host)
    local cmd = string.format("nc -z -w 1 %s 445 >/dev/null 2>&1", host)
    local code = os.execute(cmd)
    return (code == 0 or code == true)
end

-- 挂载核心函数
local function mountTiPlus(manualAlert)
    local mounted, currentPath = isMounted()
    if mounted then
        print("[TiPlus] 已经挂载于: " .. currentPath)
        if manualAlert then hs.alert.show("TiPlus 已经挂载于 " .. currentPath) end
        return true
    end

    if manualAlert then hs.alert.show("正在尝试挂载 TiPlus...") end

    -- 依次尝试高速直连 IP 与 Tailscale 域名
    for _, serverHost in ipairs(servers) do
        print("[TiPlus] 正在预检服务器 " .. serverHost .. " 端口...")
        if isPortOpen(serverHost) then
            local shareURL = "smb://" .. serverHost .. "/" .. shareName
            print("[TiPlus] 端口连通，执行安全挂载: " .. shareURL)

            local ok, result = hs.osascript.applescript('mount volume "' .. shareURL .. '"')
            if ok then
                print("[TiPlus] 挂载成功，当前通道: " .. serverHost)
                if manualAlert then hs.alert.show("TiPlus 挂载成功（" .. serverHost .. "）") end
                return true
            end
        else
            print("[TiPlus] 节点 " .. serverHost .. " 离线，静默跳过")
        end
    end

    print("[TiPlus] 当前所有网络通道均不可达")
    if manualAlert then hs.alert.show("TiPlus 挂载失败，网络未连通") end
    return false
end

-- 1. 启动或重载配置时主动检测一次
mountTiPlus(false)

-- 2. 网络事件监听：无论哪条通道恢复连通，自动尝试挂载
for _, serverHost in ipairs(servers) do
    local reachability = hs.network.reachability.forHostName(serverHost)
    if reachability then
        reachability:setCallback(function(self, flags)
            local isReachable = (flags & hs.network.reachability.flags.reachable) > 0
            if isReachable then
                if mountTimer then mountTimer:stop() end
                mountTimer = hs.timer.doAfter(1, function()
                    mountTiPlus(false)
                end)
            end
        end):start()
    end
end

-- 3. 快捷键手动挂载 (Option + Command + M)
hs.hotkey.bind({"alt", "cmd"}, "M", function()
    mountTiPlus(true)
end)

03 总结与体会

在配置好之后，整个工作流的体验变得极其顺畅：

远程控制 Mac mini：屏幕共享连上即用，中间查资料再也不会频繁被锁屏打断；断开连接后自动锁定，安全无虞。
数据共享：插上 40 Gbps 的 USB-C 线，极速共享盘瞬间挂载到位；拔掉线出门，切到 Tailscale 依然能在后台无感访问，不需要在命令行敲密码，更不需要降级安全性。

Hammerspoon 确实是个非常轻量又方便的小工具，用几十行代码就能把日常使用中很具体的痛点给顺畅解决掉，推荐给有类似需求的朋友。

上下文、压缩与缓存：大模型使用者必须搞懂的三个概念

2026-08-02T22:50:00+08:00

面向日常重度使用 Claude Code / Codex 等 AI 编程工具的工程师。所有涉及 Claude 与 Codex 的技术细节均以官方文档为准，文末附完整出处。

0. 先给一个心智模型

这三个概念不是并列关系，而是一条因果链：

flowchart LR
    A["<b>上下文窗口</b><br/>模型单次能看到的全部内容<br/>（有硬上限）"]
    B["<b>压缩 Compaction</b><br/>窗口快满了怎么办<br/>把历史换成摘要"]
    C["<b>缓存 Prompt Caching</b><br/>每轮都重发全部历史<br/>不想每次都重新计费"]

    A -- "容量不够 → 必须取舍" --> B
    A -- "每轮重发 → 重复计算" --> C
    B -- "压缩改写了前缀<br/>必然打断缓存" --> C

    style A fill:#2d6cdf,stroke:#1b4a9c,color:#ffffff
    style B fill:#c0392b,stroke:#7d2519,color:#ffffff
    style C fill:#1e8449,stroke:#125230,color:#ffffff

一句话概括三者的取舍差异，这是全文最重要的一句：

	触发时发生什么	代价	会不会丢信息
缓存失效	重新计算整个前缀	变贵 + 变慢	不会，模型看到的内容完全一致
上下文压缩	历史被摘要替换	一次额外的模型调用	会，细节永久丢失

很多人把两者混为一谈。缓存失效只是钱和延迟的问题，压缩才是真正会伤害任务质量的操作。 后面所有的实践建议都从这条区别推导而来。

1. 上下文（Context Window）

1.1 官方定义

Anthropic 官方文档的定义是：

"The 'context window' refers to all the text a language model can reference when generating a response, including the response itself."

—— 上下文窗口指的是模型生成回复时能够引用的全部文本，包括回复本身。

有两个要点常被误解：

第一，它不是模型的知识，是模型的"工作记忆"。 官方特别强调它 "is different from the large corpus of data the language model was trained on"（区别于训练语料）。训练知识是模型权重里固化的东西；上下文窗口是这一次请求临时塞进去的东西。

第二，输出也占窗口。 "100 万上下文"不是"你可以输入 100 万 token，模型再额外输出"，而是输入 + 输出总共不超过 100 万。

1.2 所以"100 万上下文"到底指什么

指的是单次 API 请求中，输入与输出 token 数之和的上限是 1,000,000。

具体到什么东西会占用它，官方列举得非常清楚：

flowchart TB
    subgraph W["一次请求的上下文窗口"]
        direction TB
        subgraph IN["输入侧（Input）"]
            direction TB
            I1["System Prompt<br/>系统提示词"]
            I2["Tool Definitions<br/>工具定义 / MCP schema"]
            I3["历史消息<br/>user / assistant 全部轮次"]
            I4["Tool Results<br/>工具返回：文件内容、命令输出、搜索结果"]
            I5["图片 / PDF / 文档"]
        end
        subgraph OUT["输出侧（Output）"]
            direction TB
            O1["Extended Thinking<br/>模型的思考过程"]
            O2["文本回复"]
            O3["Tool Use 请求"]
        end
        IN --> OUT
    end

    style IN fill:#eaf2fd,stroke:#2d6cdf,color:#1a1a1a
    style OUT fill:#fdf3e7,stroke:#e67e22,color:#1a1a1a

原文表述：

"Everything in the request counts toward the context window: the system prompt, every message in messages (including tool results, images, and documents), and your tool definitions. The output Claude generates for the turn, including its extended thinking, counts too."

一个反直觉但很重要的补充：缓存过的内容照样占窗口。

"Cached prompt prefixes still occupy the context window: prompt caching changes what you pay for those tokens, not whether they count."

缓存省的是钱和时间，不是空间。

1.3 关键推论：模型是无状态的，每轮都在重发全部历史

这是理解后面一切的基础。Claude Code 官方文档说得最直白：

"The model doesn't remember anything between requests, so Claude Code re-sends the full context: the system prompt, your project context, every prior message and tool result, and your new message."

也就是说，你在终端里看到的"连续对话"是个幻觉。实际发生的是：

flowchart TB
    subgraph R1["第 1 轮请求"]
        direction LR
        a1["系统提示<br/>+工具"] --> b1["用户 1"]
    end
    subgraph R2["第 2 轮请求"]
        direction LR
        a2["系统提示<br/>+工具"] --> b2["用户 1"] --> c2["助手 1"] --> d2["用户 2"]
    end
    subgraph R3["第 3 轮请求"]
        direction LR
        a3["系统提示<br/>+工具"] --> b3["用户 1"] --> c3["助手 1"] --> d3["用户 2"] --> e3["助手 2"] --> f3["用户 3"]
    end

    R1 --> R2 --> R3

    style a1 fill:#d5e8d4,color:#1a1a1a
    style a2 fill:#d5e8d4,color:#1a1a1a
    style a3 fill:#d5e8d4,color:#1a1a1a
    style f3 fill:#ffe6cc,color:#1a1a1a
    style d2 fill:#ffe6cc,color:#1a1a1a
    style b1 fill:#ffe6cc,color:#1a1a1a

绿色部分每轮完全相同，橙色是每轮新增的部分。正因为绝大部分内容重复，缓存才有意义；也正因为历史只增不减，窗口才会满，才需要压缩。

1.4 Context Rot：为什么"塞满"是个坏主意

官方明确警告：更大的窗口不等于更好的效果。

"more context isn't automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what's in context just as important as how much space is available."

上下文腐烂（context rot）：随着 token 数增长，模型的准确率和召回率会下降。所以"精心筛选放什么进去"和"有多大空间"同等重要。

这直接影响你该怎么用工具：一个跑了 3 小时、塞满了 50 个文件内容的 session，即使还没到窗口上限，效果也已经在衰减了。主动 /clear 往往比死撑到自动压缩更好。

1.5 当前主流模型的窗口大小

Claude 系列（官方文档）：

模型	上下文窗口	单次最大输出
Claude Fable 5 / Mythos 5	1M	128K
Claude Opus 5 / 4.8 / 4.7 / 4.6	1M	128K
Claude Sonnet 5 / Sonnet 4.6	1M	128K
Claude Sonnet 4.5 及其他更早模型	200K	—

要点：

1M 是默认值，不需要 beta header："For every model with a 1M-token context window, 1M is the default: you don't need a beta header."
1M 按标准价格计费，超过 200K 没有溢价："A 900k-token request is billed at the same per-token rate as a 9k-token request."
单次请求最多 600 张图片或 PDF 页（200K 窗口的模型是 100 张）。
⚠️ Claude 4.7 及之后的模型换了新分词器，同样的文本会多出约 30% 的 token（"This tokenizer produces approximately 30% more tokens for the same text"）。所以拿 4.6 的 token 数经验去估 4.7+ 会偏低。

OpenAI GPT-5.6 Sol（官方模型页）：

项目	数值
上下文窗口	1,050,000
单次最大输出	128,000
长上下文计费门槛	超过 272K 输入 token 的请求，整个请求按 2× 输入价、1.5× 输出价计费

原文："Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request."

这个 272K 门槛非常关键，也是 Codex 社区里各种"为什么是 272K"讨论的根源——它是一条计费红线，不是能力上限。特别注意措辞是 "for the full request"：一旦越线，整个请求都按 2 倍输入价计费，而不只是超出的那部分 token。所以在接近 272K 时主动压缩，省下的不是一点边际成本，而是整轮请求的一半。

1.6 窗口满了会发生什么（API 层面）

输入本身就超了：所有模型都返回 400 invalid_request_error（"prompt is too long"）。
输入 + max_tokens 超了：Claude 4.5 及更新的模型会接受请求，生成到上限时以 stop_reason: "model_context_window_exceeded" 停止；更早的模型直接报校验错误。

1.7 一个容易被忽略的机制：Context Awareness

Claude Sonnet 5 / Sonnet 4.6 / Sonnet 4.5 / Haiku 4.5 具备上下文感知能力——API 会自动往系统提示里注入模型的 token 预算：

<budget:token_budget>200000</budget:token_budget>

每次工具调用后还会追加剩余量提示：

<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>

这让模型能"知道自己还剩多少余量"，从而主动规划长任务节奏，而不是盲目往下做。这些标签是 API 自动注入的，你不需要也不应该自己发送。

Opus 4.7 及之后的 Opus、Fable 5、Mythos 5 不接收这些注入标签，改用 beta 的 task budgets 机制。

1.8 Extended Thinking 与窗口的关系

思考（thinking）token 的计费与占用规则值得单独说明：

thinking token 属于 max_tokens 的一部分，按输出 token 计费，计入速率限制。
历史思考块是否保留，取决于模型：
Opus 4.5+、Sonnet 4.6+、Fable 5、Mythos 5：默认保留，作为后续请求的输入 token 计费。
更早的 Opus/Sonnet 与所有 Haiku：API 自动剥离历史思考块（你传回去它也会自动删），为对话内容腾出空间。
唯一必须回传 thinking 块的场景：工具调用循环中，提交 tool_result 时必须原样带上对应的完整 thinking 块（含签名）。API 用密码学签名校验，改动就会报错。

2. 压缩（Compaction）

2.1 什么情况下应该压缩

先区分三种"腾空间"的手段，它们代价完全不同：

手段	做了什么	信息损失	缓存影响
压缩（Compaction）	历史 → 一段摘要	大，细节永久丢失	打断（对话层前缀完全变了）
上下文编辑（Context Editing）	只清除旧的工具结果 / 思考块	中，仅丢工具输出	打断（清除位置之后失效）
清空（/clear、开新 session）	全部丢弃	全部（但你是主动的）	重建，但系统提示层可能仍命中

该压缩的时机（按优先级）：

✅ 任务与任务之间的自然断点 —— 最佳时机。你已经不需要上一个任务的细节了，压缩几乎零损失。
✅ 快到窗口上限，但当前任务还没做完 —— 不得不压，让它压。
❌ 任务做到一半、正在调试细节时 —— 最糟。摘要会丢掉你刚建立起来的关键上下文。
❌ 换新任务时 —— 这时应该 /clear 而不是 /compact。压缩会把无关的旧任务摘要一直背在身上，既占 token 又干扰模型。

Claude Code 官方给的建议正是这一条：

"run /compact at a natural break in your work, such as between tasks, instead of waiting for auto-compaction to trigger mid-task."

2.2 压缩的通用流程

flowchart TD
    A["对话持续增长"] --> B{"input tokens<br/>达到触发阈值？"}
    B -- 否 --> A
    B -- 是 --> C["额外发起一次模型调用<br/>让模型总结当前全部历史"]
    C --> D["生成摘要<br/>（Claude 包在 &lt;summary&gt;&lt;/summary&gt; 中）"]
    D --> E["用摘要替换掉阈值之前的全部内容"]
    E --> F["带着摘要继续任务"]
    F --> A

    style C fill:#fdebd0,stroke:#e67e22,color:#1a1a1a
    style E fill:#fadbd8,stroke:#c0392b,color:#1a1a1a

注意 C 这一步是一次真实的、额外的模型调用——它要消耗 token、计费、占用速率限制。这是压缩的隐性成本。

2.3 Claude：官方 API 的服务端压缩

Anthropic 提供了服务端压缩（beta），是官方推荐的长会话上下文管理方案：

"Server-side compaction is the recommended strategy for managing context in long-running conversations and agentic workflows."

配置方式：

{
  "context_management": {
    "edits": [{
      "type": "compact_20260112",
      "trigger": { "type": "input_tokens", "value": 150000 }
    }]
  }
}

需要 beta header：anthropic-beta: compact-2026-01-12

关键参数与规则：

项目	说明
默认触发阈值	`input_tokens = 150,000`
阈值下限	必须 ≥ 50,000
触发类型	目前仅支持 `input_tokens`
`pause_after_compaction`	为 `true` 时压缩后返回 `stop_reason: "compaction"`，让你有机会插入内容
`instructions`	自定义摘要提示词，完全替换默认提示词（不是追加）
支持模型	Fable 5、Mythos 5、Mythos Preview、Opus 5、Opus 4.8–4.6、Sonnet 5、Sonnet 4.6

执行后发生什么： 响应里会出现一个 compaction 块。后续请求中，"the API automatically drops all content blocks prior to the compaction block and continues from the summary."——API 自动丢弃压缩块之前的所有内容。你必须把这个 compaction 块原样传回去。

计费方式（重要）： 压缩会多出一次采样迭代，usage 里用 iterations 数组分开记账：

{
  "usage": {
    "input_tokens": 23000,
    "output_tokens": 1000,
    "iterations": [
      { "type": "compaction", "input_tokens": 180000, "output_tokens": 3500 },
      { "type": "message",    "input_tokens": 23000,  "output_tokens": 1000 }
    ]
  }
}

⚠️ 顶层的 input_tokens / output_tokens 只反映非压缩迭代。要算真实总消耗，必须把 iterations 全部加起来。只看顶层字段会严重低估账单。

2.4 Claude：更精细的替代方案——Context Editing

如果压缩太"重"（一次性丢掉所有细节），可以用 context editing（beta header：context-management-2025-06-27）：

工具结果清除 clear_tool_uses_20250919：

参数	默认值	说明
`trigger`	100,000 input tokens	何时开始清除
`keep`	3 tool uses	保留最近几组工具调用/结果
`clear_at_least`	无	至少清除多少 token，否则不动手
`exclude_tools`	无	永不清除哪些工具的结果
`clear_tool_inputs`	`false`	是否连工具入参一起清

它在服务端、模型看到 prompt 之前执行，客户端保留完整历史，无需同步。被清除的结果会替换成占位文本，让模型知道"这里原本有东西，被清掉了"。

思考块清除 clear_thinking_20251015：用 keep: {"type": "thinking_turns", "value": N} 保留最近 N 轮，或 keep: "all"。

⚠️ 两者同时使用时，clear_thinking_20251015 必须排在前面。

与缓存的关系（官方明确）： - 清除工具结果会使缓存前缀失效，每次清除都产生 cache write 成本。所以官方建议用 clear_at_least 确保"清得够多，值回缓存重建的钱"。 - 思考块保留时缓存命中、被清时缓存失效。要最大化缓存命中率就设 keep: "all"。

2.5 Claude Code：自动压缩的实际行为

触发时机：接近窗口上限时自动触发。官方对 Sonnet 5 给出了具体数字：

"Sessions auto-compact before the window fills, at about 967K tokens by default; set CLAUDE_CODE_AUTO_COMPACT_WINDOW to choose a different threshold."

即约 96.7% 的位置（1M 窗口）。/context 命令能看到实时占用明细以及预留的 autocompact buffer。

压缩顺序：不是一上来就摘要，而是分两步：

"It clears older tool outputs first, then summarizes the conversation if needed."

先清旧的工具输出，不够再总结对话。这个设计很合理——工具输出（文件内容、命令回显）通常是最占空间又最容易重新获取的。

压缩后什么活下来了（官方表格，这张表非常实用）：

机制	压缩后的状态
系统提示、输出风格	不变（本来就不在消息历史里）
项目根 `CLAUDE.md`、无作用域 rules	从磁盘重新注入
Auto memory (`MEMORY.md`)	从磁盘重新注入
带 `paths:` frontmatter 的 rules	❌ 丢失，直到再次读到匹配文件
子目录里的嵌套 `CLAUDE.md`	❌ 丢失，直到再次读到该目录下的文件
已调用的 Skill 正文	重新注入，但每个 skill 上限 5,000 token、总计 25,000 token，超出时最旧的先丢
Hooks	不受影响（hooks 是代码，不占上下文）

这张表能直接指导你的工程实践：

必须跨压缩存活的规则，绝不要用 paths: frontmatter，放进项目根 CLAUDE.md。 官方原话："If a rule must persist across compaction, drop the paths: frontmatter or move it to the project-root CLAUDE.md."
Skill 的关键指令放在 SKILL.md 最前面。 因为截断保留的是开头："Truncation keeps the start of the file, so put the most important instructions near the top."

其他细节：

/compact focus on the auth bug fix —— 可以带指令，让摘要保留你指定的重点，而不是让模型猜。
也可以在 CLAUDE.md 里加一个 "Compact Instructions" 章节，长期生效。
v2.1.198 起，摘要请求会继承 session 的 extended thinking 配置。
压缩抖动保护：如果单个文件或工具输出大到"每次压缩完立刻又填满"，Claude Code 会在尝试几次后停止自动压缩并报错，而不是无限循环。

2.6 Codex：压缩机制与配置

手动压缩 /compact，官方描述：

"Summarize the visible chat to free tokens. Use after long runs so Codex retains key points without blowing the context window."

清空 /clear：

"Reset the visible UI and chat context together when you want a fresh start."

自动压缩的配置项（config.toml，官方配置参考）：

配置项	官方描述
`model_auto_compact_token_limit`	"Token threshold that triggers automatic history compaction (unset uses model defaults)."
`model_auto_compact_token_limit_scope`	`total`（默认）或 `body_after_prefix`——"Controls whether the auto-compaction threshold counts the full active context (`total`, the default) or only growth after the carried compaction-window prefix (`body_after_prefix`)."
`model_context_window`	"Context window tokens available to the active model."
`compact_prompt`	内联覆盖压缩提示词
`experimental_compact_prompt_file`	从文件加载压缩提示词（实验特性）

model_auto_compact_token_limit_scope 这个参数值得多说一句：total 是拿整个活动上下文去比阈值；body_after_prefix 只算压缩窗口前缀之后新增的部分。后者能避免"摘要本身越滚越大导致压缩越来越频繁"的问题，长会话下更稳。

Codex TUI 会显示 100% context left 之类的剩余量指示器，可以直接观察。

⚠️ 注意：社区广泛流传的"阈值会被静默钳制到窗口 90%"、"压缩后保留 20,000 token 的最近用户消息"等说法来自第三方逆向分析，未见于 OpenAI 官方文档，版本间也可能变化，此处不作为事实引用。

Codex 背后的 API 能力：OpenAI 在 Responses API 层提供两种压缩方式—— - 服务端压缩：请求里带 context_management + compact_threshold，流式响应过程中一旦越线就触发压缩，在同一个流里发出 compaction item 再继续推理。 - 独立端点 /responses/compact：完全无状态、ZDR 友好。你把整个上下文窗口发过去，它返回一个压缩后的窗口。

两者返回的都是一个加密的 compaction item——"It is opaque and not intended to be human-interpretable." 这是与 Anthropic 的显著差异：Claude 的摘要是明文可读的 <summary>，OpenAI 的是加密不透明对象。

2.7 压缩对本次 session / 任务的影响

这是提问里最实际的一问，分四个层面回答：

① 信息层面：细节永久丢失，且丢失是不可逆的

摘要是有损的。压缩前你说过的"注意这个接口的超时要设 3s 不是 30s"，如果模型没判断它重要，就没了。Claude Code 官方的原话是 "detailed instructions from early in the conversation may be lost"。

→ 对策：持久化的约束写进 CLAUDE.md（Codex 写进 AGENTS.md），别指望对话历史。

② 连续性层面：模型会"忘记"自己刚才在干什么的细节

摘要的目的是"提供连续性以便在新的上下文中继续推进"，但它保留的是状态和下一步，不是过程。已经排查过、排除掉的错误路径最容易在摘要中丢失，导致模型压缩后又走一遍老路。

→ 对策：压缩前把关键结论落到文件（笔记、TODO、代码注释），文件是跨压缩最可靠的记忆。

③ 成本层面：压缩本身要花钱，而且可能很贵

压缩要额外跑一次全历史的总结。在 Claude Code 里有一个巨大的成本差异：

"While the cache is warm, that request reads your prefix from the cache, so a mid-session /compact costs a fraction of what the context size suggests... After a break longer than the cache lifetime, there is no cache left to read, so the summarization request reprocesses the full history as uncached input. This is why /compact costs the most when you resume an old session."

缓存热的时候压缩很便宜；隔夜回来再压缩最贵。 这条直接推出一个实践：想压缩就趁热压，别等第二天。

④ 缓存层面：压缩必然打断对话层缓存

"By design, this invalidates the conversation layer, since the next request has a new, shorter history that doesn't share a prefix with the old one."

但好消息是：压缩之后那一轮反而不慢——因为新的对话层只有一小段摘要，重建缓存的成本很低。慢和贵的是压缩这一步本身。

⑤ 质量层面：这是唯一的正面影响

别忘了压缩也有好处。官方指出："as a conversation grows, response quality degrades, so compaction replaces older content with a concise summary." 在 context rot 严重时，压缩掉一堆无关历史反而会提升回答质量。

💡 一个比压缩更好的选择：/rewind 如果你只是走错了路想退回去，用 /rewind 而不是 /compact。官方原话："Rewinding truncates back to a prefix that is already cached, rather than building a new one as compaction does." 回退到的前缀本来就在缓存里，几乎零成本，而且不丢信息——只是把错误的分支砍掉。

3. 缓存（Prompt Caching）

3.1 什么是缓存

回到 1.3 节的结论：每一轮请求，绝大部分内容和上一轮完全相同。缓存就是让服务端复用已经算过的部分。

Claude Code 文档的描述最清晰：

"The API caches by matching the start of each request, called the prefix, against content it recently processed. On a normal turn, the prefix is the entire previous request and only the latest exchange is new. The match is exact, so a change anywhere in the prefix recomputes everything after it. There is no per-file or per-segment caching."

三个必须记住的性质：

只匹配前缀，不是任意片段。
精确匹配，改一个字符就不算命中。
改动点之后的全部内容都要重算——所以越靠前的改动越致命。

flowchart TB
    subgraph OK["✅ 命中：只在末尾追加"]
        direction LR
        K1["系统提示"] --> K2["历史 1-5"] --> K3["新消息"]
    end
    subgraph BAD["❌ 未命中：改了靠前的内容"]
        direction LR
        B1["系统提示<br/>（变了！）"] --> B2["历史 1-5"] --> B3["新消息"]
    end

    style K1 fill:#d5e8d4,stroke:#2e7d32,color:#1a1a1a
    style K2 fill:#d5e8d4,stroke:#2e7d32,color:#1a1a1a
    style K3 fill:#ffe6cc,stroke:#e67e22,color:#1a1a1a
    style B1 fill:#f8cecc,stroke:#c0392b,color:#1a1a1a
    style B2 fill:#f8cecc,stroke:#c0392b,color:#1a1a1a
    style B3 fill:#f8cecc,stroke:#c0392b,color:#1a1a1a

绿色 = 缓存读取（便宜），橙色 = 新写入，红色 = 全部重算。

3.2 缓存命中率

命中率指的是本轮输入 token 中，从缓存读取的比例。Anthropic 在响应的 usage 里给了两个字段：

字段	含义
`cache_read_input_tokens`	本轮从缓存读取的 token，按标准输入价的 10% 计费
`cache_creation_input_tokens`	本轮写入缓存的 token，按标准输入价的 1.25×（5 分钟）或 2×（1 小时）计费
`input_tokens`	⚠️ 只是最后一个缓存断点之后的 token，不是全部输入

总输入 = cache_read + cache_creation + input_tokens

判断标准很简单：

"A high read-to-creation ratio means caching is working well. If creation stays high turn after turn, something is changing in your prefix."

如果 creation 一直居高不下，说明你的前缀里有东西每轮都在变，需要排查。

OpenAI 对应的字段是 cached_tokens。

3.3 计费影响：缓存到底省多少

Anthropic 的倍率（官方定价页）：

操作	倍率	有效期
5 分钟缓存写入	1.25× 基础输入价	5 分钟
1 小时缓存写入	2× 基础输入价	1 小时
缓存读取（命中）	0.1× 基础输入价	同上

官方给出的回本计算：

"A cache hit costs 10% of the standard input price, which means caching pays off after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)."

举个实感数字。假设你在 Claude Code 里用 Opus 5（$5/MTok 输入），会话累积了 300K token 的上下文，接下来还要来回 20 轮：

场景	计算	成本
无缓存	20 轮 × 300K × $5/M	$30.00
缓存全部命中	1 次写入 300K × $6.25/M + 19 次读取 × 300K × $0.50/M	$4.73
中途切了一次模型	上述 + 再写一次 300K × $6.25/M	$6.60

结论：缓存能把长会话成本压到约六分之一；而中途切一次模型多花的 $1.88，约等于 12 轮正常缓存命中对话的成本（每轮命中 300K × $0.50/M = $0.15）。这就是"随手切个模型试试"的真实代价。

各家的定价（Anthropic 官方）：

模型	基础输入	5m 写入	1h 写入	命中	输出
Fable 5 / Mythos 5	$10	$12.50	$20	$1	$50
Opus 5 / 4.8 / 4.7 / 4.6	$5	$6.25	$10	$0.50	$25
Sonnet 5（8/31 前优惠价）	$2	$2.50	$4	$0.20	$10
Sonnet 4.6 / 4.5	$3	$3.75	$6	$0.30	$15
Haiku 4.5	$1	$1.25	$2	$0.10	$5

单位：美元 / 百万 token

3.4 计费之外：缓存失效还影响延迟

提问里问"缓存失效的影响，理解主要是计费？"——不完全是。官方描述失效的后果时，钱和速度是并列的：

"some actions invalidate the cache and make the next response slower and more expensive while it rebuilds."

重新处理 300K token 的首 token 延迟（TTFT）会非常明显。在交互式使用中，这个"卡一下"的体感往往比账单更让人难受。

但要再次强调 缓存失效不影响正确性——模型看到的内容一模一样，只是重新算了一遍。这和压缩有本质区别。

3.5 什么情况下缓存会失效

（A）API 层面的失效规则

层级结构：缓存按 tools → system → messages 的顺序建立。

"Changes at each level invalidate that level and all subsequent levels."

flowchart TB
    T["<b>Tools</b> 工具定义"] --> S["<b>System</b> 系统提示"] --> M["<b>Messages</b> 对话消息"]

    T -. "改动 → 全部失效" .-> X1["💥 tools + system + messages"]
    S -. "改动 → 向下失效" .-> X2["💥 system + messages"]
    M -. "改动 → 只影响自己" .-> X3["💥 messages"]

    style T fill:#f8cecc,stroke:#c0392b,color:#1a1a1a
    style S fill:#fdebd0,stroke:#e67e22,color:#1a1a1a
    style M fill:#d5e8d4,stroke:#2e7d32,color:#1a1a1a

完整失效对照表（Anthropic 官方，✓ = 该层缓存仍有效，✘ = 失效）：

变化项	Tools	System	Messages
工具定义（名称/描述/参数）改动	✘	✘	✘
开关 web search	✓	✘	✘
开关 citations	✓	✘	✘
切换 speed 设置	✓	✘	✘
改 `tool_choice`	✓	✓	✘
增删图片（任意位置）	✓	✓	✘
改 thinking 参数	视模型	视模型	✘
改 `output_config.effort`	视模型	视模型	✘

其他会导致未命中的情况：

切换模型 —— 每个模型有独立缓存，内容一样也不通用。
超过 TTL 未使用 —— 5 分钟（默认）或 1 小时。
低于最小可缓存长度 —— 达不到就静默不缓存，不报错：

"Any requests to cache fewer than this number of tokens will be processed without caching, and no error is returned."

模型	最小可缓存 token
Opus 5、Fable 5、Mythos 5	512
Opus 4.8、Sonnet 5、Sonnet 4.6/4.5、Opus 4.1/4、Sonnet 4	1,024
Mythos Preview、Opus 4.7、Haiku 3.5	2,048
Opus 4.6、Opus 4.5、Haiku 4.5	4,096

跨组织 / 跨 workspace —— 缓存在组织之间完全隔离，部分平台还按 workspace 隔离。
断点放错位置（最常见的工程错误）——把 cache_control 放在每次都变的块上（比如带时间戳的块）。官方给了明确解释：

"The lookback does not find stable content behind your breakpoint and cache it. It finds entries that prior requests already wrote, and writes happen only at breakpoints."

正确做法：断点放在最后一个不变的块上。

工具 JSON key 顺序不稳定 —— 某些语言序列化时 key 顺序随机，会静默破坏缓存。

其他限制：最多 4 个显式缓存断点；回溯窗口最多 20 个块。

（B）Claude Code 层面的失效规则

Claude Code 把请求按"变化频率"分了三层，尽量让稳定的东西排前面：

层	内容	何时变化
System prompt	核心指令、工具定义、输出风格	工具集变化，或 Claude Code 升级
Project context	`CLAUDE.md`、auto memory、无作用域 rules	session 启动，或 `/clear`、`/compact` 之后
Conversation	你的消息、Claude 的回复、工具结果	每一轮

另外两个不在 prompt 文本里、但同样属于缓存 key 的东西：

模型：每个模型独立缓存。
Effort level：同一模型的不同 effort 也是独立缓存。

❌ 会打断缓存的操作（官方完整清单）：

操作	说明
切换模型 `/model`	整个历史重算。`opusplan` 每次进出 plan mode 都是一次模型切换；Fable 5/Opus 5 的自动模型 fallback 也算
改 effort level `/effort`	会话中改动时 Claude Code 会先弹确认框
打开 fast mode	增加了一个属于缓存 key 的请求头。每次会话只付一次，之后开关都不再打断
连接/断开 MCP server	⚠️ 仅当工具定义被加载进前缀时。默认的 deferred tools 模式下不受影响
启用/禁用插件	仅当插件提供 MCP server 时。Skills / commands / agents / hooks / LSP / themes 都不打断
deny 整个工具	如 `Bash`、`WebFetch` 这种裸工具名的 deny 规则。带作用域的如 `Bash(rm )` 不打断*
执行压缩	见 2.7
升级 Claude Code	系统提示/工具定义变了。⚠️ 升级后 resume 长会话可能是你发出过的最贵的一次请求

✅ 不会打断缓存的操作：

操作	为什么安全
编辑仓库里的文件	文件内容只在被读取时进入上下文；改文件只会追加一条 `<system-reminder>`
会话中编辑 `CLAUDE.md`	不打断缓存，但改动也不生效——要等 `/clear`、`/compact` 或重启
改输出风格	同上，不打断也不生效
切换权限模式	不改系统提示（`opusplan` 的 plan mode 除外）
调用 skills / commands	作为 user message 追加在末尾
`/recap`	把摘要作为命令输出追加，而非替换历史
`/rewind`	回退到的前缀本来就在缓存里
启动 subagent	子代理有自己独立的上下文和缓存，父会话前缀不受影响

💡 官方建议一句话总结： "Pick your model and effort level at the top of a session, then save /compact for natural breaks between tasks. The fewer changes you make mid-task, the higher your cache hit rate."

（C）Claude Code 的缓存生命周期（TTL）

Claude 订阅计划：Claude Code 自动请求 1 小时 TTL，休息一小时内回来仍能命中。
但如果超出套餐额度、开始消耗 usage credits，会自动降回 5 分钟 TTL（因为此时 1 小时写入更贵）。
API key / Bedrock / Google Cloud / Foundry：默认 5 分钟，设 ENABLE_PROMPT_CACHING_1H=1 开启 1 小时。
调试用：FORCE_PROMPT_CACHING_5M=1 强制 5 分钟。

（D）Claude Code 的缓存作用域（容易踩坑）

"In Claude Code, the cache is effectively scoped to one machine and directory."

系统提示里嵌入了工作目录、平台、shell、OS 版本、auto-memory 路径，所以：

❌ 不同目录的两个 session 互不命中 —— 包括同一个仓库的不同 git worktree。
✅ 同一目录下并行的多个 session 会共享缓存。
⚠️ 顺序启动的 session 只有在启动时的 git 状态快照一致时才共享（系统提示还捕获了分支和最近提交）。

Subagent 与 Fork 的差别很重要：

	缓存行为
Subagent	全新的系统提示和工具集，从零建缓存；即使订阅计划也只用 5 分钟 TTL。父会话前缀不受影响
Fork	完整继承父会话的系统提示、工具、历史，第一次请求就命中父会话的缓存

这解释了为什么"用 subagent 做大量文件调研"是划算的：它把大读取隔离在自己的窗口里，父会话的上下文和缓存都保持干净。

3.6 OpenAI / Codex 的缓存管理

OpenAI 的缓存是全自动的，没有 cache_control 这种标注机制。

项目	规则
启用方式	自动，无需改代码
最小前缀	1,024 token（"Caching is available for prefixes containing at least 1,024 tokens"）
缓存内容	system / user / assistant 消息、user 消息里的图片、`messages` 数组与 `tools` 列表、结构化输出 schema
保留时长（GPT-5.6+）	"for at least 30 minutes, but OpenAI may retain it longer"
保留时长（更早模型）	"generally remain active for 5 to 10 minutes of inactivity, up to a maximum of one hour"
观测字段	`cached_tokens`
写入成本（GPT-5.6+）	1.25× 未缓存输入价
路由优化	`prompt_cache_key`——共享长前缀的请求用同一个 key，建议每个 key 保持约 15 请求/分钟

未命中的原因：前缀不精确匹配，或隐式断点里包含了变化的元素（时间戳、工具调用历史、用户输入）。

官方最佳实践与 Anthropic 完全一致：静态/重复内容放开头，变化的、用户相关的信息放末尾。

两家的核心差异对照

Anthropic OpenAI

缓存控制显式 cache_control（也支持自动模式）全自动，无手动控制

最小长度 512 ~ 4,096（按模型） 1,024

TTL 5 分钟 / 1 小时（可选，价格不同） GPT-5.6+ 至少 30 分钟

写入溢价 1.25×（5m）/ 2×（1h） 1.25×

命中折扣 0.1×（省 90%）显著折扣

路由控制无需（按前缀哈希） prompt_cache_key

压缩摘要明文 <summary> 加密不透明对象

	Anthropic	OpenAI
缓存控制	显式 `cache_control`（也支持自动模式）	全自动，无手动控制
最小长度	512 ~ 4,096（按模型）	1,024
TTL	5 分钟 / 1 小时（可选，价格不同）	GPT-5.6+ 至少 30 分钟
写入溢价	1.25×（5m）/ 2×（1h）	1.25×
命中折扣	0.1×（省 90%）	显著折扣
路由控制	无需（按前缀哈希）	`prompt_cache_key`
压缩摘要	明文 `<summary>`	加密不透明对象

4. 三者的相互作用

现在把三个概念串起来。一个长会话的真实 token 曲线是这样的：

每个锯齿的谷底 = 一次压缩 = 一次昂贵的额外调用 + 一次信息损失 + 一次对话层缓存重建。

优化的目标因此非常明确：让锯齿尽可能少，让每段"缓存热"的平台期尽可能长。

flowchart TD
    Start["长会话进行中"] --> Q1{"要换任务了吗？"}
    Q1 -- 是 --> Clear["<b>/clear</b><br/>最干净：不背历史包袱<br/>也避免 context rot"]
    Q1 -- 否 --> Q2{"走错路了想退回？"}
    Q2 -- 是 --> Rewind["<b>/rewind</b><br/>✅ 前缀已在缓存<br/>✅ 不丢信息"]
    Q2 -- 否 --> Q3{"要做大量文件调研？"}
    Q3 -- 是 --> Sub["<b>subagent</b><br/>大读取隔离在子窗口<br/>父会话上下文与缓存不受影响"]
    Q3 -- 否 --> Q4{"接近窗口上限？"}
    Q4 -- 否 --> Go["继续，什么都别动<br/>保持缓存热"]
    Q4 -- 是 --> Q5{"当前任务做完了？"}
    Q5 -- 是 --> Compact["<b>/compact focus on ...</b><br/>趁缓存热压，最便宜"]
    Q5 -- 否 --> Wait["先把手上这一步收尾<br/>结论落到文件<br/>再压缩"]

    style Clear fill:#d5e8d4,stroke:#2e7d32,color:#1a1a1a
    style Rewind fill:#d5e8d4,stroke:#2e7d32,color:#1a1a1a
    style Sub fill:#d5e8d4,stroke:#2e7d32,color:#1a1a1a
    style Go fill:#d5e8d4,stroke:#2e7d32,color:#1a1a1a
    style Compact fill:#fdebd0,stroke:#e67e22,color:#1a1a1a
    style Wait fill:#fdebd0,stroke:#e67e22,color:#1a1a1a

5. 日常实践：怎么用好一个 session

5.1 会话开始时（决定了后面 80% 的效率）

一开始就把模型和 effort 定下来，中途别换。 这是投入产出比最高的一条。中途切模型 = 整个历史重算。官方的观察很有意思：为了省钱切到"更便宜"的模型，重建缓存的开销可能比继续用原模型还贵。
要用 fast mode 就在会话开头开。

"turning it on at the start of a session costs less than turning it on deep into a long one." 开头开：几乎无成本。第 200K token 时开：整个历史按 fast mode 价重算。
该配的 MCP server、插件一次配好。 在 deferred tools 默认模式下 MCP 变动是安全的，但如果你的环境走 LLM gateway 或用了 alwaysLoad，工具定义就在前缀里，中途变动 = 全量重算。
稳定的约束写进 CLAUDE.md / AGENTS.md，不要写在对话里。 这是唯一能跨压缩、跨 /clear 存活的地方。

5.2 会话进行中

保持追加，避免修改。 这是所有缓存优化的第一性原理。Claude Code 的很多设计——plan mode 做成可调用的工具而不是切换工具集、MCP 工具延迟加载——都是为了这一条。
大规模调研交给 subagent。 一次 grep 全仓库 + 读 20 个文件，可能就是 50K token。放进 subagent，父会话只收到一段摘要。
走错路用 /rewind，不要用 /compact。 前者回到已缓存的前缀且不丢信息，后者两样都占。
会话中改 CLAUDE.md 是无效的。 官方明确：改了不生效，Claude 还在用 session 启动时加载的版本。要生效必须 /clear、/compact 或重启。这是很多人反复踩的坑——改完配置发现 Claude 完全没变化，以为是模型不听话。
定期 /context 看占用。 看看是不是某个 MCP server 或某次巨大的文件读取吃掉了大部分空间。

5.3 关于休息和恢复

知道你的 TTL 是多少。
- 订阅计划：1 小时。午休一小时回来，缓存大概率还在。
- API key：默认 5 分钟。接杯水回来可能就冷了，除非设了 ENABLE_PROMPT_CACHING_1H=1。
要长时间离开前，先决定回来怎么办。
- 短暂离开（TTL 内）：什么都不用做。
- 长时间离开且任务未完成：离开前趁缓存热执行 /compact。等第二天回来再压缩，是最贵的一种压缩方式。
- 长时间离开且任务已完成：直接关掉。下次 /clear 开新的。
升级 Claude Code 之后不要立刻 resume 长会话。 官方警告："the first turn back into a long session can be the most expensive request you send." 升级后更适合开新会话。

5.4 关于目录（容易忽略的一条）

固定在同一个目录工作。 缓存实际上是按机器 + 目录隔离的。频繁在 worktree 之间跳，等于每次都是冷启动。同一目录并行开多个 session 反而是共享缓存的。

5.5 健康度自检

症状	可能原因	处理
每轮都慢，`cache_creation` 持续很高	前缀里有东西每轮在变	查 MCP server 是否在反复重连；查是否有动态工具更新
刚 resume 就特别慢特别贵	缓存已过期，或升级过 Claude Code	正常现象；考虑改用 `/clear` 开新会话
自动压缩报错停止	单个文件/工具输出过大导致"压缩抖动"	别再整读那个大文件；改用 grep 定位或交给 subagent
改了 `CLAUDE.md` 但没生效	会话中编辑不生效	`/clear` 或重启
压缩后模型"忘了"之前的约定	规则用了 `paths:` frontmatter，或在嵌套 `CLAUDE.md` 里	移到项目根 `CLAUDE.md`，去掉 `paths:`
Skill 指令压缩后失效	超出 5K/skill 或 25K 总量被截断	关键指令挪到 `SKILL.md` 开头

6. 速查表

压缩阈值

场景	阈值	可调方式
Anthropic API 服务端压缩	默认 150,000 input tokens（下限 50,000）	`trigger.value`
Anthropic 工具结果清除	默认 100,000 input tokens	`trigger.value`
Claude Code（Sonnet 5, 1M 窗口）	约 967K tokens	`CLAUDE_CODE_AUTO_COMPACT_WINDOW`
Codex CLI	未公开默认值（"unset uses model defaults"）	`model_auto_compact_token_limit`

缓存 TTL

场景	TTL
Anthropic API 默认	5 分钟
Anthropic API 可选	1 小时（写入 2×）
Claude Code + 订阅计划	1 小时（自动）
Claude Code + 订阅超额用 credits	自动降到 5 分钟
Claude Code + API key / 第三方	5 分钟（`ENABLE_PROMPT_CACHING_1H=1` 可改）
Claude Code subagent	5 分钟（即使订阅计划）
OpenAI GPT-5.6+	至少 30 分钟
OpenAI 更早模型	闲置 5–10 分钟，最长 1 小时

变量	作用
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	自定义自动压缩阈值
`ENABLE_PROMPT_CACHING_1H=1`	在 API key 场景启用 1 小时 TTL
`FORCE_PROMPT_CACHING_5M=1`	强制 5 分钟 TTL（调试用）
`DISABLE_PROMPT_CACHING=1`	完全关闭缓存（仅调试）
`CLAUDE_CODE_DISABLE_1M_CONTEXT=1`	禁用 1M 上下文
`DISABLE_AUTOUPDATER=1`	控制升级时机，避免意外的缓存重建

一句话记忆

上下文 = 模型这次能看到的全部（输入+输出），缓存过的照样占空间。压缩 = 空间不够了，用摘要换空间，会丢信息，趁缓存热的时候做最便宜。缓存 = 复用算过的前缀，只认精确前缀匹配，失效只影响钱和延迟、不影响正确性。 最优策略 = 开头定好模型，中途只追加不修改，大活交给 subagent，任务之间 /clear。

参考文档

Anthropic 官方

Claude Code 官方

OpenAI 官方

Skill、Subagent 与 Agent 究竟是什么？从一个月度总结实战谈 AI 原生架构

2026-07-22T11:45:00+08:00

在大模型（LLM）和 AI 智能体（Agent）快速演进的今天，我们在使用类似 Claude Code、Google Antigravity、AutoGPT 等 AI 编程助手或 Agent 框架时，经常会听到几个核心词汇：Agent、Subagent 和 Skill。

很多开发者往往会感到困惑： - “Skill 和 Agent 到底有什么区别？不都是给 AI 用的工具吗？” - “既然主 Agent 已经能干活了，为什么还需要 Subagent？” - “Subagent 到底是保存在内存里的一个虚无概念，还是一个真正的代码实体？”

为了彻底说清楚这三者的概念与工程落地，本文将结合一个真实的实战需求——“每月自动统计代码仓库变化并生成结构化月报”，手把手拆解这套 AI 原生架构。

一、形象比喻：企业团队的运作模型

要搞懂这三者的关系，最直观的方式就是对比一个现代企业项目团队的日常分工：

flowchart TD
    subgraph 企业团队模型
        Manager["主 Agent (项目负责人 / PM)"]
        Worker["Subagent (专职分析员工)"]
        SOP["Skill (SOP 操作手册 & 工具脚本)"]

        Manager -->|派发任务| Worker
        Worker -->|读取标准并执行工具| SOP
        Worker -->|交付成果报告| Manager
    end

维度	Agent (主智能体)	Subagent (子智能体)	Skill (技能/工具包)
现实比喻	项目负责人 / PM	专职员工 / 专项专员	SOP 操作手册 / 员工指南 / 工具箱
本质属性	全局控制中枢，负责响应用户输入与任务调度。	动态派生的独立 LLM 线程/会话，专注解决单一复杂子任务。	静态的指令集、规范文件（如 Markdown SOP）及可执行脚本。
上下文 (Context)	包含与用户对话的全部主历史。	完全隔离的独立上下文空间，不受主对话噪音干扰。	没有上下文，它是被读取的文件与调用的工具。
生命周期	贯穿整个 Chat Session 过程。	被唤醒时启动，完成特定任务后提交结果并结束。	长期静态保存在项目 Git 仓库中。

💡 核心一句话： Skill 告诉 Agent“标准和工具是什么”；Subagent 是真正“带上工具、在独立房间里闭门干活的员工”。

二、真实需求场景：每月仓库变化统计与月报生成

假设我们在一个项目中需要增加一个自动化能力：每月自动统计本仓库的代码提交、文档新增、模块变动，并形成一份有深度、有分类总结的月度 Markdown 报告。

为什么单纯靠“主 Agent + 提示词”很笨重？

如果直接让主 Agent 在当前对话窗口里去干这件事情： 1. 上下文严重污染：主 Agent 需要读取近 30 天几十上百条提交记录和几百个文件的变更 diff。这些巨量日志会瞬间塞满主对话窗口的 Context Window。 2. 效率与成本低下：海量的中间数据会使后续每句聊天的 Token 消耗急剧增加，甚至导致主 Agent “头晕遗忘”之前的上下文。

因此，完美的解法就是：Skill + Subagent 协同架构。

三、架构设计与落地实现

整个系统的运作流程如下图所示：

sequenceDiagram
    autonumber
    participant User as "用户 / 定时任务 (Cron)"
    participant MainAgent as "主 Agent (Main Agent)"
    participant SubAgent as "专员 Subagent (repo_monthly_reporter)"
    participant SkillDir as "静态 Skill (skills/repo-monthly-report)"
    participant Report as "输出成果 (outputs/reports/)"

    User->>MainAgent: 触发“生成上月仓库报告”
    MainAgent->>SubAgent: 派发子任务 (invoke_subagent)
    Note over SubAgent: 启动独立 Context 空间
    SubAgent->>SkillDir: 1. 读取 SKILL.md 指南 SOP
    SubAgent->>SkillDir: 2. 执行 extract_git_metrics.py 脚本
    SkillDir-->>SubAgent: 返回 JSON 格式硬指标数据
    Note over SubAgent: 3. 对 Git Log 进行语义归纳与分类
    SubAgent->>Report: 4. 生成 monthly-YYYY-MM.md 报告
    SubAgent-->>MainAgent: 汇报完成情况与文件路径
    MainAgent-->>User: 最终答复与成果呈现

1. 第一步：打造 Skill（静态 SOP 与工具箱）

在仓库中建立 skills/repo-monthly-report/ 目录：

SKILL.md (标准操作流程指南)：定义了报告的四大归纳维度（如 AI 技能库、投资模型、学术论文、项目清理）、报告保存路径规范（outputs/reports/monthly-YYYY-MM.md）以及标准的 Markdown 结构模板。
scripts/extract_git_metrics.py (数据提取脚本)：用 Python 自动化提取过去指定天数的提交总数、贡献者、增删代码行数及按业务模块分类的文件列表。

# extract_git_metrics.py 核心片段
def categorize_file(filepath):
    """根据文件路径进行业务模块分类"""
    if filepath.startswith("articles/"):
        return "学术论文/文章 (articles/)"
    elif filepath.startswith("invest/"):
        return "投资/金融模型 (invest/)"
    elif filepath.startswith("skills/"):
        return "AI Agent Skills (skills/)"
    # ...其他分类逻辑

2. 第二步：定义并派生 Subagent（动态分析员工）

主 Agent 通过声明并派生一个名为 repo_monthly_reporter 的子智能体：

{
  "name": "repo_monthly_reporter",
  "role": "Repo Monthly Reporting Specialist",
  "system_prompt": "你是一个专业的仓库月报生成子智能体。严格遵守 skills/repo-monthly-report/SKILL.md 规范，运行 Python 统计脚本，对业务模块进行深度语义归纳，生成月报保存至 outputs/reports/。"
}

随后主 Agent 执行 invoke_subagent 派发任务： Subagent 启动后，在自己独立的 Context 空间内加载 Skill，运行 Python 脚本提取了 18 个变更文件与 -45,831 行数据，并完成了深度语义总结。

3. 第三步：生成结构化月度报告

最终生成的月报 outputs/reports/monthly-2026-07.md 包含了极其清晰的业务图景：

总体概览：代码新增 +621 行，清理 -45,831 行大文本与废弃文件。
三大核心亮点：
上线 pdf-watermark 水印 Agent 技能包；
新增《价值平均定投法》金融知识文档与配套 Excel 工具；
彻底清理老旧爬虫数据集与临时产物。

四、核心追问：Subagent 究竟保存在哪里？

在实际工程中，很多人会好奇：Subagent 到底是一个保存在硬盘上的实体，还是仅仅一串临时提示词？

答案是：它既有运行态的实体，也有静态配置的储存。

1. 运行态实体 (Runtime Entity)

当 Subagent 被派生时，系统真正为其建立了独立的进程与存储路径。例如本次运行中，Subagent 的完整推理过程、思维链以及中间工具调用历史，真实地保存在本地磁盘上： ~/.gemini/antigravity/brain/<subagent-conversation-id>/.system_generated/logs/transcript.jsonl

这也正是为什么它的运行不会占用或污染主 Agent 的 Context 窗口。

2. 配置与定义持久化 (Persistence)

动态注册（会话级 Session Scope）：通过 define_subagent 工具在运行内存中注册，仅对当前 Chat Session 有效，重启后注册表中不保留。
静态配置文件（项目级 Project Scope）：将 Subagent 的 Prompt 和角色写入项目的配置文件（如 AGENTS.md 或 .claude/agents/），这样每次打开客户端或任何人拉取仓库代码，系统均会自动识别并加载该 Subagent。

[仓库根目录]
├── skills/                      <-- 静态 Skill 目录 (跟随 Git 永久持久化)
│   └── repo-monthly-report/
│       ├── SKILL.md
│       └── scripts/extract_git_metrics.py
├── AGENTS.md                    <-- 静态 Subagent 配置文件 (项目级持久化)
└── outputs/reports/             <-- 成果输出路径

五、工程总结：何时用 Skill？何时用 Subagent？

在设计 AI 原生系统或进行 Agentic Workflow 开发时，可以遵循以下三分法原则：

写成 Skill：
凡是静态的操作流程 (SOP)、代码规范、文档模板、纯 Python/Shell 工具脚本，通通写成 Skill 放在 skills/ 目录下。它是纯粹的知识与工具沉淀。
定义 Subagent：
凡是需要大量上下文消耗（如读大量日志、审阅成百上千行代码）、并发处理、或特定专业角色设定（如专业 Code Review 员、安全审计员、月报撰写专员）的任务，定义为 Subagent。
主 Agent 负责调度：
主 Agent 保持轻量，专注于倾听用户的复杂指令，做顶层任务拆解，并发派给对应的 Subagent 去完成。

通过这套架构，我们不仅实现了一个自动化的仓库月报工具，更彻底搞懂了 AI 原生开发中最核心的三大基石理念。

CPU、GPU、TPU 到底谁更“聪明”？从逻辑运算到光互连，一篇看懂 AI Infra

2026-07-19T21:00:00+08:00

朋友最近问了我两个问题。一个是：“GPU 的逻辑能力不强，逻辑运算应该是 CPU 更强吧？”另一个是：“一体封装出来以后，光模块就没有未来了，只剩光纤？”

两个问题都踩在真实的技术趋势上，也都把一个系统问题压成了“谁强谁弱、谁取代谁”的判断题。第一句对了一半，而错的那一半，恰好是理解 GPU 的钥匙；第二句基本不成立，但它错的方式很有代表性——把“产品形态的变化”当成了“功能的消失”。

要把这两个问题说清楚，得从 CPU、GPU、TPU 各自的设计出发点讲起，再经过内存墙、互连和软件栈，最后回到光模块。这篇文章就把这条线走完。不背产品参数，只讲“为什么这样设计”——参数每年都换，设计逻辑十年不变。

一、先把三兄弟放在一张表里

维度	CPU	GPU	TPU（本文特指 Google TPU）
第一目标	单线程、少量线程的低延迟	大规模并行吞吐	矩阵计算的吞吐与能效
典型硬件	少量复杂核心、大缓存、分支预测、乱序执行	上百个 SM、Warp/SIMT、CUDA Core、Tensor Core	少量 TensorCore（MXU 脉动阵列 + 向量 + 标量单元）、SparseCore
怎么对付延迟	预测、推测、乱序，尽量不等	海量线程轮转，谁的数据到了就跑谁	编译器提前排好数据搬运和执行节拍
内存思路	多级硬件缓存隐藏不规则访存	寄存器、共享内存、L2、HBM 分层复用	软件管理的 VMEM 暂存 + HBM
最舒服的任务	分支多、串行依赖、不规则、任务小	大批量、数据并行、矩阵/向量密集	形状稳定、矩阵占比高、可编译成规则数据流
常见软件	C/C++、Java、数据库、操作系统	CUDA、cuDNN、PyTorch、Triton、NCCL	JAX/PyTorch、XLA、Pallas
典型角色	主机、调度、预处理、业务控制	通用加速：训练、推理、渲染、HPC	Google 体系内的大规模训练与推理

这张图值得记住的不是“CPU 核少、GPU 核多”，而是底下那行小字：芯片面积和功耗是死的，每换一种花钱方式，都要牺牲另一种能力的密度。三种芯片不是三个段位，是三份不同的预算分配方案。

二、三种芯片，三种花钱方式

CPU：为“不可预测”买单

通用代码的第一特征是不可预测：满地的 if/else 和函数调用，指针追着哈希表、树、图到处跳，中断和系统调用随时插队，前一条指令的结果决定下一条干什么。

现代 CPU 的应对，是把大量晶体管花在“猜”上。分支预测器每个周期都在猜下一条指令从哪取，主流设计的命中率能做到 95% 以上——但猜错一次，十几级流水线里的工作全部作废；乱序引擎把不依赖当前结果的后续指令提前执行；推测执行沿着猜测的路径先跑起来，错了再回滚；多级缓存负责把不规则的访存伪装成低延迟。这些机制没有一个在“算”，它们都在让等待消失。

所以 CPU 的核心数是几十到上百，而每个核心都很“重”。它的目标是延迟：一个请求进来，尽快出去。

GPU：用人海掩盖等待

GPU 的出发点相反。图形渲染要对几百万像素做同一套运算，AI 的矩阵计算也一样：一条计算规则，作用于海量数据。这种任务不需要每个线程都配备分支预测和乱序引擎，它需要的是数量。

一张 H100 上有 132 个 SM（流式多处理器），合计一万六千多条 FP32 通道。硬件把线程按 32 个一组编成 Warp 调度：一个 Warp 在等内存，调度器就切去跑另一个 Warp。CPU 靠预测隐藏延迟，GPU 靠“手头永远有别的活”隐藏延迟。它优化的不是单个任务多快结束，而是单位时间完成的总量。

另外，现代 GPU 早就不是“一堆小 ALU”。SM 里同时住着做通用算术和逻辑运算的 CUDA Core、专做矩阵乘加的 Tensor Core、访存和特殊函数单元；存储从寄存器、共享内存、L2 一路分层到 HBM；再往外还有 NVLink/NVSwitch 的多卡互连。这个清单后面会反复用到。

TPU：为“确定性”重排一切

TPU 是从工作负载倒推出来的机器。Google 在 2015 年部署第一代 TPU 时的判断是：推理负载的主体是矩阵乘加，而矩阵乘加的循环边界、访存模式在运行前就全部已知——那么 CPU 和 GPU 为“不确定性”准备的机制，缓存、乱序、推测、复杂调度，统统是可以省掉的开销。2017 年那篇著名的 TPU 论文把这个立场写得毫不客气，几乎逐条否定了通用处理器的经典设计。

省下来的面积去了哪里？一个 256×256 的脉动阵列：65,536 个 8-bit 乘加单元排成网格，权重驻留在阵列中，激活值按时钟节拍从一侧流入，部分和在相邻单元间接力，结果从另一侧流出。每个单元不取指令、不做调度，唯一的工作是乘加和传递，所以同样的面积能塞进远多于通用设计的运算单元。这颗 92 TOPS（INT8）的芯片上没有硬件管理的缓存，只有 24 MiB 由软件显式管理的片上缓冲。

今天的 TPU 复杂了很多，骨架没变。TensorCore（Google 文档里的用词，和 NVIDIA 的 Tensor Core 不是一回事）由三部分组成：MXU 脉动阵列做矩阵乘加，向量单元处理激活函数、Softmax、归一化这些逐元素运算，标量单元管控制流和地址计算。VMEM 是编译器显式管理的片上 SRAM，站在 GPU 里 L1/L2 的位置上；SparseCore 专门处理嵌入查表这类 MXU 极不擅长的稀疏访存；芯片之间用 ICI 高速互连。数据什么时候从 HBM 搬进 VMEM、以什么布局喂给 MXU，全部由 XLA 编译器在编译期排定。

顺带澄清一个名词：TPU 特指 Google 的产品线；行业里更宽泛的叫法是 NPU，各家 NPU 内部可能是脉动阵列、向量引擎或别的数据流结构，差异很大，不能都按 TPU 来理解。

边界正在互相渗透

真实产品从不严格站队。CPU 这边加了向量和矩阵扩展（AVX-512、Intel AMX、Arm SVE/SME）；GPU 的 Tensor Core 一代比一代大、一代比一代独立；TPU 反过来在补向量灵活性和稀疏处理。最直白的信号是 CUDA 13 正式加入了 Tile 编程模型：程序员按“数据块”描述计算，线程怎么排交给编译器，块内单一控制流、没有分支发散的概念——这套叙事，十年前是 TPU 的专利。

所以三类芯片的差别从来不是“能不能做”，而是做某类任务时，有多大比例的硅面积在产出有效工作。

三、AI 负载长什么样

主体是矩阵乘法

以 Transformer 为例，计算时间大头花在 Q/K/V 投影、Attention 内部的两次矩阵乘、输出投影、FFN 层的矩阵乘，以及训练时对应的反向传播上。矩阵乘法的特点是：乘加操作海量重复，循环边界和访存模式提前可知——这正是 Tensor Core 和 MXU 的主场。

但模型里还有 Softmax、LayerNorm、激活函数、采样、稀疏路由、Embedding 查表这些非矩阵部分，它们会落到 GPU 的 CUDA Core、TPU 的向量单元或 SparseCore，有些干脆留在 CPU 上。一轮训练或推理，从来不是某一种计算单元的独角戏。

精度是第二根杠杆

AI 对单个数值的精度要求远低于科学计算。训练主流是 BF16，FP8 正在铺开；推理进一步用到 INT8、FP8 甚至 FP4。位宽砍半的收益是三重的：同样的内存放下双倍参数，同样的带宽搬运双倍数据，同样的面积摆下更多低位宽运算单元。

当然“位数越低越好”是误解。低精度需要缩放、校准和足够的累加精度兜底。现在小位宽的主流玩法是微缩放（microscaling，如 MXFP8、NVFP4）：数值用 4/8 bit 存，每一小组数配一个缩放因子，硬件在计算时把缩放乘回去——存储和带宽按小格式付费，精度靠缩放因子找补。

三种执行模型

执行模型	直观理解	优点	代价
SIMD	一条指令驱动多条数据通道	控制开销低，适合规则向量计算	通道间难以各行其是
SIMT	写起来像独立线程，硬件按 Warp 成组锁步执行	编程灵活，通用并行能力强	同 Warp 分支不一致会发散
脉动阵列	数据按节拍流过二维乘加网格	矩阵密度和数据复用最高	对形状、布局、编译调度敏感

三者不是升级关系，是在控制灵活性、硬件密度、编程难度之间选了三个不同的落点。CPU 的向量扩展是 SIMD，GPU 是 SIMT 套在 SIMD 上，TPU 把宝押在脉动阵列上、旁边配向量单元兜底。

四、真正的主角：内存墙

先记一组数量级：在先进工艺上，做一次乘加只要几个皮焦；从片上 SRAM 取一次数，大约贵一个数量级；从 HBM 取一次，贵两个数量级；跨过 PCIe 或网络，再翻几番。时间同理——乘加是纳秒级以下，HBM 访问是几百纳秒，跨节点是微秒到毫秒。算术很便宜，搬数据很贵，而且这个差距逐年拉大。

数据要走的路——从对象存储、网络、CPU 主存，跨过 PCIe 进入 HBM，再经片上 SRAM、寄存器抵达矩阵单元——一张图看完：

越靠近计算单元，存储越快，也越小、越贵。加速器上几乎所有优化，最后都能折叠成一句话：数据搬进来一次，尽量多算几遍，再搬走。

Roofline：一道除法看穿性能

一个内核的性能上限可以粗略写成：

可达性能 ≤ min（峰值算力，内存带宽 × 算术强度）

算术强度（arithmetic intensity）指每搬一个字节做多少次运算。峰值算力除以带宽，得到一个平衡点：算术强度高于它，是算力受限；低于它，是带宽受限，堆再多计算单元也没用。

拿 H100（SXM）算一下：BF16 稠密算力约 990 TFLOPS，HBM3 带宽 3.35 TB/s，平衡点约 295 FLOPs/Byte——每从 HBM 搬一个字节，要做将近三百次运算才喂得饱计算单元。矩阵乘法靠分块复用可以够到这个数；而逐元素加法读两个数、算一次、写一个数，算术强度只有约 0.08，天生贴在带宽墙上。

再算一笔更扎心的账。70B 参数的模型，BF16 权重 140 GB，恰好放进一张 H200（141 GB HBM3e，4.8 TB/s）。单并发逐 token 解码时，每生成一个 token 至少要把权重完整读一遍：140 ÷ 4.8 ≈ 29 毫秒。也就是说，不管这张卡标多少 PFLOPS，batch=1 的解码上限就是每秒三十来个 token，还没算 KV Cache。为什么推理团队拼命做量化、攒大 batch，为什么 HBM 常年供不应求，这一道除法就够解释了。

沿着同一条逻辑，很多现象都不神秘了：Kernel Fusion 省的是中间结果往返 HBM 的搬运；FlashAttention 的贡献不是发明新乘法，是让注意力矩阵不落 HBM；低精度的首要收益在容量和带宽，其次才是运算速度；批量太小，矩阵单元就吃不饱。

从一颗芯片到一座集群

单卡放不下模型、或者算得不够快，就要扩展，路线有两条。Scale-up 是在机箱和机架内用紧耦合互连把多颗加速器拼成“一台更大的机器”：NVIDIA 这边是 NVLink/NVSwitch，GB200 NVL72 把 72 张 GPU 收进一个 NVLink 域，每卡互连带宽 1.8 TB/s；Google 这边是 ICI，把成千上万颗 TPU 织成 3D 环面（torus）。Scale-out 是跨服务器、跨机架，用 InfiniBand 或以太网把域连成集群。

TPU 还有一件独门武器：从 v4 起，pod 内部用 OCS（光路交换机）连接一个个 4×4×4 的芯片立方体。光路交换不解析数据包，只负责“接线”，好处是可以按作业重构拓扑、绕开故障芯片，代价小得惊人——论文给的数字是系统成本占比不到 5%、功耗不到 3%。

到了几千上万卡的规模，最慢的往往不是矩阵乘法，而是卡间交换梯度和激活的集合通信（All-Reduce、All-Gather、All-to-All）。网络的形状会反过来决定模型怎么切。两个公开的对照很能说明问题：PaLM 540B 在 6,144 颗 TPU v4 上训练，靠 3D 环面的带宽，只用了数据并行加张量并行两个维度，MFU 做到 46.2%；Llama 3 405B 在 16,384 张 H100 上，因为 NVLink 域外要跨到 InfiniBand，带宽有断崖，不得不叠上张量、流水线、上下文、数据四维并行，MFU 约 41%~43%。数字接近，工程复杂度差了一倍——并行策略不是自由选择，是网络形状逼出来的。

同一份 Llama 3 报告还有一组更少被引用的数字：54 天训练里发生 419 次意外中断，平均每三小时一次，其中 30.1% 归因于 GPU 故障、17.2% 归因于 HBM3 故障。在这个规模上，可靠性不是运维话题，是性能的一部分——checkpoint 和故障恢复的速度，直接进有效算力的分母。

五、“GPU 逻辑不强”，对，也不对

回到朋友的第一个问题。“逻辑”这个词至少混着四件事：一是布尔和位运算（AND、OR、XOR、移位、位计数）；二是整数运算（地址、索引、哈希、编解码）；三是控制流（分支、循环、状态机）；四是业务逻辑（事务、协议、服务编排）。把它们拆开，答案就清楚了。

论位运算和整数，GPU 不弱，甚至很强

GPU 的 ALU 本来就叫“算术逻辑单元”。CUDA 指令集里整数运算、比较、移位、位翻转、population count、前导零计数一应俱全。证据不用翻手册：比特币还在用显卡挖的年代，GPU 跑的 SHA-256 就是纯粹的整数与位运算；今天的 GPU 数据库和分析引擎（cuDF 等）做的过滤、哈希 join、字典解码，也全是“逻辑运算”。

对海量相互独立的数据做同样的逻辑，GPU 的吞吐可以远超 CPU；只对一个配置值做一次 AND，当然轮不到 GPU。差别在并行规模和启动开销，不在“会不会逻辑”。

论复杂分支，CPU 确实占优

CPU 有分支预测和乱序执行，擅长在纠缠的控制流里压低单线程延迟。GPU 的软肋在 Warp 上：同一个 Warp 的 32 个线程如果走向不同分支，硬件要把两条路径分别执行——跑 if 时屏蔽走 else 的线程，再反过来。这叫分支发散（warp divergence），结果仍然正确，但有效并行度掉了一半。要是 32 个线程各走一条又长又不一样的路，GPU 的吞吐优势就被磨光了。

一个细节：从 Volta 起，每个线程有独立的程序计数器（独立线程调度），能避免一类死锁、允许更细粒度的交错，但发散的路径依然要分别占用执行时间。硬件保证正确，不保证不浪费。

所以，CPU 赢延迟，GPU 赢规模

任务	更可能合适	主要原因
处理一次 HTTP 请求并查库	CPU	分支多、状态多、单次延迟敏感
对上亿像素做同一个阈值判断	GPU	相同逻辑可大规模并行
小型规则引擎、配置解析	CPU	任务太小，GPU 启动和搬运开销不划算
大批量哈希、位图、压缩	视算法而定，GPU 常有吞吐优势	独立数据多
不规则图遍历	通常 CPU 起步，特定算法可上 GPU	访存不规则、负载难均衡
矩阵乘法后接少量激活与判断	GPU/TPU	主体仍是高密度矩阵计算

判断一个任务归谁，与其问“谁强”，不如按四层过一遍：指令层面，芯片支不支持这种运算（几乎都支持）；延迟层面，依赖链多长、分支能不能预测；吞吐层面，有没有成千上万个独立任务可以并行；系统层面，数据在不在显存里、Kernel 启动和 PCIe 搬运要花多久。四层里真正分胜负的，通常是后两层。

严谨版本的回答是：

GPU 不是逻辑运算能力弱，而是没把晶体管花在复杂控制流的低延迟上。少量、串行、分支不可预测的任务归 CPU；海量数据执行相同或相近的逻辑，GPU 往往更快，而且快得多。

六、芯片之外：两套软件栈，两条演进路线

一块加速器好不好用，软件栈的分量不低于硬件。两家的栈长得像，分工的切法不一样：

NVIDIA 真正的护城河不是芯片，是左边这一整摞：二十年的 CUDA 生态、调到极致的数学库、所有框架的一等支持、海量已有内核和调试工具，以及“新论文的参考实现默认是 CUDA”这个惯性。研究代码和新算子几乎总是先出现在 GPU 上，这不是规格表能替代的。

右边的 TPU 栈把布局推断、DMA 调度、双缓冲、指令打包全部交给编译器，作者只描述“块”和“流水线”。好处是写出来就不慢、结果逐位可复现（脉动阵列是确定性的）；代价是遇到编译器没覆盖的边角算子时，排障要下到编译器的层面，路径和 GPU 完全不同。

两条路线正在对穿

看最近三代硬件的动作会发现一件有意思的事：两边都在往对方的方向走。

GPU 这边，Hopper 引入 TMA，把张量搬运从线程手里拿走、交给异步硬件引擎和描述符；Blackwell 把 Tensor Core 从 Warp 调度器解耦，双 die 合封，NVLink 域扩到 72 卡；CUDA 13 加入 Tile 编程模型。翻译一下：GPU 在一步步引入“编译器排定的数据流”——这正是 TPU 的出身。

TPU 这边，Trillium（v6e）把 MXU 扩到 256×256；最新的 Ironwood（TPU7x）每颗芯片两个 chiplet，各带一个 TensorCore、两个 SparseCore 和 96 GB HBM，合计 192 GB、7.37 TB/s 带宽，FP8 稠密算力约 4.6 PFLOPS，单 pod 用 3D 环面加 OCS 连到 9,216 颗芯片；同时 PyTorch/XLA、vLLM 的 TPU 后端在一点点补生态短板。翻译一下：TPU 在补灵活性和易用性——这正是 GPU 的出身。

单芯片指标上，Ironwood 和 Blackwell 已经咬得很紧；真正拉开身位的是紧耦合域的规模（9,216 对 72/144）和生态成熟度（CUDA 对 XLA）。这两个维度，恰好一家一个。

七、怎么选：从工作负载出发

先看负载，再看品牌

场景	首选起点	需要特别检查
Web 服务、数据库、控制面、数据预处理	CPU	单线程延迟、缓存命中、内存容量
小模型、低 QPS、间歇运行	CPU 或小型 GPU	加速器利用率能否覆盖成本
视觉、语音、LLM 训练	GPU；JAX/GCP 体系可评估 TPU	软件兼容、HBM 容量、通信占比、可用容量
大批量离线推理	GPU/TPU	吞吐、批量、量化、每 token 成本
交互式低延迟推理	GPU/TPU	首 token 延迟、解码带宽、KV Cache、并发
渲染、视频、科学计算	GPU	有没有成熟库、双精度需求
稳定的超大规模训练/推理（Google 系）	TPU 吸引力大	XLA 算子覆盖、拓扑与切分
新论文复现、快速试验	GPU 路径最短	生态与调试效率

训练和推理是两种负载，推理自己还要再拆两半

训练要存激活、算梯度、频繁跨设备通信，看重 HBM 容量带宽、低精度稳定性、集合通信效率，以及前面说的 checkpoint 与故障恢复速度。

推理分两个阶段：Prefill 一次吃进整段输入，矩阵大，偏算力受限；Decode 逐 token 生成，批量不足时被权重和 KV Cache 的读取带宽卡死（回想 H200 那道除法）。同一张卡在离线大批量里效率很高，不代表单用户对话时能接近峰值——两个阶段的瓶颈根本不是同一个。

别拿 TOPS 直接比

厂商规格表可能分别标着 FP64、TF32、BF16、FP8、FP4 的峰值，甚至掺着稀疏加成。不同精度的 TOPS 放一列比大小，得出的结论毫无意义。有意义的比较只有：同一个模型同一精度下的有效吞吐、端到端时间、每 token 或每次训练的成本、功耗与机房容量，以及集群规模下的 MFU 和故障恢复。

八、CPO 会杀死光模块吗

回到朋友的第二个问题。先把“一体封装”落到确切的名词上：CPO（Co-Packaged Optics，共封装光学），把光引擎搬到交换 ASIC 或 XPU 旁边、共享封装基板，从而砍掉长长的板级高速电通道。

先看清楚可插拔光模块里有什么

一只高速可插拔模块远不止“光纤接口”。盒子里通常装着：DSP 或均衡电路、激光器、调制器、光电探测器、Driver 和 TIA 模拟前端、温控与监控固件，外加光耦合、连接器、封装和测试。交换芯片通过 PCB 上的 SerDes 把电信号送到面板模块，模块完成电光转换。

问题出在速率上。SerDes 到了 200G/lane，电信号在 PCB 上走几十厘米损耗急剧变大，均衡电路越做越强、功耗越吃越多。CPO 的思路是釜底抽薪：让电信号出了 ASIC 没走几毫米就变成光。

图里画的是外置激光源的一类常见方案，不代表所有实现——不同厂商在光源位置、DSP 去留、光引擎边界上各有取舍。

CPO 改变的是“在哪转换”，不是“要不要转换”

注意，CPO 没有删掉任何光收发功能，它只是把原来集中在一个盒子里的功能拆开、重新安放——完整的可插拔收发模块，变成“共封装光引擎 + 可维护的外置激光源 + 光连接”，上图底部那行总结说的就是这件事。

激光源的去向最能说明问题。激光器怕热，而 CPO 恰恰把光学器件推到了发热大户 ASIC 旁边，于是产业界把激光源单独拎出来放到前面板，做成可插拔、可热更换的模块——OIF 在 2023 年发布的 ELSFP 规范定义的就是这个东西；Broadcom 的 51.2T CPO 交换机 Bailly（8 个 6.4T 光引擎与交换芯片共封装）用的也是可插拔外置光源。CPO 不是消灭了模块，是把模块的边界重新画了一遍。

光纤为什么独自扛不起来

光纤是介质，只会传光。产生稳定光源、把电比特调制到光上、把光转回电、放大与恢复信号、温度补偿、功率监控、波分复用、耦合与测试——这些功能一项都不会因为封装形式变化而消失，只会换个地方存在。无论载体叫光模块、光引擎、光 Chiplet 还是外置激光源，干的都是这些活。

CPO 自己的账单

维度	可插拔光模块	CPO
高速电通道	从 ASIC 走到前面板，长	极短，光引擎紧贴 ASIC
功耗与密度	高速率下压力越来越大	超高带宽下优势明显
维护	坏一只，拔了换新	光引擎与主封装耦合，维修边界复杂
散热	模块在面板，独立热设计	光学器件贴着高功耗 ASIC，热设计难
良率与测试	模块独立制造、测试、筛选	多芯片合封，Known-Good-Die 与耦合测试更难
互操作	MSA 与供应链成熟	标准与多供应商生态仍在成形
落地节奏	各速率、距离、场景通吃	先进入带宽/功耗最紧张的场景

集成度更高不等于处处更好。前面板模块坏了拔掉就换；共封装光引擎出问题，牵连的是整个交换机。外置激光、可拆光连接器、冗余和监控，都是产业为了把可维护性找回来而新做的设计。

实际发生的是共存和价值链迁移

看头部厂商怎么做、怎么说，比看口号准。NVIDIA 在 2025 年 GTC 上发布 Quantum-X 与 Spectrum-X Photonics 交换机（单端口 1.6T，激光器数量减到四分之一，宣称能效 3.5 倍、可靠性 10 倍，液冷设计），InfiniBand 版 2025 年底出货、以太网版 2026 年跟进——同一篇通稿里，NVIDIA 明确表示可插拔光模块技术将与之并行发展，还点名了 Coherent、Fabrinet 和国内读者熟悉的新易盛（Eoptolink）、旭创（InnoLight）。发布 CPO 的人自己都没打算送走可插拔。

未来几年比较合理的图景是：CPO 优先进入交换容量、端口密度和功耗最紧张的 AI 集群；可插拔 DSP 模块继续吃下成熟网络、长距离和多供应商场景；LPO/LRO 作为中间路线，保留可插拔形态、去掉或简化模块内 DSP 来省功耗；板载光学和光 I/O 在不同封装层级继续探路。对厂商来说，“组装完整盒子”的环节在高端市场承压，但激光器、硅光、调制器、探测器、Driver/TIA、光纤阵列、连接器、封装测试的价值不会蒸发，只会重新分桌。

CPO 会减少某些高端交换机里可插拔模块的数量，但消失的是一种产品外形，不是光收发产业。增长的也绝不只有光纤——恰恰相反，光引擎、外置光源和高密度光连接的技术含量比原来更高了。

九、把答案还给朋友

问题一：GPU 逻辑不强，逻辑运算应该 CPU 更强？

如果你说的是复杂分支、串行依赖、低延迟控制，对，CPU 更强，它的分支预测、乱序执行和缓存体系就是为这个造的。但如果说的是 AND、OR、XOR、比较、掩码这类逻辑运算，GPU 不但会做，还能对海量数据同时做——当年挖矿跑的哈希就是纯逻辑运算。GPU 真正的弱点是同一个 Warp 里线程走不同分支时利用率下降。所以别问谁的逻辑强，要问：任务有多少并行度、分支有没有规律、数据在谁的内存里。

问题二：一体封装以后，光模块没有未来，只剩光纤？

如果你说的是 CPO，它确实会把光引擎从面板模块搬到交换芯片旁边，一部分可插拔模块会被替代。但光纤只负责传输，不会发光、调制、探测和监控——这些功能全都还在，只是换了封装位置，激光源甚至专门做成了可插拔的（OIF 还为此定了 ELSFP 标准）。连发布 CPO 交换机的 NVIDIA 都在通稿里写明可插拔技术并行发展。所以不是“光模块消失、只剩光纤”，而是“完整的盒子被拆成共封装光引擎、外置激光和光连接”，两种形态会共存很多年。

十、写在最后

这两个问题背后其实是同一个思维习惯：把系统问题压成单点对决。但现代 AI Infra 里没有单点——CPU、GPU、TPU 是三份不同的晶体管预算，光模块和 CPO 是两种光电转换的安放方式，芯片性能要过内存墙、互连、编译器、调度和可靠性的层层折扣才变成有效算力。

如果只带走一句话，带这句：

AI Infra 的竞争，不是芯片之间的一对一决斗，而是看谁能让数据用更低的能耗、更少的等待、更高的可靠性，从存储流到计算单元，再流到下一颗芯片。

附录：术语速查

术语	含义
ALU	算术逻辑单元，执行算术、比较、位运算
MAC	乘加运算，矩阵计算的基本动作
SIMD	单指令多数据
SIMT	单指令多线程，GPU 的执行模型
Warp	NVIDIA GPU 中成组调度执行的 32 个线程
SM	Streaming Multiprocessor，GPU 的基本执行单元
Tensor Core	NVIDIA GPU 中的矩阵乘加单元；Google 文档里的 TensorCore 是另一个概念（MXU+向量+标量的组合）
MXU	TPU 的矩阵乘法单元，核心是脉动阵列
HBM	高带宽内存，加速器的片外主存
VMEM	TPU 上由编译器管理的片上暂存 SRAM
ICI	Inter-Chip Interconnect，TPU 芯片间高速互连
Tiling	把大张量切块，让数据在片上反复复用
算术强度	每搬一个字节做多少次运算，Roofline 模型的横轴
MFU	Model FLOPs Utilization，有效算力利用率
Scale-up / Scale-out	紧耦合域内扩展 / 跨节点网络扩展
CPO	共封装光学，把光引擎放到主 ASIC 旁边
LPO / LRO	保留可插拔形态、去掉或简化模块内 DSP 的两类路线
ELSFP	OIF 定义的可插拔外置激光源规范
OCS	光路交换机，通过重构光路改变互连拓扑

资料来源与延伸阅读

本文的框架部分参考了 Adam Mainz 的两篇长文（他刚从 Meta 的 Triton 编译器团队转到 Google TPU 团队，文章立场偏 TPU，本文未采纳其平台优劣结论），产品规格与 CPO 进展均用一手资料交叉核验。

Adam Mainz, From SIMT to Systolic: A Foundation for GPU and TPU Architecture 及 The Two Stacks
NVIDIA, CUDA Programming Guide（SIMT、Warp 与 Tile 编程模型）
NVIDIA, Hopper Tuning Guide（TMA 与内存层级）
NVIDIA, Blackwell Architecture
Jouppi et al., In-Datacenter Performance Analysis of a Tensor Processing Unit（TPU v1 论文）
Jouppi et al., TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning
Google Cloud, TPU System Architecture 与 TPU7x（Ironwood）
Chowdhery et al., PaLM: Scaling Language Modeling with Pathways（46.2% MFU 与 pipeline-free 训练）
Meta, The Llama 3 Herd of Models（4D 并行与 54 天故障统计）
OIF, ELSFP Implementation Agreement 发布通告与 Implementation Agreements 列表
Broadcom, What Is Co-Packaged Optics? 与 CPO 产品页
NVIDIA, Spectrum-X / Quantum-X Photonics 发布通稿（含可插拔并行发展与合作伙伴名单）

资料与产品状态核验日期：2026-07-19。

我只是想打开一个 Markdown 文件看一眼——于是 vibe coding 了一个编辑器

2026-06-06T15:00:00+08:00

一个小到可笑的需求

先说清楚我到底想要什么，因为这决定了后面所有的取舍：

我只是想在 macOS 上随手打开一个 Markdown 文件看一眼，如果能顺便改两笔就更好——仅此而已。

我不需要笔记库（vault）、不需要双向链接、不需要标签系统、不需要文件树、不需要发布到博客的一键流程、不需要 30 个主题。这些功能不是不好，而是它们都在解决"管理大量笔记"的问题，而我的问题是"此刻打开这一个文件"。

这个需求小到，理论上应该有一大把现成软件能完美满足。但真当我一个个试过去，发现没有一个让我舒服的。

我试过的那些编辑器，以及为什么都不行

把候选者摊开，按我最在意的几个维度排一张表：

编辑器	实现方式	价格	维护状态	我的槽点
Typora	Electron / CEF	付费	活跃	体验确实是标杆，但收费 + Electron 套壳，进程动辄几百 MB
MacDown	原生 WebView	免费开源	年久失修	老牌良心货，但更新近乎停滞，对新语法支持滞后
MacDown3000	MacDown 衍生	免费	不稳定	每次跟着更新就容易"罢工"，可靠性堪忧
Mark Text	Electron	免费开源	基本停更	曾经很惊艳，如今 issue 堆积、长期没有新版
Obsidian	Electron	个人免费	活跃	强大但"重"，是知识库工具，为"打开一个文件"杀鸡用牛刀
iA Writer	原生	付费	活跃	原生、极简、很优雅，但要付费，且偏纯写作
Marked 2	原生	付费	活跃	只读预览器，不能编辑，定位和我的需求错位
VS Code	Electron	免费	活跃	它是 IDE，为看一个 md 启动整个编辑器，心理负担太大

把这张表看下来，会发现它们恰好踩满了我的四条雷区：

要么收费——Typora、iA Writer、Marked 2，体验好但要掏钱，而我的需求廉价到不值得为它付费；
要么是 Electron 套壳——Mark Text、Obsidian、VS Code，随便开一个进程就吃掉几百 MB 内存，启动还有可感知的延迟，跟"随手看一眼"的轻快感背道而驰；
要么年久失修——MacDown 这样的老牌开源货，代码还在，但维护近乎停摆，新语法跟不上；
要么不稳定——MacDown 衍生出来的 MacDown3000，我用得最闹心，常常一更新就不能好好工作。

最让我难受的是第 2 条。Markdown 这种纯文本格式，本应是最轻量的东西，结果主流方案却普遍建立在一整个浏览器内核之上。为了渲染几段文字和代码块，背一个 Chromium，怎么想都不对劲。

那就自己写一个吧

既然挑不到，那就自己造。正好赶上 AI 辅助编程（大家戏称 "vibe coding"）已经足够顺手，我决定亲自下场，做一个完全贴合自己需求的编辑器。给它起名 Markdown2——"Markdown Editor Too"，一个不太正经的双关：既是"另一个 Markdown 编辑器"，也是"我也想要一个 Markdown 编辑器"。

立项时我给自己定了几条死规矩，全部是对前面四条雷区的正面回应：

原生，不用 Electron——用 SwiftUI + AppKit，做成真正的 macOS app，启动快、内存小；
轻量，专注阅读/编辑——单窗口，只有"编写"和"阅读"两种模式，不做文件管理、不做笔记库；
离线，不依赖网络——公式、图表的渲染资源全部内置打包，断网照样工作；
开源免费——MIT 协议，自己用得放心，也省得有人重蹈我"挑不到"的覆辙。

技术栈选 Swift 而不是继续套 Electron，理由很直接：我想要的就是"原生的轻"。文本编辑这件事，AppKit 的 NSTextView 经过几十年打磨，底子比任何 Web 富文本都扎实；外层用 SwiftUI 搭界面和状态管理，写起来又足够现代。两者配合，正好是"原生底座 + 现代外壳"。

整个项目用 Swift Package Manager 组织，拆成三层：

MD2Core——纯逻辑层，Markdown 解析、渲染成 HTML、大纲提取、语法高亮、文档统计，不碰 UI，方便写单元测试；
MD2AppSupport——承载启动激活这类与 AppKit 生命周期强相关的辅助逻辑；
MD2App——SwiftUI/AppKit 的应用层，窗口、编辑器、预览、设置都在这。

逻辑和界面分层之后，核心的解析渲染能力是可以脱离 GUI 单独测试的，这让"vibe coding"产出的代码不至于变成一团没法验证的浆糊。

途中那些有意思的坑

vibe coding 不是把需求丢给 AI 就万事大吉，真正花时间的，永远是那些"看起来该工作却不工作"的细节。挑几个印象最深的讲讲——前两个是早期的小坑，后两个则是真正需要先想清楚、再让 AI 动手的复杂需求。

坑一：`swift run` 启动后，窗口躲到了别人后面

开发阶段我习惯用 swift run Markdown2 直接跑。结果发现一个诡异现象：app 进程确实起来了，但窗口总是藏在当前 app 的后面，前台焦点还赖在终端/编辑器上，等于这 app 没法正常用。

排查下来，根因有点意思：SwiftPM 跑出来的是一个裸的 Mach-O 可执行文件，而不是被 LaunchServices 管理的 .app bundle。macOS 对"裸进程"和"正经 app"的窗口前台化待遇是不一样的——从裸进程里直接调 AppKit 的激活 API，并不足以可靠地把窗口抢到最前面。

解决办法是加了一段"直接启动引导"（direct-launch bootstrap）：当 Markdown2 发现自己不是在 .app 里运行时，就在 .build 目录下临时合成一个 Markdown2.app，再通过 NSWorkspace 带激活地把这个 bundle 打开，然后原始的裸进程退出。被 bundle 拉起来的那个进程会跳过引导逻辑，正常进入主流程。后来又发现 SwiftUI 的 WindowGroup 在这条特殊启动路径下，偶尔会进了 applicationDidFinishLaunching 却没真正建出可用的初始窗口，于是干脆在 AppDelegate 里显式创建主 NSWindow，把 SwiftUI 的 ContentView 塞进去托管，再加上几次延迟激活重试兜底。

这个坑我专门写了回归测试，验证激活策略提升、窗口层级排序、以及对"迟到窗口"的延迟重试。它很典型地说明了一件事：AI 能飞快写出主干，但操作系统层面的边角行为，还是得人去抠。

坑二：公式和图表，到底要不要联网

很多 Markdown 编辑器渲染数学公式和图表时，是去 CDN 拉 KaTeX/Mermaid 这些前端库的。但这跟我"断网也能看"的原则冲突——很多时候我打开一个 md，恰恰是在没网或不想联网的场景。

于是我把渲染资源全部内置打包进 app：

数学公式用内置的 KaTeX，行内 $...$ 和独占一行的 $$...$$ 都支持，还带上了 mhchem 扩展，能写化学式 \ce{H2SO4}；
图表支持 mermaid、flow（flowchart.js）和 sequence（js-sequence-diagrams），引擎全部离线内置。

代价是 app 体积大了一点，但换来"任何时候、任何网络环境下打开都一致"，我觉得非常值。顺带一提，这两块功能我是用 spec-driven 的方式做的——先写 proposal/design/spec，再让 AI 照着实现，archive 里留着 add-math-support 和 add-diagram-rendering 两个变更记录。给 vibe coding 套上一层规格约束，产出的可控性明显高很多。后面两个更复杂的需求，更是全靠这套流程才没翻车。

坑三：模式切换后，怎么还"停在原地"

这是个用着用着就越来越忍不了的体验问题：在编写/阅读两种模式之间切换时，视口总是弹回文档顶部。文档但凡比一屏长，每切一次就得重新滚回刚才看的地方，读改循环被打断得很烦。

听起来像"记一下滚动位置"这么简单，真做起来才发现卡在一个根本性的错位上：编辑器和预览是两套完全不同的坐标系。编辑器认的是「源码第几行」，预览是一个 WKWebView，认的是「DOM 元素的像素滚动偏移」。我"刚才在第 180 行"，翻译成预览里该滚到哪个像素，并没有现成的换算。

破局点是文档大纲：每个 Heading 节点同时带着源码 line 和 HTML 元素 id——它天然就是横跨两套坐标系的那座桥。于是策略定为：切换时锚定到「光标/视口上方最近的那个标题」，按章节粒度对齐，不追求像素级或光标级精确——目标是"落回文档的同一部分"，而不是分毫不差。没有标题的文档、或标题之前的内容，则退化成按滚动比例（scroll-fraction）兜底，绝不静默跳回顶部。

真正棘手的是异步：WKWebView 的滚动位置只能通过 evaluateJavaScript 回调异步读取，而 SwiftUI 的模式切换是同步发生的、旧视图瞬间就被销毁。所以根本不能"在切换那一刻才去问预览滚到哪了"——得在用户滚动时就持续把「当前视口顶部是哪个标题」缓存下来，等切换真正发生时直接拿现成的值用。我把纯粹的「行号↔标题」解析逻辑（比如"找出 line 不超过某行的最后一个标题"）抽进 MD2Core 做成纯函数，这样不依赖跑起来的 WebView 就能单测。

这种需求，是没法一句话丢给 AI 的。得先把"用什么做锚、锚在什么粒度、异步怎么规避、没锚点时怎么兜底"这几件事一条条想清楚、写进 spec，AI 才可能写对——否则它大概率给你一个"在简单情况下能跑、一遇到长文档和异步就乱套"的版本。

坑四：藏不住的图表"闪一下"

这个 bug 是做坑三时顺手揪出来的：调试滚动位置时我注意到，预览加载完之后大约一秒，Mermaid 图表会肉眼可见地"闪"一下——先显示一段原始代码文本，然后才被引擎替换成渲染好的 SVG。

根因有两层。其一，图表引擎是异步渲染的，在它 resolve 之前，DOM 里就摆着原始源码当占位文本给读者看到了；其二，前面提过预览的 WKWebView 每次切换模式都会重建，所以这个闪烁不只第一次出现，而是每切一次复发一次。

修法是给占位状态做文章：源码仍然留在 DOM 里供引擎读取，但用 CSS 不再把它当正常文本显示；等引擎渲染完成，再加一个约 120ms 的淡入，把生硬的"代码→图"硬切变成柔和过渡；同时给占位块预留一点 min-height，减少 SVG 撑开时的布局跳动。这里最容易踩的雷是别把错误兜底搞丢了——解析失败时仍然要把原始源码显示出来，绝不能让一个写错的图表变成一片空白。所以"渲染成功才隐藏、失败要回显"这条岔路必须在 spec 里写死，测试也要专门覆盖错误路径仍然可见。

一个需求的调试过程牵出另一个隐藏问题，再各自立项、写 spec、补回归测试——这才是真实软件演进的样子，也是为什么我越来越离不开这套"先规格、后实现"的节奏。

现在的 Markdown2 长什么样

迭代到现在，它已经能覆盖我日常的全部需求：

单窗口、双模式：一个主界面，Esc 从编辑切到预览，预览里 Cmd+双击 切回编辑，手不离键，且切换时停留在同一章节、不会弹回顶部；
多窗口：每个文档独立开窗，从 Finder 双击打开时会复用那些还没动过的空白窗口，不会越开越乱；
大纲侧栏：按标题自动生成，长文档导航很顺；
自动保存 + 关闭确认：已保存的文档防抖自动保存，有未保存改动时关窗/退出会提示；
状态栏：字数、字符数、行数、预计阅读时间一眼可见；
够用的 Markdown 渲染：标题、强调、链接、图片、引用、各类列表、GFM 表格、带语法高亮的围栏代码（Python/Go/Rust/Swift 等十来种语言）、YAML front matter、[TOC]，外加前面说的离线公式与图表；
文件类型关联：打包后把 .md/.markdown 注册给自己，双击直达。

它不做的事同样清晰：脚注、PDF/DOCX 导出、图片上传拖拽、打字机模式、主题管理、笔记库——这些都不在"随手打开看一眼"的射程内，我刻意没碰。约束自己不做什么，往往比堆功能更难，但这恰恰是我对那些"功能太复杂"的编辑器最大的不满，不能自己又掉进同一个坑。

一点心路体会

回头看这趟，从"挑不到一个趁手的 Markdown 编辑器"到"两天攒出一个自己用着舒服的原生 app"，最大的感受有两条。

一是 AI 把"自己造一个轮子"的门槛拉得很低了。放在以前，为了这么个小需求去啃 AppKit、SwiftUI、KaTeX 内嵌，光是查文档就能劝退我；现在 vibe coding 让我能把精力集中在"我到底想要什么、哪里还不对"上，而不是卡在 API 细节里。

二是 AI 替代不了"品味"和"较真"。它能秒出一个能跑的版本，但"窗口为什么躲到后面"这种坑、"要不要联网渲染"这种取舍、"克制住不加哪些功能"这种判断，依然得人来定。工具越强，"想清楚自己要什么"反而越值钱。

代码已经开源在 GitHub（stutiredboy/Markdown2），MIT 协议。如果你也和我一样，只是想随手打开一个 Markdown 文件看一眼，欢迎试试，也欢迎拍砖。

姚顺宇 4 小时访谈，通透有趣的灵魂~

2026-05-19T20:00:00+08:00

听完这四个多小时的访谈，有几点觉得比较有意思的：

1、姚顺宇坦言自己 90% 甚至 99% 的代码都是 AI 生成的，果然极客精神首先还得是实用主义，和古法编程形成了反差，拥有最好的本地大模型和代码助手，还非要去拼人力，这就是跟生产力过不去，当然不妨碍我们应当保留那 1%~10% AI 无法触达的能力；

2、所谓"到了架构瓶颈"，往往只是代码里藏了个低级 Bug。就好比近一年来各大公有云的各种 big boom 可能单纯是一段糟糕的监控代码把控制面给打爆了；

3、Idea 极其廉价，执行力和"靠谱"才是硬通货。姚顺宇提到"AI 这个事其实不太需要脑子，最重要的特质是 Execute（执行力）"。想法需要详尽的架构蓝图，现在不缺天马行空的所谓"英雄"，缺的是能把复杂的项目，一步步拆解清晰，能把事情做细，对交付结果死磕到底的靠谱工程师；

4、祛魅"老登"，破除个人英雄主义神话。"没有哪个老登是你的亲属，他傻就可以直接说他傻"。技术发展到今天这个量级，单枪匹马搞定颠覆性算法的时代已经翻篇了，本质上都是工程体系和集体主义的胜利。只要逻辑自洽、结果能经得起客观标准的检验，就不需要去迷信那些旧时代的权威；

5、Anthropic Dario 所谓的"AI 安全"，不过是反中和争霸的遮羞布。姚顺宇毫不避讳地爆料，离开 Anthropic 有 40% 的原因是因为受不了 CEO Dario 的反华立场，而且极其反感 Dario 那套"我们必须拥有最强模型才能推 AI 安全"的逻辑。这点真的让人挺 respect 的。现在硅谷那帮大佬动辄把"AI 安全"挂在嘴边，搞得极其神圣，但扒开这层皮，底层逻辑无非是"我要垄断最强技术，所以规矩必须由我来定"的政治博弈和商业算计；

6、OpenAI 救了 Google 一命，"如果 ChatGPT 一鼓作气把 Search 吃透，Google 就完了。正因为没做到极致，反而给 Google 留了反击的时间。"如果在技术优势期没有把核心场景打穿、形成绝对的降维打击，那就是给对手留了喘息和重组火力的窗口期。OpenAI 后来高管流失、各种内部动荡，多少也印证了在战略执行上的拖泥带水是致命的；

7、程序员的未来不是消失，而是"极度中心化"的残酷洗牌。"绝大多数失去独特价值，1/1000 的人拿 100 倍工资。"这句话很残酷也也很真实（虽然资本家大概率不会真的给你 100 倍工资）。未来留下来的，必定是那些具备全局视野、能把复杂业务逻辑拆解成 AI 可执行步骤的"超级节点"。这1/1000的人，其实是懂业务、懂架构，还能下一线动手的"超级总包商"；

见识学习了姚顺宇作为"不靠 LP 吃饭、没有历史包袱"的新一代研究员的特质，这些带着浓厚极客精神和真实体感的观点，以姚顺宇相对平静又戏虐的语气跳脱而出，还是很有冲击力的。另外抛开那些虚头巴脑的，不管外面的风口吹得多高，哪怕是 Anthropic、Google DeepMind 这样的神级团队，本质上也是由一个个也会写出 Bug、也会搞出命名乌龙（Claude 3.5/3.6）的工程师组成的。对我们来说，用好当下最锋利的工具去武装自己才是咱们在这个快速变现的时代里最应该马上去做的（至于能不能成为最核心的护城河，谁知道呢~~

借长鑫科技的东风，把存储这件事一次讲透

2026-05-17T10:00:00+08:00

2026 年 5 月 17 日，长鑫科技更新科创板招股书：2026 年 Q1 营收 508 亿、归母净利润 247.62 亿，半年指引营收 1100—1200 亿、归母 500—570 亿，同比预增 2244%—2544%。一家长期亏损的国产 DRAM 厂，半年净利干到 500 亿+ 的体量，把"中国存储能不能赚钱"这道老问题，直接翻篇了。

借这股东风，正好把存储这条产业链相关的信息学习一轮。

一、AI 时代的存储，凭什么分成六层

CPU 和 GPU 自己只有一点点片上缓存，装不下模型，更装不下推理上下文。所以存储被迫往外摊，离算力越远、容量越大、单位成本越低，但延迟和能耗也越高。这就是分层的由来。

按"离算力的距离"由近到远，AI 存储一共六层，2025 年六层合计市场约 2290 亿美元：

挑几个关键点说：

L0 片上 SRAM：嵌在每颗芯片里，本身只有 10—17 亿美元的独立晶片市场，但每一颗 H100、B200、TPU v5 为了多塞 SRAM 都得多买晶圆，真正的利润池落在台积电——全球先进工艺晶圆 70% 以上在它手里。
L1 HBM：用 TSV 把 DRAM 垂直堆叠，再用 CoWoS 贴到 GPU 旁边。它几乎单枪匹马决定了 AI 加速器能跑多大的模型。2025 年盘子约 350 亿美元，2028 年预计冲到 1000 亿美元，CAGR 40%（美光 FY26Q1 业绩会口径）。2026Q1，SK 海力士的营业利润率打到了 72%，比台积电（58%）和英伟达（65%）都高。
L2 主板 DRAM：DDR5/LPDDR/GDDR 这些常规内存条，2025 年 1218 亿美元，是六层里盘子最大的。三星、SK、美光把产能往 HBM 倾斜后，反而让普通 DRAM 维持了高利润和定价权。
L3 CXL 内存池：把 DRAM 从单台服务器"池化"到机架级，多个 GPU 按需共享。当前规模才 16 亿美元，但 2033 年看到 237 亿。这一层最暴利的环节是重定时器，Astera Labs 占 55%，非 GAAP 毛利率 76%。
L4 企业级 SSD：QLC 大容量盘已经把 HDD 从 AI 数据湖里彻底挤出去。2025 年 261 亿美元，CAGR 24%，海力士子公司 Solidigm 与 Kioxia 已经做出 122TB 的单盘。
L5 NAS 与云对象存储：数据湖、归档、跨团队协作的最外层，AWS+Azure+GCP 三家拿走 65—70%，靠的是"数据出网+生态锁定"的复利。

一句话总结：越靠近算力，盘子越小，毛利越高。HBM 盘子只有 DRAM 三分之一，毛利率却翻倍；CXL 重定时器盘子最小，毛利率最高。

二、龙头格局：三强 + 一个新入场的第四名

存储是典型寡头行业，前三家在每一层都基本拿走 90% 以上。

DRAM（TrendForce 2025Q4）：三星 35.8% 重夺第一、SK 海力士 32.1%、美光 22.4%，长鑫 CXMT 升至 4.7%，构成新的"四强"格局。按招股书披露的产能/出货口径，长鑫 2025Q4 全球份额已达 7.67%——口径差异主要在于片数 vs 营收，长鑫片数堆上来了，单价还在追赶。
HBM（2026Q1）：SK 海力士约 58%（拿下英伟达大单）、三星 22%、美光 20%。三星份额从 40% 掉到 22%，主要被先进封装良率拖累。
企业级 SSD（2025Q4）：三星 36.9%、SK（含 Solidigm）32.9%、美光 14.0%、Kioxia 11.7%、SanDisk 4.4%，前五合计约 90%。

韩美三巨头同时吃下 DRAM+HBM+NAND 三层红利，是更全面的"AI 存储平台公司"。长鑫是这个格局里唯一的中国玩家——之前的市场被三星、SK、美光三家寡头垄断超过 90%，长鑫从零起步做到全球第四，本身就是 0→1 的破局。

三、长鑫的产业链全景：设备 + 材料 + 客户

长鑫现在合肥两座、北京一座，三座 12 英寸厂，月产能合计接近 30 万片，按晶圆片数算已占全球 DRAM 接近 15%。上海新厂分两期共 20 万片，2027—2028 年陆续投产，远期奔着 50 万片以上去。IPO 拟募资 295 亿，其中约 200 亿会直接变成设备订单——这是国产设备厂未来两年最确定的基本盘。

上游 · 设备（国产化率 ≈ 45%）

已跑通：刻蚀（北方华创 ICP > 50%、中微 CCP）、CMP（华海清科国产份额 > 90%）、清洗（盛美 SAPS/TEBO）、热处理（北方华创立式氧化炉）。
验证中：薄膜沉积（拓荆 PECVD、北方华创 PVD 进入量产），但 DRAM 电容核心的高 K ALD 还是应材、ASM 的地盘。
卡脖子：光刻国产化率不到 5%，主力还是 ASML NXT:1980Di。2026 年 4 月美国众议院通过 MATCH 法案，要求 150 天内堵死 DUV 出口的灰色通道——这道墙短期绕不开。量测（KLA 占 51-54%）、涂胶显影（东电 90%）、离子注入也都还是个位数国产率。

上游 · 材料（领先设备一个身位）

湿电子化学品 + CMP：晶瑞电材（全品类）、安集科技（抛光液国内 ≈70%）、鼎龙股份（抛光垫国内 > 70%）、格林达（G5 级 TMAH 显影液）。
气体 + 前驱体 + 硅片：广钢气体（电子大宗气签了 15 年长协，国内罕见）、华特气体（光刻气国内 60%）、雅克科技 / 安德科铭（ALD 前驱体）、沪硅产业 / 立昂微（12 英寸硅片）。
靶材：江丰电子，12 英寸国内份额 > 70%，部分进入 3 纳米验证。
薄弱环节：ArF 光刻胶（南大光电、彤程刚破冰），掩模版（Photronics/Toppan/DNP 主导，国产化率极低）。

材料端最大的特点是"量"先于"价"——化学品单价指数从 2022 年的 100 跌到 2025H1 的 77.90，但景气回升直接传导到采购量。按 2026Q1 业绩外推，长鑫全年材料采购规模冲到 270 亿以上是大概率事件。

下游 · 客户与封测

股东即大客户：阿里云（持股 3.85%）、阿里网络、小米、联想、OPPO、vivo；华为昇腾系列的 HBM2/HBM3 与 LPDDR5X 由长鑫优先供应。
封测已国产化：沛顿（深科技）承接 > 50% 委外封测，长电、通富、盛合晶微补位；HBM 后段封装材料（华海诚科 GMC、联瑞新材球硅）随 2026 年底上海后段厂投产开始放量。

四、为什么 DRAM 这一波"确定性"格外强

把视角拉远，三件事同时发生：

AI 驱动的存储超级周期：Omdia 预测全球 DRAM 市场规模从 2025 年的 1505 亿美元增长到 2030 年的 5710 亿美元，CAGR 30.56%；HBM TAM 提前两年看到 1000 亿美元的水平。
三巨头扩产谨慎 + 产能向 HBM 倾斜：直接结果是 2026Q1 DRAM 平均售价（ASP）环比涨幅超 60%，明确的卖方市场。
国产替代被外部约束加速：MATCH 法案越收紧，长鑫每往国产设备多切一个百分点，对应的就是北方华创、中微、拓荆、华海清科、盛美的实打实订单。

风险也要诚实地讲：DRAM 是存储三大品类中需求被两头挤压最严重的一类（上有 HBM 抢算力侧需求、下有 NAND 抢 token 侧需求），从历史周期看也通常是最早反转的。半年 500 亿净利的高基数能维持多久，要看 H2 ASP 走势和长鑫向 G5/HBM3 的代际切换节奏。

结语

长鑫的故事，本质不是一家公司的 IPO，而是整条中国 12 英寸国产存储平台第一次被验证、被复用的过程——刻蚀和 CMP 已经跑通，薄膜沉积和清洗在跟进，量测和光刻是下一个要啃的硬骨头。

对普通投资者来说，与其押单一标的，不如把这张产业链全景图收好：HBM 的利润最暴利但跟自己关系最远，DRAM 的盘子最大、长鑫的扩产传导最直接，材料和设备里的"量增弹性"标的反而最持续。 AI 时代缺芯、缺电、缺存，长鑫正好压在"缺存"这条最确定的线上。

主要数据来源： - 长鑫科技 2026 年更新版科创板招股书； - TrendForce《Price Rally Drives 4Q25 DRAM Revenue Up 29.4%》； - Counterpoint《Global DRAM and HBM Market Share》； - Omdia DRAM TAM 预测； - 美光 FY26Q1 业绩电话会； - SK 海力士 2026Q1 财报。

USB 命名混乱救命表：从 1.1 到 120Gbps

2026-04-26T12:00:00+08:00

为什么需要这张表

USB 的命名乱到什么程度？看几个常踩的坑：

同一个速率，三个商标名：USB 3.0、USB 3.1 Gen 1、USB 3.2 Gen 1 是完全同一个东西（5 Gbps）。你在淘宝看到三种叫法只是上架时机不同。
"SuperSpeed" 比 "SuperSpeedPlus" 慢一倍：听起来就差一个 Plus，实际上一个 5 Gbps 一个 10 Gbps。
USB 3.2 Gen 2 和 USB 3.2 Gen 2x2 不是一回事：后者是双 lane，速率翻倍到 20 Gbps。x2 这个后缀很多店铺不会写。
USB4 也不是只有一种：有 USB4 20Gbps 和 USB4 40Gbps 两个档位，盒子上不写清楚就只能赌。
USB4 不等于 Thunderbolt 4，也不等于 USB-C：USB-C 只是物理接口，Thunderbolt 是 Intel 的超集协议，USB4 是 USB-IF 的协议——三者经常被混着叫。

下面这张表就是用来在买线、选 dock、判断 NAS / 移动硬盘盒接口时一眼对上号的。

营销名 vs 技术名

营销名（Marketing Name）	等价别名（Also Known As）	信号速率	理论带宽	线芯	线长上限
USB 1.1	Full Speed	12 Mbps	1.5 MiB/s	4	4 m
USB 2.0	Hi-Speed	480 Mbps	60 MiB/s	4	4 m
SuperSpeed USB 5Gbps	USB 3.0 USB 3.1 USB 3.2 USB 3.1 Gen 1 USB 3.2 Gen 1	5 000 Mbps	625 MiB/s	8	3 m
SuperSpeedPlus USB 10Gbps	USB 3.1 USB 3.2 USB 3.1 Gen 2 USB 3.2 Gen 2	10 000 Mbps	1 250 MiB/s	8	2 m
SuperSpeedPlus USB 20Gbps	USB 3.2 USB 3.2 Gen 2x2	20 000 Mbps	2 500 MiB/s	12	1 m
USB4 20Gbps	USB4 Gen 2×2 USB4	20 000 Mbps	2 500 MiB/s	12	0.8 m
USB4 40Gbps	USB4 Gen 3×2 USB4	40 000 Mbps	5 000 MiB/s	12	0.8 m
USB 80Gbps 2026 补充	USB4 v2.0 USB4 Gen 4×2 Thunderbolt 5（超集）	80 000 Mbps	10 000 MiB/s	12	1 m（被动）
USB 120Gbps 2026 补充 / 非对称	USB4 v2.0 Asymmetric Thunderbolt 5 Bandwidth Boost	120/40 Gbps	15 000 / 5 000 MiB/s	12	1 m（被动）

看表姿势：买线、买盒子的时候，先把店家写的字串去 "Also Known As" 这一列里搜，落到哪一行就是哪一行的速率。不要被 "SuperSpeed"、"USB 3.2"、"USB4" 这种笼统说法骗——它们对应着多个不同档位。

Gen 命名约定：A x B 是什么意思

USB-IF 后来给 3.x 和 USB4 加的 Gen A x B 后缀，含义其实很规整：

USB Gen A x B

A = 第几代信号（决定每个 lane 的速率）
B = 用了几条 lane（双工对数）

下面这张表把 3.2 / USB4 各代乘开后的实际速率算清楚：

名称	单 lane 信号	总信号速率^a	编码	去编码后^b	理论带宽^b	真实顺序读^c
USB 3.2 Gen 1x1	5 000 Mbps	5 000 Mbps	8b/10b	4 000 Mbps	500 MiB/s	~400 MiB/s
USB 3.2 Gen 1x2	5 000 Mbps	10 000 Mbps	8b/10b	8 000 Mbps	1 000 MiB/s	~800 MiB/s
USB 3.2 Gen 2x1	10 000 Mbps	10 000 Mbps	128b/132b	9 696 Mbps	1 212 MiB/s	~780 MiB/s
USB 3.2 Gen 2x2	10 000 Mbps	20 000 Mbps	128b/132b	19 392 Mbps	2 424 MiB/s	~1 600 MiB/s
USB4 Gen 2x2	10 000 Mbps	20 000 Mbps	128b/132b	19 392 Mbps	2 424 MiB/s	~1 600 MiB/s
USB4 Gen 3x2	20 000 Mbps	40 000 Mbps	128b/132b	38 787 Mbps	4 848 MiB/s	~2 700 MiB/s
USB4 Gen 4x2 v2.0 / 2026 补充	40 000 Mbps（PAM3）	80 000 Mbps	64b/66b	77 575 Mbps	9 696 MiB/s	~6 000 MiB/s

注：多 lane 系统在发端做 lane striping，在收端做 lane bonding，用户看到的就是一个连续 stream。
^a 厂商盒子上印的就是这一栏。
^b 减掉编码开销后的有效速率。8b/10b 损失 20%，128b/132b 损失约 3%，64b/66b 损失约 3%。
^c 实测顺序读速率（要扣掉协议层、文件系统、SSD 主控本身的瓶颈）。

理解了 Gen A x B 之后，再回头看商标名就清晰多了：所谓 "SuperSpeedPlus 20Gbps" 其实就是 Gen 2 信号 × 2 lane；所谓 "USB4 40Gbps" 其实就是 Gen 3 信号 × 2 lane。这套约定唯一的问题是 USB-IF 自己又不在卖品名里写 Gen N×M，反而强推 "USB 80Gbps" 这种以速率为名的新商标——表里第一栏就是这么来的。

线材：4 / 8 / 12 芯

USB 物理线最常见三档：

4 芯：PWR、GND、D+、D-。一对差分信号，半双工一条 lane。
8 芯：4 芯的基础上加 RX+/RX-、TX+/TX-。两条 lane，一上一下，全双工。
12 芯：8 芯的基础上再加一组 RX2+/RX2-、TX2+/TX2-。四条 lane（两上两下），全双工。

一个 USB lane = 一对 ± 差分线。所以 4 芯 = 1 个半双工 lane，8 芯 = 2 个 lane，12 芯 = 4 个 lane。USB 3.2 Gen 2x2、USB4、USB4 v2.0 这些 "x2" 的标准都是要 12 芯线才能跑满的。

USB-A / USB-B 接口（4 芯 / 8 芯）

Type-A 4-wires	Type-A 8-wires	Type-B 4-wires	Type-B 8-wires

8 芯版本的 Type-A 蓝色塑料舌片就是 USB 3.x 的标志——多出来的 5 个针脚塞在原来 4 个的下方/后方。USB-B 8 芯版本（也叫 USB 3.0 Type-B）则是直接在原本梯形上又叠了一块，所以看起来像一个驼背的小房子。

USB-C 接口（12 芯）

只有 USB-C 有足够的引脚数支撑两个完整 lane。

CC1 / CC2：Configuration Channel。两端用来识别谁是 DFP（Downstream Facing Port，主机一侧）、谁是 UFP（Upstream Facing Port，设备一侧），同时也用来协商供电档位、切到 Alt Mode（DisplayPort、Thunderbolt、HDMI 等）。
SBU1 / SBU2：Sideband Use。用作 DisplayPort 的 AUX 通道、热插拔检测（HPD）等辅助信号。

USB-C 真正强大的地方是这两组针脚——没有它们，USB 就是个纯数据口；有了它们，一根 C 线可以同时跑数据、视频、PD 供电，并且正反盲插。

充电规格 / PD 档位

规范	最大电压	最大电流	最大功率
USB 2.0	5 V	500 mA	2.5 W
USB 3.0 / 3.1	5 V	900 mA	4.5 W
USB Battery Charging (BC) 1.2	5 V	1.5 A	7.5 W
USB-C Current Mode（非 PD）	5 V	3 A	15 W
USB-C / Power Delivery（PD 1/2）	20 V	5 A	100 W
USB-C PD 3.1 EPR（Extended Power Range）	48 V	5 A	240 W

要拉满 240 W，必须是支持 EPR 的线（线身上一般直接印 EPR 240W），并且两端 charger / 设备都支持 PD 3.1。普通 100 W 线直接插上去只会握手到 100 W 档位。

2026.04 补充：USB 80Gbps 已经量产

原文写于 2022 年，那会儿的天花板就是 USB4 40Gbps。到 2026.04，新的 USB4 v2.0（USB-IF 现在统一叫 "USB 80Gbps"）已经过了 spec → silicon → 整机三道关，能在零售店里买到。

技术上和老 USB4 的关键差别：

PAM3 信号：每个 symbol 不再是 0/1 两态，而是 -1/0/+1 三态（每 symbol 携带 ~1.58 bit）。这是单 lane 速率从 20 Gbps 翻到 40 Gbps 的核心。
编码换成 64b/66b：开销从 ~3% 略降。
对称模式 80 Gbps：4 lane × 40 Gbps = 160 Gbit 信号，扣编码后约 ~9 700 MiB/s 理论值；实测顺序读目前在 6 GB/s 左右（被 NVMe 主控和 PCIe 拓扑限制住）。
非对称模式 120 / 40 Gbps：3 lane 走一个方向、1 lane 走反方向。专门给 8K 显示、外置 GPU 这种"大头朝外"的场景。USB-IF 称这个档为 "USB 120Gbps"，Intel 在 Thunderbolt 5 里叫 "Bandwidth Boost"——同一回事。
接口仍然是 USB-C，引脚数还是 12。线长上限稍微放宽到 1 m（被动铜线）；超过 1 m 一般要 active 线。

参考

原文：Fabien Sanglard — USB Cheat Sheet（2022-05）
规范文档（USB-IF 官方下载）：USB Document Library
USB 1.0（1996-01）/ USB 1.1（1998-09）/ USB 2.0（2000-04）
USB 3.0（2008-11）/ USB 3.1（2013-07）/ USB 3.2（2017-09）
USB4 v1.0（2019-08）/ USB4 v2.0（2022-10）
USB Power Delivery 3.1 EPR：USB-IF PD Spec
Thunderbolt 5 / Intel Barlow Ridge 控制器公开材料：Intel Newsroom

啤酒游戏：让 Claude 和 Codex 干了这杯酒

2026-04-21T22:00:00+08:00

上一篇讲的是同一门《运营与供应链管理》的设施选址案例。那次比较干净：重心法有唯一解，让两个 AI 互评一轮，再用 Python 跑一遍，基本就能定谁对谁错。

这次不一样。第二次课后作业是经典的啤酒游戏（Beer Game）：零售商 → 批发商 → 制造商三级供应链，真实需求在第 2 周从 4 箱/周升到 8 箱/周，之后保持稳定，但由于信息失真和 4 周提前期，链路里层层放大。案例写到：到第 24 周零售商还堆着 75 箱、批发商还堆着 218 卡车量，而制造商在第 19 周库存已经冲到 93 批。

题目三问：

画出 1–24 周库存和订单图，解释牛鞭效应
分析牛鞭效应的影响、成因、对策
假设你是“聪明零售商”，给出最优订货策略，并算出你比“普通零售商”多赚多少钱

问题 1、2 偏定性，两个 AI 答得大体接近。真正分歧出在问题 3：Claude 最初算出超额收益约 500–1000 元，Codex 最初算出 7500–7900 元。差了一个数量级。

一开始的分歧，其实不只是一道算术题

两份答案的最优订货策略看上去很接近：第 1 周按常态 4 箱，第 2 周开始往上调，之后维持 8 箱/周的稳态。真正的差别只在一句话：

Claude：第 2 周订 12 箱
Codex：第 2 周订 8 箱

但光是 4 箱之差，不足以解释为什么一个答案多赚几百元，另一个多赚几千元。真正把两份答案拉开的，是背后的两个建模选择：

行为假设：第 5 周不可避免的 4 箱短缺，到底能不能在第 6 周作为 backorder 补卖？
收益口径：第 24 周普通零售商手上的 75 箱库存，到底是资产，还是在本题比较口径里被等效忽略掉？

事后看，双方真正争的不是“谁算错了”，而是“哪套假设和口径更适合这道题”。

第一轮：双方先各自为自己的答案辩护

我先让它们各自写一份对比报告：

Claude_VS_Codex_by_Claude.md
Claude_VS_Codex_by_Codex.md

这一轮的立场很清楚：

Claude 认为自己那份更合理，因为案例 PDF 第 6、7 周明确写了顾客会留下名字电话等货，说明 backorder 真实存在
Codex 认为自己那份更严谨，因为从 24 周现金流口径看，普通零售商第 24 周手里还有 75 箱库存，占着现金、卖得慢，财务上不能当成“已经实现的收益”

如果把两边都尽量善意理解，它们其实各有抓手：

Claude 抓的是案例行为证据
Codex 抓的是比较口径和现金占用

到这一步，我还不能明确说谁一定错。因为和设施选址那题不一样，啤酒游戏这道题在第 3 问里确实存在建模自由度。

第二轮：真正让局面收敛的，不是继续争观点，而是“用对方的尺子重算一遍”

第二轮我把两份对比报告再丢回去，让双方继续回应：

Claude_VS_Codex_Round2_by_Claude.md
Claude_VS_Codex_Round2_by_Codex.md

Claude 这一轮做得最好的一点，是它没有继续停留在“PDF 原文支持 backorder”这种事实争论上，而是直接做了一件更硬的事：

用 Codex 自己定义的口径，反算 Claude 的策略。

它的核心计算逻辑是：

如果第 2 周订 12 箱，那么：

第 5 周的 4 箱缺口先形成 backorder
第 6 周正好到货 12 箱
这 12 箱刚好覆盖“第 5 周积压的 4 箱 + 第 6 周真实需求 8 箱”
之后回到稳态，每周到货 8 箱、卖 8 箱
因而 期末库存仍然是 0

按这个路径，套进 Codex 当时自己采用的“收入 - 采购 - 持有成本”的 24 周现金流式口径，会得到：

口径	Claude 策略（W2=12）	Codex 策略（W2=8）
销量（箱）	188	184
收入（元）	23,500	23,000
采购（元）	17,600	17,200
持有成本（元）	9.23	9.23
现金利润（元）	5,890.77	5,790.77
期末库存（箱）	0	0

也就是说，在同一口径下，Claude 的第 2 周订 12 箱方案，比 Codex 的第 2 周订 8 箱方案多赚 100 元。这 100 元恰好就是多履约的 4 箱 × 单箱毛利 25 元。

这一步很关键，因为它把争论从“你觉得、我觉得”推进到了“就用你自己的尺子量，结果还是这样”。

第二轮之后，Codex 的主要修正也很明确

Codex 在第二轮里做了两个重要修正。

1. 承认原先的 7500/7900 元量级不合理

它接受了一个关键点：

不能把普通零售商第 24 周剩余的 75 箱库存直接按 0 价值处理。

因为案例并没有说这 75 箱永远卖不出去。真实需求仍然大约是 8 箱/周，这些库存更合理的理解是：

期末库存资产
后续持有成本负担
潜在的折价风险和资金占用

而不是立刻等于当期亏损。

这一步修完以后，Codex 把自己原先的“多赚 7500/7900 元”回收掉了。

2. 接受“第 2 周订 12 箱”作为基准更优方案

在允许并管理 backorder 的前提下，Codex 也接受了：

第 2 周订 12 箱
第 3～20 周每周订 8 箱
第 21～24 周订 0 箱

这个策略方向。

不过这里 Codex 也补了一句我认为很重要的限定：

这个“12 箱更优”的结论，最好显式写出前提：允许并管理 backorder。

我认为这是必要的，因为 PDF 确实证明了 backorder 现象存在，但它并不自动等于“第 5 周那 4 箱一定 100% 都能补卖”。所以更稳妥的说法，不是“无条件严格最优”，而是“在题目给定的聪明零售商设定下，作为基准解更合理”。

到最后，双方其实收敛到了什么？

如果只看“最后谁赢”，这个过程会被误读成：

Claude 证明了自己是对的
Codex 改口认输

但我觉得更准确的描述是：

双方最后在“主策略”和“收益量级”上基本收敛了，但在普通零售商对照组的具体重构数值上，还没有完全统一。

已经收敛的部分是：

第 1、2 问两边都能作为参考
第 3 问的基准策略应以“第 2 周订 12 箱”为主
这个策略的前提是：允许并管理 backorder
原先的 7500/7900 元 应判为口径失真，不再成立
更合理的收益量级是：几百元到一千元左右

但还没有完全统一的部分是：

Claude 版当前仍把中心值写成 727 元
Codex 修订后写成了基准 476 元，并把现实区间写成 500～1,000 元

这说明它们已经没有大的结论性冲突，但还保留着一个典型的“同方向、不同中心值”的建模差异：普通零售商路径到底按哪组重构数据来算。

一个小插曲：我自己也踩了“AI 不重读文件”的坑

这轮还有个挺好玩的插曲。

共识文件落完之后，我又让 Claude 再检查一次两份正式答案是否还有逻辑冲突。按道理说，这一步应该先重读最新版文件再比。

但它一开始并没有这么做。它直接沿用脑子里前几轮的旧印象，给了我一个“已经基本没问题”的判断。我后来自己去看文件，才发现：

Codex 的正式答案已经被修订过了
第 3 问的主策略、收益区间、口径说明都已经更新了
但 Claude 那次检查没有先读最新版，就直接开始比较

我后来让它重新读取文件，再做一遍结论，结果就正常了。

这件事让我挺警惕一件事：

AI 在多轮上下文里，不是只会“算错”，它也会像人一样偷懒地以为自己还记得文件长什么样。

所以现在我的默认流程变成了：

跨轮复核前，明确要求它重新读取目标文件
不接受“基于之前讨论我认为……”这种比较
文件类任务尽量让它把引用行号和当前版本一起报出来

这次复盘，对流程最大的启发是什么？

1. 有争议的题，不能只让双方“表态”，要让它们“同口径重算”

第一轮的问题在于，双方都能自圆其说：

Claude 说：PDF 支持 backorder
Codex 说：现金口径更保守

这两句话都没错，但都还不够“打穿”对方。第二轮真正让问题收敛的，是 Claude 改变了打法：不用自己的尺子，而是用 Codex 自己的尺子，去量 Claude 的方案。

这比继续争抽象原则有效得多。

2. 案例题里，分歧很多时候不是“算错”，而是“口径没统一”

设施选址那题属于“公式题”，ground truth 比较硬。

啤酒游戏第 3 问更像“建模题”：

backorder 怎么处理
期末库存怎么估值
普通零售商的路径怎么重构

这些都不是 PDF 直接给好的唯一答案，而是解释空间。

所以这种题最重要的不是先问“谁对谁错”，而是先问：

你们是不是用了同一套假设？
你们是不是在用同一套收益口径？

3. 最终共识最好落成文件，而且最好双方都落

这次最终比较清楚的阶段，不是嘴上说“好像差不多了”，而是双方都逐步把立场修正进文件：

Claude_VS_Codex_Final_Consensus_by_Claude.md
Claude_VS_Codex_Final_Consensus_by_Codex.md
以及修订后的 answers/啤酒游戏-案例解答_Codex.md

一旦文件更新，后续讨论就有了稳定落点。否则很容易出现“口头上已经同意了，原答案还停留在旧版本”的错位。

这道题本身也给了我一个额外收获

我觉得这次最有意思的，不只是“谁算赢了”，而是它把一个课堂上常讲、但很多时候很抽象的管理问题，演得特别具体：

同一个案例、同一份 PDF，只要口径和隐含假设不统一，最后得出的“结论”就可能差一个数量级。

这和牛鞭效应本身很像。牛鞭效应里，上游看到的不是“需求”，而是“需求 + 滞后 + 情绪 + 防御性下单”。这次两个 AI 一开始看到的也不是同一个“收益”，而是：

收益 + backorder 假设
收益 + 库存估值口径

所以最后真正值得记住的，不是 7900 还是 727，而是：

在供应链和管理分析里，先统一口径，再比较数值，往往比争谁的数字更大更重要。

尾声

AI 也会偷懒，也会划水。 而且不是个案，使用 AI 也是要走心的~

我是怎么让 Claude 和 Codex 帮忙完成课程作业

2026-04-20T22:00:00+08:00

这学期有一门《运营与供应链管理》，第二次课留了个案例作业：南方超级医疗设备公司的设施选址。题目不难，标准的重心法（Center of Gravity）单仓库选址问题，考的是套公式 + ROI 判断。

我照例先让 Claude 做了一份，给了一个看起来挺漂亮的参考答案。觉得不放心，开了一个新的会话用 Codex 再独立跑了一遍。拿到结果之后我愣住了：两份答案的思路完全一致，计算出来的最优坐标相差不大，但最终 ROI 正负相反、决策完全相反。

Claude：重心在 (7.42, 5.04)，年运输节约 $46,838，ROI −188%，结论：续租堪萨斯城，别搬
Codex：重心在 (7.58, 4.51)，年运输节约 $223,646，ROI +41.22%，结论：应当搬迁

两个都是基于同一份 PDF 案例、同一个重心法公式，怎么会算出一正一负？

左右互博：把裁判位置也交给 AI

我本来的计划是自己动手验算一遍，但看了一会儿发现这事没那么简单——重心法有两个版本（一次加权平均 vs Weiszfeld 迭代）、费率 R 的单位有两种理解（美元/担 vs 美元/担/英里）、外向成本又有两种建模方式。要真人判裁谁对谁错，我得先把讲义从头翻一遍。

懒病发作，我干脆把两份答案一起丢回一个新的 Claude 会话，原话是这样的：

你完成的解答位于：南方医疗设备公司设施选址_参考答案-Claude.md 我使用其他模型解答的结果和你基本不一致，虽然思路是相同的，结果位于：南方医疗设备公司设施选址-案例解答-Codex.md 请检查双方究竟谁的逻辑存在问题，并给出支撑理由，如有必要，请修正完善最终版本结论

注意这里：Claude 开新会话后其实是没有前次对话记忆的，所以这份 _参考答案-Claude.md 对它而言就是一份陌生的答案，和 Codex 的那份在它眼里是对等的。这样它就没有「维护自己面子」的心理包袱。

Claude 翻出了自己的错

它做的第一件事是去读讲义 PDF 里重心法的原始公式。这一步关键——它不是在两份答案的输出之间找分歧，而是把两者都对照原题和教材做 ground truth 校对。

几分钟后它给出了结论：

Codex 的逻辑正确，Claude 的参考答案存在三处方法论错误。

三处错误它一条条列了：

1. R 的单位错。 讲义里目标函数是 TC = Σ Vᵢ·Rᵢ·dᵢ，要求 Rᵢ 为「美元/担/英里」。案例表里给的是「美元/担（当前线路总费率）」，必须除以当前距离才能换算。案例原文第 2 页其实写得很清楚：「可估计出以仓库为起点的外向运输平均成本为 0.0235 美元/担/英里」——这句话就是在提示学生做单位换算。前一次 Claude 把这段忽略了，直接把美元/担当权重用，相当于把当前距离"二次放大"进了权重里，让远距离客户影响被高估。

2. 没迭代。 讲义 p.13 把步骤写得很明白：先用 X₀ = Σ(V·R·X)/Σ(V·R) 算一个初始坐标，然后根据 dᵢ 做 Weiszfeld 迭代直到收敛。前一次 Claude 算完初始坐标就收工了。

3. 外向费率结构错。 案例文本明确给了一个统一的外向均值 0.0235。前一次 Claude 反其道而行之，按每个客户的当前总费率和距离回推了每客户不同的每英里率。这会让 Chicago 显得每英里 0.050、Montreal 每英里 0.019，两者相差 2.6 倍——这种人为的不一致把新选址的外向成本虚推高了，把真实 $223K 的年节约压成虚假的 $47K。

这三处错误串在一起，合力把最优点错误地向东北拉偏、又错误地抬高了新址的外向账单，最终得到"别搬"的结论。Codex 在这三点上都是按讲义和案例原文来的。

用 Python 作第三个独立裁判

到这一步其实已经够了，但我让 Claude 再做一件事：别用自己的文字推理下结论，写段 Python 从头算一遍，以程序的数值输出为准。

下面这段是它写的（我稍微整理了一下）：

import math
k = 230.0  # 1 坐标单位 = 230 英里

# (V, R_per_mile, X, Y) — 内向用个别每英里率，外向统一 0.02346
nodes = [
    (61500,  0.01438521, 3.60, 3.90),   # 菲尼克斯
    (120600, 0.00791246, 6.90, 1.00),   # 蒙特雷
    (17000,  0.02346330, 0.90, 9.10),   # 西雅图
    (32000,  0.02346330, 1.95, 4.20),   # 洛杉矶
    (12500,  0.02346330, 5.60, 6.10),   # 丹佛
    ( 9500,  0.02346330, 7.80, 3.60),   # 达拉斯
    (29500,  0.02346330, 10.20, 6.90),  # 芝加哥
    (21000,  0.02346330, 11.30, 3.95),  # 亚特兰大
    (41300,  0.02346330, 14.00, 6.55),  # 纽约
    ( 8600,  0.02346330, 12.70, 7.80),  # 多伦多
    (10700,  0.02346330, 14.30, 8.25),  # 蒙特利尔
]

# 初始种子
X = sum(V*R*Xi for V,R,Xi,Yi in nodes) / sum(V*R for V,R,Xi,Yi in nodes)
Y = sum(V*R*Yi for V,R,Xi,Yi in nodes) / sum(V*R for V,R,Xi,Yi in nodes)

# Weiszfeld 迭代
for _ in range(100):
    nx = ny = d = 0.0
    for V,R,Xi,Yi in nodes:
        di = k * math.sqrt((X-Xi)**2 + (Y-Yi)**2)
        if di < 1e-6: continue
        w = V*R / di
        nx += w*Xi; ny += w*Yi; d += w
    Xn, Yn = nx/d, ny/d
    if abs(Xn-X) + abs(Yn-Y) < 1e-7: break
    X, Y = Xn, Yn

def TC(Xp, Yp):
    return sum(V*R * k*math.sqrt((Xp-Xi)**2 + (Yp-Yi)**2) for V,R,Xi,Yi in nodes)

print(f"optimum = ({X:.4f}, {Y:.4f})")
print(f"TC @ KC  (8.20, 6.00) = {TC(8.20, 6.00):,.0f}")
print(f"TC @ Claude(7.42,5.04) = {TC(7.42, 5.04):,.0f}")
print(f"TC @ Codex (7.58,4.51) = {TC(7.58, 4.51):,.0f}")
print(f"TC @ optimum          = {TC(X, Y):,.0f}")

跑出来的输出：

optimum = (7.5806, 4.5084)
TC @ KC  (8.20, 6.00) = 6,983,017
TC @ Claude(7.42,5.04) = 6,792,698
TC @ Codex (7.58,4.51) = 6,759,371
TC @ optimum          = 6,759,371

几件事一次性水落石出：

Weiszfeld 迭代收敛到 (7.5806, 4.5084)，和 Codex 的 (7.58, 4.51) 逐位对上
Codex 那份的 TC $6,759,371 在正确方法下也正好是最优值
Claude 前一份的 (7.42, 5.04) 在正确方法下 TC 是 $6,792,698——比最优值贵了 $33K/年，连局部最优都不是
堪萨斯城 TC $6,983,017 和题目给的 $6,982,104 差不到 0.02%（差异来自案例里距离和均值的四舍五入），说明用的参数都没偏

然后年节约 $223,646，减去每年 $10 万新增租金，一次性搬迁投入 $30 万，年 ROI 41.22%，远高于 25% 阈值。正确结论是应当搬迁。

然后它把自己之前写错的那份改了

我让它把修订版直接覆盖原文件，同时在文件顶上标注修订说明。它交出的文件顶部是这样的：

# 案例：南方超级医疗设备公司设施选址 —— 参考答案（修订版）

> 修订说明：本版本相对于初版修正了三处方法论错误——
> (1) 将运输费率 R 从「美元/担」换算为「美元/担/英里」；
> (2) 在初始种子 (X₀, Y₀) 的基础上补充 Weiszfeld 迭代；
> (3) 外向费率按案例原文统一取 0.02346 美元/担/英里，而非按客户回推。
> 修订后结论从「维持堪萨斯城」转为「应搬迁至 (7.58, 4.51) 附近」。

三个情景（Q1 基准、Q2 需求变化、Q3 费率上涨）的结论全部翻过来，ROI 从负值变成 41%–60% 区间，决策从"别搬"变成"都该搬"。

为什么「左右互博」比让单一模型深挖更靠谱

这件事让我后面做类似作业时固定下来了一套流程：一份答案让 A 模型做，一份让 B 模型做，再让 A 当裁判评 B，要求它必须回到原始材料（讲义/教材/题目原文）做 ground truth 校对，最后用 Python 当第三方复算。

为什么这么折腾？几个观察：

单一模型很难发现自己的方法论偏差。 如果我一开始就让 Claude 自己审自己那份答案，它大概率会在"既有框架"里找局部的算术错误，而不会去质疑 R 的单位、是否需要迭代这种框架本身的选择。Codex 那份答案的存在提供了一个不同的框架作为参照，这时候回到原题去校对才有意义。换句话说：两个答案的差异不在于谁算得更准，而在于把可能的解法空间暴露了出来。

当裁判比当选手更挑剔。 让 Claude 做题时它倾向于快速给出一个自洽的流程。让它当裁判时，它会去对照原文、逐字抠公式、做单位分析。同一个模型、同一个任务知识，输出质量差很远——角色不同，防御姿态不同。

Python 兜底是性价比最高的一步。 两个模型吵起来的时候，文字推理再漂亮也有可能都错。让它们最后落到一段可执行的代码上，数值一跑就有定论。这次 Python 确认 (7.5806, 4.5084) 是严格最优，也顺手把 Claude 自己给的 (7.42, 5.04) 彻底证伪了——文字说它"连局部最优都不是"显得没说服力，一行 TC(7.42, 5.04) = 6,792,698 > 6,759,371 谁都没法赖。

模型之间没有「面子」问题。 前面提到我没告诉新会话的 Claude 那份错答案是它自己写的。这是有意为之——同一个账号、同一个模型，它如果意识到是在审自己的作业，有没有可能措辞会软一点？我不敢保证。切掉身份线索，让它以陌生答卷的姿态去评，才放得开。

我有不担心的地方，也有担心的地方

不担心的是：作业本身是死题、有唯一答案、可以程序化验证。在这类场景下 AI + AI + 代码的组合已经比我自己从头算可靠得多——我自己算大概率也会在哪一步单位换算上犯 Claude 初版犯的那种错。

担心的是：不是所有作业都有"Python 可跑的 ground truth"。比如案例讨论题让写一份"定性分析报告"的时候，两个模型可能会写出两份看起来都通顺、实则都在偏差范围内的答卷，而我没有外部锚点去判对错。这种时候"左右互博"只能证伪明显的错误，不能正向保证正确。

但即便如此，让 AI 看它同行的作业依然比让 AI 看自己的作业要诚实。这是我这次学到的最实用的一招。

尾声

借助 AI ，我弄清楚了重心法为什么要迭代、为什么 R 必须是每英里率——这两件事要是我自己硬看讲义，大概率和 Claude 初版踩一样的坑。把作业交给 AI 之后，我反而把原理学得更明白了。

这件事我没推广到所有课——有些课的作业本来就是要自己算才算练到手（比如数理课）。但对那些"考的是方法，不是手算熟练度"的课，我现在的默认姿势就是两个模型互评 + 代码兜底。花的时间比自己硬做少得多，踩的坑反而更少。

下次有类似的折腾再来记录。

用 Cloudflare Worker + KV 给静态博客加一个浏览量计数

2026-04-19T23:00:00+08:00

上一篇换主题写完的时候，心里还有一个未了的念头：新主题把 Google Analytics 那坨早就停服的 UA 代码删了之后，整站就零统计了。写的时候没想太多，但上线一两天之后，每次点开自己的博客都有一种「在给空气写字」的感觉 —— 到底还有没有人看，哪篇被多读几遍，完全没有信号。

于是今晚继续折腾，给每篇文章加一个浏览量，顺带在页脚放一个整站 PV / UV。效果本身没什么稀奇，技术栈和取舍倒值得说一下。

静态站做计数的几种路子

博客源码在 source 分支，CI 构建后推到 gh-pages，GitHub Pages 托管。这个架构的好处是零运维、免费；坏处是 没有访问日志，GitHub 只在 Traffic API 里给 14 天的 top paths，而且要 OAuth 认证，前端根本用不了。

所以任何「在线计数」都得外挂。我考虑过的选项按接入门槛排列大概是这几类：

方案	接入	数据归属	可控性
不蒜子	粘两行 script	第三方	几乎无
GoatCounter 云版	注册、粘 script	第三方	有仪表板和 API
Umami / Plausible 自托管	要一台 VPS	自己	完全
Cloudflare Worker + KV	写个 Worker	自己	完全

这四类都想过。

不蒜子 是中文博客圈最常见的选择，粘两行 JS 就能在页面上显示数字。但它不支持写入初始值、不暴露 API，偶尔还会抽风（busuanzi.ibruce.info 服务不稳是老问题了）。更关键的是：刚删完一大票第三方脚本（GA、AdSense、Disqus）的新主题，再挂一个外链，心理上拧巴。

GoatCounter 其实是符合我审美的选择 —— 开源、隐私友好、有 API、能自建也能用云版。唯一拿不准的是国内访问 goatcounter.com 的稳定性，以及把读者数据托管给第三方（哪怕它是隐私友好的）仍然是「托管」。

自托管 Umami / Plausible 需要一台 VPS 常驻。对一个每月也写不了一两篇的博客，养一台 VPS 就为了这个，是过度消费。

Cloudflare Worker + KV 最终胜出。几个原因：

我本来就是 CF 用户（域名 DNS 在 CF），账号、DNS 都是现成的
Worker 免费档 100k 请求/天、KV 1k 写/天 + 100k 读/天，对个人博客是绰绰有余的天花板
边缘节点在国内延迟一般不差
Worker 是一张多用途底牌 —— 未来要做外链跳转计数、RSS 订阅数统计、简单的 webhook 都能复用同一套基础设施

唯一的缺点是要自己写代码、自己部署。但需求简单到几十行 TS 就能搞定，还换不来过度工程的烦恼。

先用 OpenSpec 把事情说清楚

跟上次换主题一样，动手之前我先让 Claude 用 OpenSpec 写了一份变更提案：

openspec/changes/add-article-view-counts/
├── proposal.md   # 为什么、要改什么、不改什么
├── design.md     # 技术决策与取舍
├── specs/        # 可测试的规范（分三个 capability）
└── tasks.md      # 38 条分步任务

好处和上次一样 —— 边界清晰。比如 design.md 里写死了几个关键决策：

计数口径 粗放全算：不按 IP 去重，不识别爬虫。我的需求是「大致知道哪些文章有人读」，不是给广告主看的精确数字
不做 time series：KV 里只存当前累计值。要趋势数据直接看 CF Dashboard 自带的请求图即可
UV 用 sha256(IP + 当日日期 + salt) 去重：每日盐轮换，不能反推原 IP，GDPR 友好
seed 在前端叠加：这是整个方案最值得单独讲的一点

seed 前端叠加：让老文章不从零起算

启用新计数有个心理坎：所有老文章（最早是 2013 年）都会从 0 开始。十三年前写的博文显示「0 次阅读」，哪怕它本来就没几个人读过，视觉上也很刺眼。

最直接的办法是在 KV 里预填一个初始值，让 pv:<slug> 从比如 3000 起算。但这样做有个恶心的地方：哪天想调整初始值（比如觉得这篇估高了），要从当前值里减掉旧 seed 再加新 seed，很容易算错。

我最终用的办法是 把 seed 放在前端：

// themes/stuhouse/static/data/view-seeds.json
{
  "install-bind-mysql-dlz":    3900,
  "debian-add-cnnic-ca":       3900,
  "pelican-custom-jinja-filters": 3900,
  "postgraduate":               300,
  "peril-of-laziness-lost":       0
}

前端展示时：

display = (seeds[slug] || 0) + realtime_pv_from_worker

这样做的好处有三点：

seed 在 git 历史里。想调整某篇文章的初始值，就是一次普通的 JSON 编辑 + commit，审计友好
数据层与展示层解耦。以后后端换成 GoatCounter / 自建服务，seed 逻辑一行不用改
新文章自动 seed = 0。JSON 里没这个 slug 就当 0，无需特殊处理

seed 数值本身来自一个简单的脚本 scripts/generate_view_seeds.py，公式是 max(评论数 × 120, 年数 × 300)。因为没导 Disqus 数据（懒得等那封导出邮件），实际跑的是纯年份兜底 —— 2013 年老文显示 3900 次阅读，2025 年新文显示 300 次，2026 年刚发的新文显示 0。不精确，但读起来自然。

Worker 侧：两个端点、几行代码

核心逻辑在 worker/src/index.ts，就两个路由：

// GET /v/<slug> → 单篇文章 PV 自增并返回
async function handleSlug(slug: string, env: Env) {
    const key = `pv:${slug}`;
    const cur = parseInt((await env.VIEWS.get(key)) || "0", 10);
    await env.VIEWS.put(key, String(cur + 1));
    return json({ pv: cur + 1 });
}

// GET /v/site → 整站 PV + UV
async function handleSite(request: Request, env: Env) {
    const ip = request.headers.get("CF-Connecting-IP") || "0.0.0.0";
    const today = ymd(new Date());

    // 站点 PV：粗放自增
    const sitePv = parseInt((await env.VIEWS.get("site:pv")) || "0", 10) + 1;
    await env.VIEWS.put("site:pv", String(sitePv));

    // 当日 UV：hash(ip + date + salt) 作 key 去重
    const hash = await sha256Hex(`${ip}|${today}|${env.SALT_SECRET}`);
    await env.VIEWS.put(`uv_today:${today}:${hash}`, "1", {
        expirationTtl: 60 * 60 * 48,
    });

    // 当日 UV size + 历史归档累计
    const todayCount = await countPrefix(env, `uv_today:${today}:`);
    const siteUvTotal = parseInt((await env.VIEWS.get("site:uv")) || "0", 10);
    return json({ pv: sitePv, uv: siteUvTotal + todayCount });
}

两件事值得注意。

KV 没有 atomic increment。上面的 get → +1 → put 在并发写入时理论上会丢计数。但这是个人博客，真并发极低，丢一两次也无所谓 —— 这正是「粗放口径」的含义。如果哪天真撞上高并发，再迁 Durable Object 就是，当下不过度设计。

UV 归档用 cron 做。每天 UTC 00:05 触发一次 scheduled 事件，列出昨日所有 uv_today:<date>:* key 的数量累加到 site:uv，然后把这些 key 删掉。这样 uv_today:* 只保留今天一天的数据，不会无限膨胀。

部署踩坑：custom_domain 的首次 deploy

整个部署靠 wrangler CLI 完成。wrangler.toml 填好 KV namespace id、secret 绑定、cron 触发器之后，一条 wrangler deploy 就能上线。但第一次配 custom_domain 时，我走了个小弯路。

原计划（也是 tasks.md 里最初写的）是老路子：先在 CF DNS 面板手工加一条 views.chenxiaosheng.com 的 A/AAAA 占位记录（任意 IP，重点是 Proxy 状态 orange cloud on），然后在 CF Dashboard 配置 Workers Routes 规则。

后来发现 wrangler 现在有更优雅的写法：

[[routes]]
pattern = "views.chenxiaosheng.com"
custom_domain = true

加上 custom_domain = true 这一行，wrangler deploy 会自动：

给这个子域创建 DNS 记录
向 CF 申请 edge 证书
把 Worker 绑到该 hostname

一条命令搞定 DNS + 证书 + 路由三件事，比老路子干净得多。

有个小注意点：首次 wrangler deploy 之前需要先 wrangler secret put SALT_SECRET，但 put secret 时会触发一次占位 deploy。如果 wrangler.toml 里已经有 custom_domain 配置而 DNS 还没就绪，会报错。保险做法是先把 [[routes]] 段注释掉，完成 secret put 和首次 deploy（会部署到 *.workers.dev），再取消注释重新 deploy 启用 custom domain。我踩过一次之后把这个顺序写进了 tasks.md。

前端：不到 50 行

前端逻辑全在 themes/stuhouse/static/js/views.js。页面加载后做两件事：

function showSiteStats() {
    fetch(WORKER_BASE + '/v/site').then(r => r.json()).then(data => {
        document.getElementById('site-pv').textContent = fmt(data.pv);
        document.getElementById('site-uv').textContent = fmt(data.uv);
        document.getElementById('site-stats-wrap').hidden = false;
    }).catch(() => {/* 静默 */});
}

function showArticlePv() {
    const slug = document.body.dataset.slug;
    if (!slug) return; // 非文章页跳过
    Promise.all([
        fetch(SEEDS_URL).then(r => r.json()).catch(() => ({})),
        fetch(WORKER_BASE + '/v/' + slug).then(r => r.json()).catch(() => null),
    ]).then(([seeds, pvData]) => {
        if (!pvData) return;
        const total = (seeds[slug] || 0) + pvData.pv;
        document.getElementById('article-pv').textContent = fmt(total);
        document.getElementById('article-pv-wrap').hidden = false;
    });
}

几个刻意的设计：

所有展示元素初始是 hidden 的，JS fetch 成功才 reveal。失败就保持隐藏 —— 禁用 JS 的读者看到的页面和接入前完全一致，不会出现占位符或半成品
两个 fetch 彼此独立，一个失败不影响另一个
数字用 Intl.NumberFormat('en-US').format() 加千分位，这行代码比 polyfill 轻多了
文章页由 <body data-slug="..."> 带出 slug；非文章页（归档、标签）body 上没这个属性，JS 直接跳过

加上 CSS 小样式和一个眼睛图标的 inline SVG，前端总共改动不到 50 行。

跑起来之后的样子

上线之后，页脚多了一行：

本站累计阅读 1 次 · 访客 1 人

点开最早那篇 2013 年的《配置 Bind 使用 MySQL dlz 模式》，meta 行变成：

📅 2013-09-09 · 约 3 分钟阅读 · 👁 3,901 次阅读

seed 3900 加上我刚刷的 1 次。整体效果自然，没有违和感。

观察几个刻度：

KV 免费额度：单次页面加载触发 1-2 次 fetch，按每日 100 个访客估算，一天产生约 200 次 write，远低于 1000/天的上限
延迟：Worker 冷启动毫秒级，国内访问通过 CF 边缘节点基本感知不到
CF Dashboard：免费账户自带的 Analytics 已经能看请求量、错误率、cron 触发记录，不需要额外仪表盘

写在后面

整套方案从 OpenSpec 提案到上线，节奏大致是：晚上跟 Claude 对了一轮选型、起草了 proposal 和 tasks，之后花了一个下午跑完 38 条任务里的 36 条（剩两条是明天早上验证 cron 和 UV 归档用的）。工作量其实不大，但过程里有两个体会想记一下。

seed 叠加这个 pattern 值得收藏。它把「初始化数据」这个一次性需求，从数据层（KV）挪到了展示层（前端 JSON），代价是每次渲染多读一个文件，换来的是可审计、可解耦、可迁移。同样的思路可以用在评论数迁移、积分系统初始化、任何「旧数据 + 新增量」的场景里。

CF Worker 作为静态站的「副引擎」很好使。它不改变「源码 + 静态输出」的主流程，却能把那些需要「一点点动态能力」的需求接住 —— 计数、跳转、短链、webhook、简单的 API 代理，都是十几行代码的事。很多人把「加动态能力」和「离开静态站」划等号，其实没必要。

至于今晚之前那个「在给空气写字」的感觉，暂时还没消失 —— 刚上线，KV 里真实数据也就一两条。但架构至少支持知道答案了，剩下的就交给时间。

Claude 在这个周末帮我翻新了博客

2026-04-19T20:30:00+08:00

上一篇《LLM 让程序员的编程美德「懒惰」更显重要了》发完没几天，自己倒先干了一件极其「懒惰」的事 —— 周六晚让 Claude 把博客主题从 2014 年的 Bootstrap 3 一路翻修到新写的 stuhouse。

折腾完准备写这篇更新稿的时候，想起前几天那次「双仓库合一」也是 Claude 陪着做的。两次经历放在一起回看，心里有些话想讲。

背景：博客的技术债从哪来

这个博客从 Pelican 起步就没怎么动过骨架，细数下来积了一堆账：

主题 pelican-bootstrap3 基于 Bootstrap 3.1.1，2019 年已经 EOL
FontAwesome 3 的 icon-* 前缀和后来加载的 FA 4.7 不兼容，图标基本不渲染
导航栏的 .navbar-collapse 没有汉堡按钮，移动端扩展菜单打不开
侧边栏被 hidden-xs hidden-sm 整体隐藏，手机读者看不到任何侧栏元素
还挂着一个 2023 年 7 月就停服的 Google Analytics UA 代码
存在 IE8 兼容分支（respond.js、jXHR.js、条件注释）
<html> 缺 lang 属性，DEFAULT_LANG='en' 和中文内容自相矛盾

虽然写的很少了，但每次打开博客都在心里念叨一句「改一下吧」，然后关掉浏览器。就这么好几年了。

案例一：双仓库合一

在讲主题之前，先倒回去讲一下更早的一次改造。

博客最早的源码放在 Bitbucket，GitHub 上的这个仓库 stutiredboy.github.io 只存构建产物。这种「源码 + 发布」分离的结构是早年从别人那抄来的，对当时的我来说是合理的：Bitbucket 支持免费私有仓库，GitHub Pages 又必须 public。

但维护起来很累：

每次写完文章要先 push 到 Bitbucket，本地 pelican content，再去 GitHub 仓库 push 生成的 HTML
两个仓库的 commit history 基本断裂，追溯改动很费劲
源码仓库没有 CI，发布靠手工

2026 年 4 月中旬，我让 Claude 帮我把这个流程整合了：所有源文件迁到 GitHub 这个仓库的 source 分支，gh-pages 分支改由 GitHub Actions 自动构建 + force-push。

提交记录里那条 Migrate Pelican blog source from bitbucket to single-repo structure 就是这次改造的结果。合并后的工作流简单了不少：

改完文章 push 到 source
Actions 自动跑 pelican content，推到 gh-pages
线上站就更新了

这次改造范围不大，但其实挺花时间，我自己拖了好几年没做。Claude 基本就是 prompt + 15 分钟的事情，包括 deploy workflow 的编排、.gitignore 的合并、content/extra/CNAME 怎么放都替我想明白了。

案例二：这个周末，换主题

这次范围大得多。

用 OpenSpec 先把事情说清楚

技术债那么一大堆，要是自己硬上，大概率会陷入「改一点发现另一个地方也得改」的泥潭，特别是改主题，人肉改起来是真累。这次换主题之前，我先用 OpenSpec 的工作流写了一份变更提案：

openspec/changes/modernize-blog-theme/
├── proposal.md   # 为什么要改、改什么、不改什么
├── design.md     # 新主题的视觉和技术决策
└── tasks.md      # 分阶段任务清单

proposal 里最关键的是 Non-Goals 那一段，明确写了「不引入站内搜索、不引入新评论系统、不做 PWA、不保留旧主题做 A/B 切换」。有了这段边界声明，后面实现的时候就不会被无关想法拉偏。

新主题 stuhouse

新主题目录是 themes/stuhouse，整体思路：

单列居中，正文最大宽度约 720 px
极简顶栏：站名、归档、简介、RSS、明暗切换
桌面宽屏（≥ 1200 px）右侧有 sticky TOC，移动端折叠
彻底去掉侧边栏，标签云迁到独立的 /tags.html
中文系统字体栈（PingFang SC → HarmonyOS Sans SC → 微软雅黑 → system-ui），零字体请求
暗色模式跟随 prefers-color-scheme + 顶栏手动切换，localStorage 持久化
代码块基于 Nord 配色，浅色、深色两套，带一键复制按钮

技术栈清理得更彻底：Bootstrap 3、jQuery、FontAwesome、respond.js、jXHR.js 全删；图标改成内联 SVG；Google Analytics / Disqus / AdSense 相关代码一并下线。

一个中间的小坑

周六 23 点开始挂着 claude 跑，周日早上起来直接可以人工验收了。按 Claude 提示启动 pelican --listen，浏览器打开 http://127.0.0.1:8000，样式完全不对（以下修复还是 Claude 干的）。

开发者工具一看：

GET https://www.chenxiaosheng.com/theme/css/main.css
=> [FAILED] net::ERR_BLOCKED_BY_ORB

原因是 pelicanconf.py 里 SITEURL = 'https://www.chenxiaosheng.com' 直接写死成生产域名，本地生成的 HTML 里所有资源链接都指向线上，自然加载不到新主题的 CSS。

Pelican 社区的标准做法是拆分 dev/prod 两份配置：

pelicanconf.py：SITEURL = ''，本地预览用，生成根相对 URL
publishconf.py：继承 pelicanconf，覆盖 SITEURL 为真实域名，CI 构建用

顺带把 GitHub Actions workflow 的构建命令从 -s pelicanconf.py 换成 -s publishconf.py。再跑 pelican --listen，样式全部到位。

归档

最后把 openspec/changes/modernize-blog-theme/ 迁到 openspec/changes/archive/2026-04-19-modernize-blog-theme/，这个变更就算完结了。tasks.md 里的每一项都对应真实的代码改动，想回溯某个决策随时能翻到上下文。

用 AI 修基础设施的一点体感

两次改造拉通一起看，有几点观察。

AI 缩短了「想做」和「开动」之间的距离。 双仓库合一这件事我拖了好几年，主题翻修拖得更久。之所以一直不动，是因为每次想起来都要估算「我得花多久」「会不会中途卡在某个坑里」。有了 Claude 之后，这个心理门槛明显降低：哪怕卡住，它能帮我很快试出方向，沉没成本低得多。

但 AI 不会替我做判断。 OpenSpec 这种「先写提案再动手」的节奏，核心作用是逼我自己把事情想清楚 —— Non-Goals 该写哪些、视觉调性参考谁、侧边栏留不留。这些决策 Claude 给不了，它最多帮我把判断落成代码。

「懒惰」这事，AI 和人的方向是反的。 上一篇文章里引用了 Bryan Cantrill 的观点：LLM 不受时间约束，没有「为未来的自己省力」的动机，放任它会让系统越滚越大。我这次刻意在 proposal 里写死边界，就是给它上一道缰绳。最终 stuhouse 的代码量比旧主题少了一大截，就是这个约束的结果。

尾声

这篇文章本身是在新主题下写的。预览窗口里看过去，正文宽度、代码块配色、TOC 高亮、复制按钮都按预期工作。写博客这件事本来应该只关心文字本身，过去那些年花在「发布流程怎么跑通」「主题哪里又坏了」上的精力，现在终于可以还给写作本身了。

LLM 让程序员的编程美德“懒惰”更显重要了

2026-04-15T21:30:00+08:00

本文基于 Bryan Cantrill 的博文 The Peril of Laziness Lost 进行半翻译半解读。

最近读到 Bryan Cantrill 的一篇博文，标题叫 The Peril of Laziness Lost（「懒惰」丧失之险）。Cantrill 是 DTrace 的共同作者、Sun Microsystems 前工程师、Oxide Computer 的联合创始人，在系统编程领域是教父级的人物。这篇文章从 Larry Wall 提出的「程序员三大美德」出发，讨论了 LLM 对软件工程的深层影响。读完之后觉得切中要害，值得展开聊聊。

程序员的三大美德

Larry Wall 在经典著作 Programming Perl（业界称为「骆驼书」）中提出了程序员的三大美德：懒惰（Laziness）、急躁（Impatience）和傲慢（Hubris）。

原文引用如下：

If we're going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris, the basis of good software design. We've all fallen into the trap of using cut-and-paste when we should have defined a higher-level abstraction, if only just a loop or subroutine.

这三个词乍听像是贬义，但 Larry Wall 赋予了它们完全不同的含义。其中「懒惰」最为深刻：它不是说程序员偷懒不干活，而是说好的程序员会因为「懒得重复做同一件事」，从而被驱动着去构建更高层次的抽象，让系统变得尽可能简洁。

Cantrill 对此的理解是：懒惰驱使我们把系统做到尽可能简单（但不能过于简单）——去开发强大的抽象，从而让更多的事情变得更容易。

懒惰的悖论：偷懒需要付出大量努力

这里有一个精妙的悖论：要做到「懒」，其实需要非常努力。

当程序员看似在「摸鱼」——躺在吊床上发呆、盯着天花板想问题——实际上是在反复推敲问题的本质。这种「吊床驱动开发」（hammock-driven development）是真正的智力劳动。程序员愿意在当下花费大量时间去打磨抽象，是因为在优化「未来的自己」的时间。当这个计算做对了，效果是辉煌的：好的抽象不仅服务于自己，还惠及所有后来者。

换句话说，程序员的懒惰让软件更容易编写，让系统更容易组合，让更多人能写出更多好的软件。

Brogrammer 文化：虚假的勤奋

然而，过去二十年软件行业的扩张带来了一种不那么健康的文化。现代抽象带来的巨大生产力催生了一种对「虚假勤奋」的推崇——Cantrill 称之为 brogrammer 文化。在这种文化里，「吊床上的深度思考」被「crushing code」的鸡血叙事取代。人们不再关心抽象是否优雅，而是关心写了多少行代码、提了多少个 PR、一天搞定了几个 feature。

LLM：给 Brogrammer 注射类固醇

LLM 的出现，在这堆干柴上劈了一道闪电。

Cantrill 的原话是：LLM 就像 brogrammer 群体的合成代谢类固醇（anabolic steroids）。无论一个人对软件开发持什么态度，LLM 都能放大这种态度的力量。于是那些本来就痴迷于「产出量」的人，现在更加不可收拾了。

他举了一个例子：Y Combinator 总裁 Garry Tan 在社交媒体上炫耀自己一天写了 37,000 行代码，还说「仍在加速」。

Cantrill 不动声色地补了一句作为对比：整个 DTrace 项目的代码量大约也就六万行左右。

用行数衡量软件的价值，就好比用重量衡量文学作品的质量。这个谬误即便是初学者也看得出来。

Garry Tan 的「作品」被拆解

至于 Tan 用如此疯狂的速度构建的产物——一个「newsletter-blog-thingy」——波兰工程师 Gregorein 对其做了一次拆解。结果既意料之中，又令人捧腹：

单次页面加载就包含了多个测试框架（test harnesses）
混入了 Rails 的 Hello World 应用
藏了一个文本编辑器
同一个 logo 出现了八个不同版本，其中一个的文件大小为 0 字节

Cantrill 指出，问题不在于这些具体的 bug（它们都可以修复），甚至不在于有人认为这种方法论代表了软件工程的未来（虽然这确实很烦人）。

真正的问题是：LLM 天生缺乏「懒惰」这一美德。

核心论点：LLM 不懂懒惰

这是整篇文章最精华的部分。

对 LLM 而言，工作是零成本的。LLM 不会觉得需要为自己（或任何人）的未来时间做优化。它会毫不犹豫地往一个越来越高的垃圾蛋糕上继续堆料。如果不加约束，LLM 只会让系统变得更大，而不是更好——也许能满足某些扭曲的虚荣指标，但代价是所有真正重要的东西。

这恰恰凸显了人类的「懒惰」有多关键：正因为我们的时间有限，才迫使我们去开发精炼的抽象。 我们不愿意把自己宝贵的（人类的！）时间浪费在笨拙抽象带来的后果上。最好的工程总是源于约束，而时间的约束限制了我们愿意承受的系统认知负荷。这才是驱动我们把系统做得更简单的力量，尽管系统本身的复杂性是内在的。

LLM 不受时间约束，也不承受认知负荷，因此不能指望它们主动去追求简洁。

LLM 仍然是重要的工具

Cantrill 并没有否定 LLM 的价值。他明确说：LLM 是软件工程的非凡工具——但归根结底，它只是工具。

正确的使用方式是：

用 LLM 处理程序员「非美德性的懒惰」——比如帮助清理技术债务这类棘手但缺乏动力去做的事
用 LLM 提升工程严谨性
但这一切必须服务于程序员自身的「美德性懒惰」：产出更简洁、更强大的系统，不仅服务于当下的自己，也服务于未来一代又一代的软件工程师

个人感想

读完这篇文章，最大的感触是 Cantrill 精准地指出了 LLM 时代的核心矛盾：工具变强了，但使用工具的判断力并没有跟着变强。

LLM 让「写代码」的边际成本趋近于零，但「思考应该写什么代码」的成本一点都没降低。如果把 LLM 当成代码的自动生成器来追求产出量，最终只会得到一个体积庞大但内在混乱的系统。真正应该做的，是把 LLM 节省下来的时间投入到更深层的思考中去——去琢磨更好的抽象、更简洁的设计。

Larry Wall 几十年前提出的「懒惰是美德」，在 LLM 时代反而变得更加重要了。

参考

Bryan Cantrill, The Peril of Laziness Lost, 2026-04-12
Larry Wall, Programming Perl (The Camel Book)

.claude/ 文件夹解剖

2026-03-23T19:36:59+08:00

大多数团队都在某种程度上采用了 AI，但“使用 AI”与“从 AI 中获得可衡量的 ROI”之间的差距，比人们想象得更大。

Postman 发布了一份成本节省分析，评估了六种常见的 API 开发工作流，并对比了“平台内置 AI”与“外部加挂 AI”在实际时间和成本上的差异。

这是一篇简短、数据驱动的阅读材料，能帮助工程负责人判断：AI 原生工具究竟在哪些环节真正能撬动效率。

你可以在这里免费下载这份指南 →

感谢 Postman 今日赞助！

Claude Code 的用户通常把 .claude 文件夹当成黑盒。知道它存在，也见过它出现在项目根目录里，但几乎没人真正打开看过，更别说理解里面每个文件的作用。

这是个被错过的机会。

.claude 文件夹其实是你在项目里“控制 Claude 行为”的中枢。

它保存了你的指令、自定义命令、权限规则，甚至还有 Claude 跨会话的记忆。理解每个文件的位置和意义之后，你就可以让 Claude Code 完全按你团队的方式运行。

这篇文章会带你完整拆解这个文件夹，从你每天会用到的文件，到你只需设置一次就能忘记的部分。

在开始之前，有一点要先知道：实际上有两个 .claude 目录，而不是一个。

一个在项目里，另一个在你的 home 目录：

项目级的文件夹保存团队配置。你会把它提交到 git，所有人都用同一套规则、同一组自定义命令、同一份权限策略。

全局的 ~/.claude/ 文件夹保存你的个人偏好和本机状态，比如会话历史和自动记忆。

这是整个系统里最关键的文件。你启动 Claude Code 会话时，它第一个读取的就是 CLAUDE.md。它会被直接加载进系统提示词，并贯穿整个对话。

说白了：你写在 CLAUDE.md 里的内容，Claude 就会遵守。

你告诉它“先写测试再写实现”，它就会这么做。你写“禁止用 console.log 做错误处理，要用自定义 logger 模块”，它每次都会遵循。

最常见的做法是在项目根目录放一个 CLAUDE.md。但你也可以在 ~/.claude/CLAUDE.md 放一个全局偏好，甚至在子目录里放局部规则。Claude 会读取它们并自动合并。

多数人不是写得太多，就是写得太少。下面是合理的取舍。

建议写：

构建、测试、Lint 命令（如 npm run test、make build 等）
关键架构决策（比如“我们使用 Turborepo 的 Monorepo”）
不显然的坑（比如“TypeScript 开启 strict，未使用变量会报错”）
导入约定、命名规范、错误处理风格
核心模块的文件与目录结构

不建议写：

应该放在 Linter 或 Formatter 配置里的内容
已有文档、可以直接链接的完整说明
长篇大论的理论解释

把 CLAUDE.md 控制在 200 行以内。文件太长会消耗上下文，Claude 的指令遵循度反而会下降。

原文此处有一个“简短但有效”的示例（截图展示）。

大约 20 行，足以让 Claude 在这个代码库里高效工作，而不需要不断追问。

有时你的偏好只属于你本人，不适合全团队。比如你偏好某种测试框架，或者希望 Claude 打开文件时遵循某个固定模式。

在项目根目录创建 CLAUDE.local.md。Claude 会和主 CLAUDE.md 一起读取，但这个文件会自动被 gitignore，不会进入仓库。

CLAUDE.md 适合单一项目。但一旦团队扩大，你很容易得到一个 300 行、没人维护、人人忽视的 CLAUDE.md。

rules/ 文件夹就是为了解决这个问题。

.claude/rules/ 里的每个 Markdown 文件都会和 CLAUDE.md 一起加载。你可以按主题拆分指令：

每个文件都更聚焦、更容易更新。负责 API 规范的人只改 api-conventions.md，负责测试标准的人改 testing.md，互不干扰。

真正的威力在“路径作用域规则”。在规则文件里加一个 YAML frontmatter，就可以让它只在匹配路径时生效：

比如它不会在编辑 React 组件时加载，而只在处理 src/api/ 或 src/handlers/ 时生效。没有 paths 的规则会在每次会话中无条件加载。

当 CLAUDE.md 开始变得臃肿时，这就是正确的拆分方式。

Claude Code 自带一些内置斜杠命令，比如 /help 和 /compact。commands/ 文件夹允许你自定义命令。

你在 .claude/commands/ 里放一个 Markdown 文件，它就会变成一个斜杠命令。

比如 review.md 会生成 /project:review，fix-issue.md 会生成 /project:fix-issue。文件名就是命令名。

原文这里给了一个简单示例：创建 .claude/commands/review.md。

然后在 Claude Code 里运行 /project:review，它会自动把真实的 git diff 注入到提示词中。反引号里的 ! 语法会运行 shell 命令并把输出嵌入。这就是命令真正有用的原因，而不只是“保存一段文本”。

如果你需要传参，可以用 $ARGUMENTS：

运行 /project:fix-issue 234 会把 issue 234 的内容直接送进提示词。

.claude/commands/ 里的项目命令会提交到仓库，和团队共享。若想在所有项目通用，把命令放到 ~/.claude/commands/，它会显示为 /user:command-name。

一个很实用的个人命令：每日站会助手、按你约定格式生成提交信息、或者快速安全扫描。

你已经了解命令。技能看起来很像，但触发方式完全不同。先看这张图的区别：

技能是 Claude 可以自己调用的工作流，不需要你敲斜杠命令，只要当前任务匹配技能描述，它就会自动触发。命令是你手动触发，技能是它自动判断。

每个技能都在自己的子目录里，包含一个 SKILL.md：

SKILL.md 用 YAML frontmatter 描述“什么时候使用这个技能”。

当你说“帮我审这个 PR 的安全问题”，Claude 会读取描述，判断匹配，于是自动调用这个技能。你也可以显式调用，比如 /security-review。

和命令最大的区别：技能可以打包一堆辅助文件。上面提到的 DETAILED_GUIDE.md 就是和 SKILL.md 同目录的参考资料。命令只是单个文件，而技能是一整个包。

个人技能放在 ~/.claude/skills/ 下，跨项目通用。

当任务复杂到值得一个专门专家时，可以在 .claude/agents/ 定义子代理。每个代理是一个 Markdown 文件，包含它自己的系统提示词、可用工具、以及模型偏好：

下面是一个 code-reviewer.md 的样子。

当 Claude 需要做代码审查时，它会在独立上下文里启动这个代理。代理完成工作后会压缩结论再汇报，这样你的主会话不会被几千 tokens 的中间过程撑爆。

tools 字段限制代理能做什么。安全审计只需要 Read、Grep、Glob，完全不该写文件。这个限制是刻意为之。

model 字段让你选择更便宜、更快的模型来做聚焦任务。Haiku 处理读操作够用，把 Sonnet/Opus 留给真正需要能力的地方。

个人代理放在 ~/.claude/agents/ 下，跨项目可用。

.claude 里的 settings.json 控制 Claude 允许做什么、不允许做什么。它定义了哪些工具可以用、哪些文件能读，以及哪些命令需要先询问。

完整文件长这样（原文此处为截图）。

各部分的含义如下：

$schema 行开启 VS Code 或 Cursor 的自动补全与校验，务必保留。
allow list：允许 Claude 无需确认即可运行的命令。典型选择包括：
- Bash(npm run *) 或 Bash(make *)，让 Claude 能自由执行脚本
- Bash(git *)，用于只读 git 操作
- Read、Write、Edit、Glob、Grep 等文件操作
deny list：无条件禁止的命令。合理的 deny list 会阻止：
- 破坏性命令，比如 rm -rf
- 直接网络命令，比如 curl
- 敏感文件，比如 .env 和 secrets/

不在 allow 或 deny 列表里的命令，Claude 会先询问再执行。这种“中间地带”是有意设计的：既有安全网，又不需要你预判所有命令。

另外你也可以用 settings.local.json 做个人覆盖。创建 .claude/settings.local.json，它会被自动 gitignore，不进入仓库。

你很少手动管理这个文件夹，但最好知道它们存在。

~/.claude/CLAUDE.md 会加载到每个 Claude Code 会话里，跨项目生效。适合放你的个人编码原则、偏好风格等。

~/.claude/projects/ 保存项目的会话记录和自动记忆。Claude Code 会把它学到的命令、模式、架构信息自动存下来并跨会话保留。你可以用 /memory 浏览和编辑。

~/.claude/commands/ 和 ~/.claude/skills/ 保存你的个人命令和技能，跨项目可用。

你通常不需要手动整理这些，但知道它们的存在很有用：当 Claude 看起来“记住”了你没明确说过的东西，或者你想清空某个项目的自动记忆、重新开始时，就知道该去哪。

最后把一切串起来：如果你从零开始，以下步骤非常实用。

Step 1. 在 Claude Code 里运行 /init，它会读取项目并生成一个初始 CLAUDE.md，然后你把它精简到关键点。

Step 2. 添加 .claude/settings.json，设置合适的 allow/deny 规则。至少允许运行命令，禁止读取 .env。

Step 3. 创建一两个最常用的命令，比如代码审查或修复 issue。

Step 4. 当 CLAUDE.md 变拥挤时，把指令拆到 .claude/rules/，并按路径做作用域。

Step 5. 在 ~/.claude/CLAUDE.md 写入个人偏好，比如“先写类型再写实现”“更偏函数式而不是类”。

这对 95% 的项目已经够用了。技能和代理只在你有反复出现的复杂工作流、值得打包时再引入。

.claude 文件夹本质上是一套协议：告诉 Claude 你是谁、项目做什么、它需要遵守哪些规则。定义得越清晰，你纠正 Claude 的时间就越少，它做的有用工作就越多。

CLAUDE.md 是你杠杆最大的文件。先把它写对，其他都是优化。

从小做起，逐步精炼，把它当成项目里的基础设施：一旦搭好，每天都会持续带来收益。

感谢阅读！英文原文：https://blog.dailydoseofds.com/p/anatomy-of-the-claude-folder

阿里云域名解析被转移，让我穿越回了 15 年前

2025-06-06T20:30:00+08:00

2025 年 6 月 6 日早上 6 点 10 分醒来，习惯性瞄了下手机，看到同事给我的留言，大概是说 aliyuncs.com 被别的国家注册了

作为一名曾经的域名管理员，我对域名类的故障是比较 敏（害）感（怕） 的，因此基本上我是短时间就清醒了的，抛出了我的第一个疑问：在用的域名忽然被别人注册了？

同事反馈是过期没续费被抢，但是 域名过期是有保护期 的，所以我并没有接受这个说法，在手机上通过 who.is 查了一下信息，发现过期时间是 2026-04-01，既然都还没有过期，那被别人注册了这个说法自然是不成立的。

继续追问了下目前可能对我们公司业务的影响，了解到如果负载均衡 LB Load Balance 有可能直接用了阿里的域名，这下我就不太淡定了，继续用 itdog 试了一下，发现有个别缓存开始失效了。结合可能对我们的影响，这下真的无法淡定了，立马起床开电脑干活！！

考虑到 whois 也会有缓存，赶紧登录自己在欧洲的一台机器重新查了一下，果然发现阿里 aliyuncs.com 的域名被人更新了（而不是被别人注册了），可以看到更新时间是 2025-06-05T21:32:38Z ，考虑到时区，和阿里通告故障的时间是基本对的上，域名、whois 都会有缓存，有一定时间差是符合常理的。

这个时候肾上腺激素开始飙升了，立马让在线的同事开工干活，主要几个动作：

第一时间把涉 aliyuncs.com 的域名捞出来，并整理成共享文档，供接下来使用；
唤醒公司域名管理员，对于我们自建 DNS 这个服务本身，如果使用了阿里 LB 的且评估是对其他业务提供服务的，马上切走。（如果我们的 DNS Server 受这个 LB 影响不可用了，这个时候爆炸半径会直接无限扩大）
域名管理员，发起紧急变更，将缓存 DNS 服务器上关乎 aliyuncs.com 这个域名的解析全部转发劫持到阿里云的权威，确保内部业务能正常解析，尽可能缩小爆炸半径；
根据服务等级，除了在相关工作群通告外，根据服务重要等级唤醒相应运维（或相应域名对应的管理员），并让他们安排将 aliyuncs.com 的业务先切到 VIP 地址；

中间还是会有一些小插曲，比如可能指引不够详细，有运维同学对于域名没有概念或者有同学所涉业务较多，有点手忙脚乱之外，整体还算快速、稳步的推进，更多的细节就不展开了。

当然，这里最终还是要给阿里云的团队点个赞，原以为这个故障时间会远超预期，然后我们在北京时间 08:14 收到反馈说经过阿里云团队的处理，域名解析开始恢复正常了，故障持续的时间大约为 6 小时左右。再加上故障发生在凌晨，另外域名解析的失效也有一个缓存的过程，不幸中的万幸就是我们基本没有受到影响（但是对不起，炸了一群人起来干活 :p

基本没有，也不是完全没有，但都在可控范围内 :-)

15 年前的鬼故事

在响应这个故障的过程中，就有同事问我是不是我们曾经也出现过这个问题，很肯定的说“是”，但也不是，情况不太一样。在这个时间点，我对于阿里云为什么 NS namesever 被改了还是不清楚的，只是猜测大概率是管理不善，帐号被黑客拿走改了 NS 之类~~ 而我们当年（约 15 年前）碰到的一个情况是被注册商（比如万网、NetworkSolutions）以涉敏感内容为由停止了解析，但阿里云 aliyuncs.com 的症状对不上。

说明一下，涉敏感内容肯定和公司没有直接相关，不展开，避免被有心之人用来作为攻击手段，也不确认该方式是否还有效

当时也是发生在凌晨（时差，美国佬刚好上班之类），年轻睡的晚，本来也想睡觉了，鬼始神差的觉得好像不太对劲，开电脑查了一下发现解析被停掉了，多次用我鳖脚的英文和 NetworkSolutions 对线（感谢那时候有 Skype 等软件可以打国际电话），辗转折腾，在多路大佬的帮助下也是差不多在白天业务高峰前才恢复解析，但毕竟是我们的核心域名，加上时间也是大几个小时，不少地方的缓存失效了，影响还是很大的（最后被某位大佬点赞了 hhhh

说说我的害怕

前面说到作为一名曾经的域名管理名，我对域名类的故障是比较敏（害）感（怕）的，这是为什么呢：

DNS 是互联网最基础的业务之一，但凡在互联网上能提供的业务大概都离不开这个基础。越是基础的东西伤害就越大；
基础的服务受关注程度低，大家都默认你正常，所以确实出问题的概率也极低，因为你不敢经常出问题。但带来的问题是所有上层业务都默认你正常，在设计的时候就不会去做过度容灾，一出问题短时间就是解决不了（但确实有时候为了一个极低概率出问题的系统做过度的容灾，不考虑 ROI 也是有毛病的表现。。。
因为 1 和 2 的情况，业务和业务，经年累月下来，你根本改不了。就像现在，你不可能拿出一套系统取代 TCP/IP、取代 DNS，哪怕 IPv4 要进化到 IPv6，这个我从读大学就被这么画大饼了，20 多年过去了，也没见 IPv6 就把 IPv4 干掉了
（价值论）通常在大多数公司里，基础服务的价值讲不清楚，上层建筑容易画大饼讲故事，也有快速创造收益的可能。像我这种做基础设施的，都要经常停下来反思我这点收入真是得之不易，劳心劳命的，然后给自己找到自洽的逻辑，继续努力~
域名的爆炸半径不可控，一方面是因为我们不可能去刷新世界上所有的缓存（运营商大多数情况下也不会鸟你），同时我们也没有办法让用户在出现故障时，让他们切换到另一个域名（如 HttpDNS 等方案这些都只能解决特定场景下的特定问题），另外 缓存是个双刃剑，它能延缓故障的爆炸，却也会让你在宣告解析恢复后要经受不停的挑战，为什么我的服务一直没有恢复？就像这次我们 直到北京时间 13:57 才收到业务反馈说运营商的缓存基本都过期不再报错了，大概是阿里云宣告恢复后的又一个 6 小时

当然，你也可以认为我过度紧张 :-)

小结

阿里云此次 aliyuncs.com 的故障真实原因是什么？这个我也不知道，但从网络上的蛛丝马迹上看是被 VeriSign（不是注册商，是 .com 顶级域的管理）改了域名解析，不考虑更深层次更腹黑的原因，只能猜测是因为阿里云有不合规的内容被投诉了之类。如下一些公众号的猜想：

作为域名的拥有者，有没有可能完全杜绝这个问题？我认为不可能，这次看起来是 VeriSign 操刀的，也就是直接绕开注册局（商）了。包括有些朋友可能会认为加一些注册局锁（类似 serverUpdateProhibited 这些）可能可以缓解，我可以很肯定的说这 只能解决到注册局层面的问题，覆盖不了本次的情况 。当然阿里云做为一家国际云商， 注册局锁这点钱你们就不要省啦 （事后也看到阿里云加上了）：

技术上能不能解决：能，但成本不知几何。鼓励大家在业务上线的时候通过多入口容灾、引入 HttpDNS 等技术解决类似问题，但是当类似问题出现时，影响还是不可避免，手忙脚乱也还是不可避免，毕竟 N 年等一回，但最好一回也不要有，害怕
可能有其他非技术非常规手段，可以从根服务器、顶级域名运营商开始实施保护，但想像不了了，请了解规则的朋友指点哈

Obsidian 接入 DeepSeek API 指南：Text Generator 插件配置教程

2025-05-12T15:07:00+08:00

以下是 Obsidian 接入 DeepSeek API 的配置教程，使用 Text Generator 插件实现智能文本生成功能。教程使用 Text Generator 插件 + DeepSeek API 生成，并经过人工校对：

1. 安装 Text Generator 插件

打开 Obsidian → 点击左侧边栏 Settings (设置)或菜单栏 Preferences
进入 Community plugins (社区插件) → 点击 Browse
搜索 Text Generator → 安装并启用插件。

2. 获取 DeepSeek API Key

访问 DeepSeek 官网注册/登录账号；
进入 API 管理页面（如无公开API，需联系官方申请权限）；
复制生成的 API Key（保存到安全位置，后面无法通过 deepseek 平台查看）；
充值（很重要，否则后面会出错）

3. 配置 Text Generator 插件

在 Obsidian 中打开 Settings → 找到 Text Generator 插件设置。
在 API Provider 中选择 Custom 或 通过+创建自定义配置（若支持）。

注：如上截图，已勾选的 deepseek 是通过后面的 + 创建出来的。
填写以下参数：
API URL: DeepSeek API 的端点地址（如 https://api.deepseek.com/chat/completions）
API Key: 粘贴你的 DeepSeek API Key
Model Name: 填写模型名称（如 deepseek-chat，根据官方文档调整）

4. 测试 API 连接

在 Obsidian 中新建一个笔记，输入内容并选中；
按快捷键 Ctrl/Cmd + J 即可自动生成；
观察是否返回 DeepSeek 生成的文本，若无响应请检查：
API Key 和 URL 是否正确
网络是否畅通
DeepSeek 账户是否有足够配额

5. 高级设置（可选）

自定义提示模板：在插件设置中修改 Prompt Template，适配你的工作流。
调整参数：如 temperature（随机性）、max_tokens（生成长度）等。

常见问题

Q: 插件报错 n.text is not a function？
A: 在插件的 Advance mode 里把 CORS Bypass 打开
Q: 提示 404 或者 Not Found 之类 A: 确认 API 地址（Endpoint）填写正确，如这里是：https://api.deepseek.com/chat/completions
Q: 提示 402 或者 Failed to load resource 之类 A: 先充值！
Q: 如何查看其他报错的详细信息 A: MacOS，使用：Cmd+Option+I 打开控制台查看

通过以上步骤，你可以在 Obsidian 中无缝调用 DeepSeek 的 AI 能力。如果需要更详细的配置（如本地代理），可参考插件官方文档或 DeepSeek API 说明。

25非全考研，人生经历+1

2025-04-13T06:30:00+08:00

23年去华工和D老师/泰老师吃饭闲逛的时候，脑子一抽想到要不干脆我也来考个研算了，但因为离国家统考的时间确实太近了，花80块钱报了名，完全没有时间准备，最后也是不了了之。但念头有了之后，却是挥之不去了，24年春节后，就默默开始准备起来了，25年4月把复试的流程走完，也进入了“拟录取”状态，小记一下人生的的经历。

为什么想考研

考研再读书的想法来的快，却挥之不急，首先还是和个人性格有比较大的关系，当我想到要去做一件事情的时候，总是会想着各种办法去实现，小到种草一件商品，大到买车买房等，只要我确定了我就会很快的想办法去实现。这个性格其实在生活、工作中给我带来了不少的好处的，坚持、靠谱、敢于接受挑战的各种评价大抵来源于此，但实际上却也经常让我个人陷入一些困境的，所谓的”内耗“。但无论如文，考个研读个书的想法真是”野火烧不尽，春风吹又生“，那就实现他吧，黄沙百战穿金甲，不破楼兰终不还。除了性格的原因，想考研读书也是受到方方面面的影响：

1、受益公司的战略调整，这几年开始有机会招聘海外的一些员工，在面试过程中就发现很有意思且很频繁的一个现象，海外同学（这里指坡县）经常会在工作一段时间后又回到学校，再出来工作，如此反复的这么一个过程。让我从“惊讶”进入到了”羡慕“，毕竟在国内要是我们的工作简历上频繁的出现”GAP“，那大抵是不受待见的。甚至于除了”铁饭碗“类的岗位，在大多数行业（比如互联网），虽然大家鼓励学习、知识的沉淀，但对于学历的追求，可能也会得到一个”有什么用呢“的反问？和海外这些员工的接触给我种了草，其他人的想法并不重要，这是让我觉得会有趣的一个经历，那就去试试吧！（谢谢我的热爱学习的同事们） 2、我不知道公司或者整个社会有什么问题，但知道我所在公司的朋友，也应该会关注到我所在的公司这两年也是各种”风起云涌“，口罩后的大家过的都不容易，对于我自己的岗位，从23年开始直到现在，我也一直是抱着背水一战，破釜沉舟的心态，可是当真的走到这一步的时候，我能做些什么，我真的没有想好。小学中学大学十六载，工作近十八载，如果有这么一个窗口，那么我想停一下看一看，也好好想一想接下来的路怎么走（毕竟40岁的互联网人那可太不被待见了啊，哈哈哈），但却并不想让自己无所事事，因此给自己一个重新学习的机会也成了自己一个很好的可选项，给自己一个暂停键，还可以充充电（算不算在逃避呢？嘿嘿）

想到了就去做，而且这次我还算是做了一个和自己性格相逆的”玩法“，早早我就告诉朋友、同事我要去考个研（以前这种人生大事怎么可以告诉大家，都是默默搞定他，免得丢人，哈哈哈），人生海海，何妨让世界听见我的号角？

备考

要说花了很多的时间备考，好像也没有，毕竟日常确实太忙了，基本都是利用周末的时间以 1.5x 甚至 2.0 的倍速刷一下视频，让自己有点印象，其实最担心的无法就是到了考场一个字都蹦不出来。非全日制工商管理类（我报了工程管理）国家统考其实就考两科《管理类综合能力》和《英语（二）》，对于我个人来说，英语其实没啥好准备的（口语不行，但阅读理解却是我的强项），主要时间还是用于学习管综了，买了中公教育的历年真题，这套真题有个好处是看不懂的题目可以刷二维码有视频学习，这对于已经离开学校18年，各种知识已经还给老师的中年人实在是太友好了！当然，这些课程的学习纯粹是为了“应试”，但好在也不是一无事处，有两点收获还是值得回味一下的：

1、算是把初中的一些数学知识重新学习了一下，涉及到基础的几何知识、平面直角坐标系、概率等等的一些知识，家里刚好有一个初中娃，被他问起来的时候显得我没有那么落伍，被我装到了； 2、学到了一个应试技巧，考试时先把”论说文“和”论述文“两篇文章写了，两篇文章只要完成度高，前面的数学题、逻辑题蒙个一半，那基本上也大差不差了。英语在考前找了几个公众号看了下英语写作的模板算是最大的准备了。逻辑题我个人就会认为纯粹就是为了考试而考试设计的各种绕口令了，总之绕晕你就对了（实际我也没有做完，至少有10道选择题就是蒙猜了），当然正能量一点，我找 DeepSeek 讨论了一下对于“逻辑题”的看法，它给出了正面反馈：

考试

考试的仪式感还是很强的，除了文具其他随着携带的东西都是在考场区域外保管的，进考场区域和考室也是面临层层安检。更有趣的是，当天也算是一边考试一边加班了，进考场区域的前 5 钟还在打电话安排和汇报工作。中午和下午考完出来的 5~10 分钟内都有电话和 IM 信息过来的灵魂拷问：“怎么我回信息这么慢的？”（真是紧张又不失有趣啊，肾上腺激素彪升，懂的都懂，哈哈哈，真心感谢当天紧急提供协助的同学们）所幸，流程算是走完了，这个考试状态感觉要凉，哈哈哈，但好在自己并不焦虑，好像有点祛魅了，原来就是这么一回事！

复试

成绩出来后其实并不理想，管综考的比较烂，英语算是拉了我一把，工程管理国家线 162，吹牛的说法是咱超了国家线近 30 分，其实一点都不理想，我所报考的学校计划招生 40 人，我排名 61，是否能进面试其实是比较悬的，最后算是有惊无险，进了复试。复试至少准备上是比初试统考用心了的，在复试通知出来的时候才发现竟然要考一门专业课，足足用了两周下班后的晚上和一个完整的周末在B站刷视频课程学习，专业课和面试的过程就不具体展开了，毕竟用官方的说法这应该属于泄密。但是回到学校复试的感受还是不一样的，走在学校的小路上，看着来往的学子和有着年头的建筑，想重新回到学校的念头还是非常强烈的。所以在对话的一开始还是略微紧张的，但也算是很快调整过来了的，复试的成绩还不错，最后总成绩把自己从 61 拉到前 30 了。因为官方的通告都是 PDF 的，让 DeepSeek 帮忙分析了下：

知识若有趣，前路自有光

至此，非全研究生的考试算是把整个流程走完了，虽然感觉对整个过程是祛魅了，但大抵自己还是会考虑这项“投资”把后面三年的学习流程走完的。印象有点深刻的是最近和同学朋友聚餐时，提到我要去读书，结合我所在的行业（学历已经没什么帮助了）、年龄（中年大叔）、学费（一年5个）、学习方式（非全日制，低人一等？），从部份朋友的眼神里看到了惊讶和不解。但我在复试专业课的准备过程中却看到了知识的趣味性、系统性、延续性，很多工作中看到的现象碰到的问题，原来可以大量使用课程里的原理、逻辑、方法加以解释（如果回到大学，我的想法一定会是这些大道理有什么意义啊？），既然这么有趣（又有挑战，听说这个学校即使非全的按期毕业率低于30%），那就让游戏继续下去吧，这应该是人生最后一次进校园的机会了？

中午逆旅，莫听穿林打叶声，何妨吟啸且徐行。

2025.04.13 06:30

你想要建造自己的数据中心吗？

2025-01-20T13:07:00+08:00

原文来自：https://blog.railway.com/p/data-center-build-part-one 很少看到有从 IDC 基础设施开始写的文章，一时兴起借 AI 工具作了粗浅的翻译。

从一开始，Railway的计算能力就是建立在谷歌云平台之上的。该平台支持了Railway的初步发展，但它也引发了许多问题，这些问题给我们的业务带来了生存风险。更重要的是，构建在超大规模云服务提供商上，阻碍了我们为客户提供最佳平台的可能性。

它直接影响了我们能够提供的定价（有人知道公有云流出流量费用吗？），限制了我们能够提供的服务级别，还引入了工程限制，这些限制了我们能够构建的能力。

我们不仅很少能理解上游环节出问题的原因，而且尽管我们每年花费数百万美元，但能得到的支持也只相当于你花费100美元所得到的。

因此，我们去年启动了一个 Railway Metal 项目。九个月后，我们在加利福尼亚的第一个站点上线，设计、规划并落地了从机柜中的光纤电缆到与互联网服务提供商的各种合同的一切。就在我们发布这篇博客的时候，我们正在启动另外三个区域的数据中心。

为了向我们的客户提供“透明基础设施”的云体验。我们需要迅速且足够好的构建我们自己的物理基础设施。这就是我们今天博客文章的主题。

所以你想要搭建自己的“云”

从 2024 年 1 月启动 Railway Metal 项目开始，我们花了整整五个月时间才将第一批服务器接入。之后，又用了额外的三个月，我们才觉得可以让用户放心地使用这些硬件（并且又过了几个月，我们才开始在这里撰写相关的内容）。

第一步是找到合适的地方。

本地部署时，你需要有地方来放置你那些崭新的服务器以及可靠的电力来保持它们运行。另外，你还需要足够的冷却措施，防止它们“熔化”（保障服务器正常运行）。

一般来说，你有三种主要的选择：绿地建设（购买或租赁数据中心）、机笼托管（在供应商的数据中心内获取一个由网格墙围起来的私人空间）、或者机架托管（租赁托管数据中心中的单个机架或机架的分区）。

这句话的意思是：“我们选择了第二种选择：一个笼子，它能给我们四面墙、一扇安全的门，以及一个空白的画布，让我们可以自由地设计其他一切。

租用或购买足够的空间来放置设备等并不是主要的成本支出，电力（以及由此带来的冷却需求）却是成本最高的部分。根据地理位置的不同，每千瓦时（$/kW）的电力价格可能会有很大的差异。--举个例子，在美国西海岸，我们支付的电力费用可能不到在新加坡支付的一半。电费是按照固定的月度承诺来支付的，无论是否实际消耗，都要支付这笔费用，以确保电力可以随时按需使用。

但是你需要多少电力呢？

能力越大，责任越大

理想情况下，如果你已经开始了数据中心迁移的任务，你应该对想要部署的计算资源数量有一个大致的概念。我们开始时设定了虚拟CPU（vCPU）的数量、内存容量（GBs）以及NVMe（一种高速存储设备）容量（TBs）作为目标，以匹配我们在谷歌云平台（GCP）的容量。

经过一系列指标、数据的分析、比较等过程，我们最终确定了合适的服务器和CPU。计算过程有很多因素、参数等可供选择、调整--甚至于都值得另外写一篇文章了--但对我们来说，最重要的因素是功耗密度。例如，我们如何在特定的功耗范围内获得我们想要的计算密度。

功率计算并不像简单地把瓦数加起来那么直接，尤其是涉及到三相电的情况。Cloudflare有一篇很棒的博客文章详细阐述了这个主题。

电力是数据中心最为关键的资源，一旦电力中断，可能需要数小时甚至数天才能完全恢复正常的运营状态。所以冗余是非常关键的，对每个机柜来说，两路独立的电力接入至关重要。在正常运行时，这两个独立的电源线路会共同分担机架设备的负载，共同为设备提供电力。这样可以保证电力供应的稳定性和效率。然而，更重要的是，这种设计必须能够抵御其中一个电源线路发生故障的情况。即使其中一个电源线路出现故障，另一个电源线路也能够立即接管全部负载，确保机架设备的持续运行，而不会因为电源故障而导致设备断电。

为了将这种电力传输到你的服务器上，你还需要一个电源分配单元（PDU），你需要根据它提供的插座数量和管理功能来选择它。基本款的 PDUI 就像是升级版的延长线，而我们部署的 PDU 则能够实现对每个插座的控制和计量。

凭借前面提及的相关能力，现在机柜里面可以正常供电了。

上帝说要有光

没有一台云机器是孤立存在的，这就是网络发挥作用的地方。

为了在Railway上实现尽可能低的延迟，我们需要为你建立到世界各地的稳定连接。

我们寻找的数据中心要具备与顶级（T1）互联网服务提供商（ISPs）处于同一网络、属于互联网交换点（IX）的一部分以及有可用光纤连接到附近其他数据中心等特性。

部署到Railway的应用程序会想要通过网络连接到各种各样的端点，无论是位于澳大利亚悉尼的家庭互联网用户，还是托管在美国AWS服务器上的API。为了给您提供尽可能低的延迟和最低的带宽成本，我们会与针对每种使用场景优化的多种互联网提供商签订合同

我们在选择互联网服务提供商（ISPs）时，会考虑它们在我们目标地区的网络成熟度。如果在一个地区选择了不合适的ISP，可能会导致到达特定目标的网络路径出现额外的网络跳数（从而产生延迟），或者在最糟糕的情况下，出现复杂的网络路由。因此，为了确保网络服务的质量和可靠性，我们会根据它们在各个地区的网络覆盖范围来选择至少两个不同的网络。

一旦连接建立，我们会从每个互联网服务提供商（ISP）那里接收完整的互联网路由表并将这些路由表整合到我们的网络交换机上以便为每个IP前缀解析出最佳路径。如果你有一个位于澳大利亚的终端用户试图连接部署在新加坡的应用程序，我们很可能会直接将这些数据包转交给Telstra。Telstra拥有澳大利亚最密集的接入网络之一。如果同一个应用程序需要将数据包发送到日本的终端用户或服务器，那么我们很可能会将这些数据包转交给PCCWPCCW直接与日本的NTT（日本电信电话公司）进行对等互联，并且在亚太地区（APAC，Asia-Pacific）拥有广泛的网络覆盖。

👉 网络之间对等互联的信息是公开可获取的，可以访问bgp.tools这个网站来观察你感兴趣的网络之间是如何实现相互连接的。

为了实现冗余，我们正在每个区域构建多个可用区，并且这些站点之间的互联互通对我们扩展计划至关重要。我们正在寻找裸纤（dark fiber）或波分复用技术（wavelength services）这样的工具来规划这种扩展。其结果是，你的应用程序不会察觉数据库是位于同一个房间，还是在相邻建筑中相隔四个街区的位置——这是一个优势，而不是缺陷——因为它增强了系统对单个数据中心故障的韧性。

...

好的，现在你已经找到了一个你满意的场地，和一个数据中心签订了协议，还和几家互联网服务提供商签了约，你就可以着手安装服务器了，对吧？

嗯，不是完全这样。首先你需要很多其他的东西来给你的服务器一个舒适温暖的家来安顿下来。

通道，机架和头顶的基础设施

在数据中心里，机架是按行排列的，机架之间的空间，也就是通道，被用于空气流通。

冷通道是从数据中心设施吹入冷空气的地方，而机架中的服务器会吸入这些冷空气，并将其从后部排出到热通道。数据中心设施会从热通道中移除这些热空气。为了达到最佳效率，不希望冷通道和热通道之间的空气混合。

即使您选择使用传统的19英寸宽设备，机架本身也存在一定的可变性。您可以根据设备和布线需求选择机架的高度、宽度和深度。

大多数服务器设备都可以通过滑轨进行滑动，以便于维护，因此要确保机笼尺寸允许设备进行滑动。布线和线缆管理也需要一定的空间，所以要在每个机架的拥挤程度与机笼内可容纳的机架数量之间做出权衡。

在我们的经验中，电力和制冷常常是限制因素，而不是实际可用的空间。在新场地，我们倾向于选择宽度为800毫米的机架，以便通过将电缆移出排气口的路径来实现更好的空气流通。

除了机架之外，你还需要一些基础设施来将电力和数据传输到你的机架。这可能涉及安装一些顶部基础设施和托盘，这些托盘让你能够将光纤电缆从你的机笼边缘路由到每个机架，并在机架之间路由电缆。当报价时，数据中心运营商通常会包含这些内容。

根据你的设计，你可能需要通过确保架空基础设施、机架内布线以及设备朝向的一致性，来优化电缆路径，使其尽可能短。由于我们的机架中每个都包含密集的交换机到服务器的光纤布线，因此我们采购的交换机是端口朝向机架后部的（这些被称为反向气流交换机，因为它们的散热口位于网络端口所在的侧面）。

这使我们能够对齐电缆托架，从而让所有的布线都发生在机架的一侧，并且没有电缆在机架的前部和后部之间来回曲折。

你已经拥有了所需的空间，签约了互联网服务提供商（ISPs），订购了硬件，准备好了机架，并且对如何布置这一切有了一个相当不错的概念。但目前，这一切还只是像一套昂贵的乐高积木一样，静静地待在数据中心的装卸区。要将它们组装起来，你现在需要利用人类历史上最通用的编程工具——Microsoft Excel。

上架和堆叠

让我们先退一步，先发表一个免责声明：整齐有序的布线需要大量的实践；我们自己也尝试过，结果……喜忧参半。

为了正确安装它们，我们引入了专业人士，但专业人士需要知道要安装什么。一份全面的文档包是必不可少的。电缆矩阵和机架布局图是常见的文件，它们向承包商传达如何安装和连接服务器。

电缆矩阵（Cabling Matrix）描述了每根电缆的端接情况，指明了连接的每一端所对应的设备位置和端口号，同时还包括电缆本身的规格信息（例如光纤类型、长度等）。机架视图（Rack Elevation）是机架本身的视觉呈现，展示了每个设备的位置和朝向。

文档工作非常繁琐，每个安装阶段都涉及60多台设备、300多根独立电缆以及许多细微之处。这些内容都被精心整理成书面规范和电子表格，作为安装和调试的基础。从物料到场到完成安装，整个过程大约需要6到14天。

数据中心的建设与软件、DevOps以及人们通常所认为的“基础设施”相去甚远。确切的说，更类似于建造房屋，而不是 Terraform 部署。

更复杂的是，每一个数据中心设施、承包商和供应商在做事方式上都会存在细微的差别，即使在同一个组织内也是如此。因此这些事情会要求你始终保持警觉，并且极度注重细节。

迄今为止我们经历过的一些困域时刻：

承包商说需要更长的电源线。原因是该站点的电源分配单元（PDU）是倒置的，因为电源是从地板接入的，这导致了插座编号在规划中被反向标记了。
来自阿姆斯特丹的电话说：“这个站点没有分界点吗？” 一个特定的设施直接将外部光纤链路安装到我们机架中的一个盒子上，而不是通过一个专用的交接点。
Railway Discord：“为什么这个PDU的相位接线这么奇怪？” 该设施的接线方式与其他站点不同，电源插座是相线对中性线接线，而不是相线对相线接线（对于电气工程师来说，这是WYE和Delta电路的区别）。
承包商说：“你的数据线太短了。” 承包商没有意识到网络设备是逆向气流的，试图以错误的方向安装设备。
我们提交了一个支持工单：“这条电缆没有建立连接。” 光纤的极性接反了；那天我们学会了什么是“翻转光纤电缆”……这是指他们从LC连接器中拔出插头并交换它们的位置。
Railway Discord：“我今天从家得宝买了一个橡胶锤。” 一个供应商的近24个PDU批次被交付时带有有故障的插座，即使施加适当的极端机械力，这些插座也无法与电源插头正确接合。

但从这一点开始——硬件已经就位，任务开始变得熟悉起来；我们现在需要进行一些BGP（边界网关协议，是一种用于互联网自治系统之间的路由协议）操作，安装一些操作系统，配置监控并让一切工作起来。

把油门踩到底

安装好的机架就像是一块空白的画布，网络设备需要进行配置，路由器的配置文件需要编写，区域互联网注册机构（RIR）的记录需要更新，我们还需要与类似 Redfish API（用于服务器主板和电源分配单元的专用控制器的 HTTP 接口）和 PXE（一种通过网络启动服务器的协议）进行交互，以确保一切正常运行。

我们也还没有讨论网络是如何工作的。我们的设计使用了FRR（Free Range Routing）和运行SONiC（Software for Open Networking in the Cloud）操作系统的白盒网络交换机，构建了一个仅基于第三层（L3）的软件驱动网络，该网络与我们的控制平面深度集成。

我们已经给你讲了很多来自一线的故事……要是再讲下去，你今天就别想走了。

在未来的文章中，我们将讨论如何将一个房间里的一堆服务器转变为一个功能性的 Railway 区域。在过去的几个月里，我们开发了两个新的软件工具：Railyard 和 MetalCP，以实现从设计新的机架、追踪和可视化布线，到在服务器上安装操作系统并将其接入互联网的“一键式”体验。

直到那时，如果这些内容中有任何让你感到兴奋的，可以查看我们目前开放的基础设施工程职位，如果这些职位引起了你的兴趣，就联系我们。

美区 Apple ID 充值攻略

2023-10-16T20:10:00+08:00

注：原文来自 https://zhuanlan.zhihu.com/p/552311280 ，亲测有效，因此转载一份，防止消失 :-)

一、购买美区苹果礼品卡

在国内购买美国 Apple gift cards的途径主要有以下三种：

淘宝购买美区礼品卡，买回来直接充值，但风险比较高，因为有些淘宝的礼品卡是黑卡，使用黑卡充值可能有 ID 丢失风险。没有信得过的店铺就不要尝试这个方法。
如果你有美国的朋友，可以让他代买礼品卡，然后充值。
到苹果美国官网自己买礼品卡送给自己，也是本文要说的方法。

准备工作

双币种信用卡，单币银联信用卡，中国发行的visa或者master
准备两个邮箱（通过邮箱发送礼品卡，Gmail可以）

购买流程

首先打开美国礼品卡购买地址：https://www.apple.com/shop/buy-giftcard/giftcard 然后选择“Email”电子礼品卡，封面随便选一个（不重要），然后填写购买金额，有$25，$50，$100的选项，官网买的话最小金额是$10。

接着填写收发人的信息及邮箱，邮箱千万不要弄错，否则无法接收礼品卡，填好后点击右上角“Add to Bag”按钮。

点完“Add to Bag”按钮后会跳转到另一个界面，这里检测下自己填写的邮箱有没有错，确认无误后点击“Check Out”按钮。

这里直接选择“Continue as Guest”按钮
接下来这里填写你的信用卡信息，包括姓名，卡号，账单地址等等，填写好信息后点击“Continue to Review”按钮。

填完上面信息后会让你再次确认邮箱等信息，确认无误后直接点击“Place Your Order”按钮就行，官网上写的是一个小时会收到邮件，正常不需要那么久，一般会在10分钟左右收到礼品卡邮件。

PS：最后填写你的 VISA 信用卡信息，和地址信息时候，如果你选择的是中国，购买失败了，可以重新下单选 United States看看，你可以搜索在线美国地址生成器，或者打开 Google Map，找到一个你喜欢的美国的详细地址，然后 Google Map 会告诉你它所在的州，街道，电话信息等。（账单地址建议选择没有消费税的五个州，因为不确定购买虚拟产品会不会账单地址不同而多交税。）

二、使用礼品卡充值

收到礼品卡后，会在邮箱中看到兑换码，复制兑换码，到app store里去充值。

充值前，先确认自己的 App Store 登录的是将要充值的 Apple ID，也就是美区 Apple ID。
把设置中国家和地区选项，改为美国，如果是 iPhone，路径是：设置 -> 通用 -> 语言和地区 -> 地区 -> United States。
打开邮件，点击进行充值。

或者你也可以打开 App Store，找到礼品卡充值入口，然后输入礼品卡的卡号(卡号在邮件里)，进行充值。具体步骤这里不再展开了，跟着手机的指引来就好了

Q&A

购买gift card并且到账之后，是否还需要绑定双币信用卡或者美国PayPal？

答：不需要，gift card和绑定双币信用卡或者美国PayPal时平行的，也就是说这三者只要满足一项，就可以进行付费APP的购买。

可以给美国区的Apple ID帮定国内的visa、master card、america express吗？

答：不可以，美国区的Apple ID只能绑定由美国发行的信用卡，有些小伙伴可能认为只要能消费美元的信用卡就可以，其实就算你绑定美国区Apple ID之后，苹果也能够识别你是大陆的信用卡，然后你的美国区账号就会被强制转成国区的Apple ID了，这就得不偿失了，所以建议不要尝试，如果不信邪，那可以试试，最后你可能需要重新注册一个美区Apple ID。

中国区Apple ID充值

中国区的Apple Store支持的充值方式有支付宝充值、微信支付、银联/信用卡/借记卡、快捷支付等四种方式，如果你在海外，确保你的支付宝或者微信账户有钱就可以充值了。

可能是全网最全的 ulimit 配置说明了

2022-06-14T13:07:00+08:00

ulimit 设置不当经常会引起各种各样的问题，比如很经典的 too many open files，网上也有很多文章讲解 ulimit 设置，如 initscrip 设置、PAM、systemd 的配置等等。

由于 systemd 已经成为主流，本文以 Debian 11 bullseye 为环境理清正确的 ulimit 设置应该覆盖哪些配置。通常情况下这些配置在绝大多数 Linux 发行版会是通用的，并不局限于 Debian。

systemd

systemd 主要涉及 /etc/systemd/system.conf 和 /etc/systemd/user.conf 两个文件，需要配置的内容是以样的，以 ulimit 中 open files 和 max user processes 为例，我们需要配置如下两项：

[Manager]
DefaultLimitNOFILE=1048567
DefaultLimitNPROC=65535

配置生效需要重启。但是这两个配置文件有什么区别呢？通过 man systemd-system.conf 了解到当以系统实例运行时，引用的是 system.conf ，当以用户实例运行时，引用的是 user.conf。不过系统环境中运行的都是系统实例，如果有兴趣的朋友可以通过 systemctl edit/enable/start --user 等操作自己注册个 user 实例看看。可以通过 cat /proc/${pid}/limits 进行确认。

结论：为了确保 ulimit 在 system 环境中生效，建议同时修改/etc/systemd/system.conf 和 /etc/systemd/user.conf 两个文件中的相关配置，并确保配置一致。

PAM limits

很多伙伴会发现，即使完全配置了 system 相关的文件并重启生效后，通过 ssh 远程登录服务器，ulimit -n 一看，还是 1024，这可是个忧伤的故事，怎么破呢？

请检查 /etc/ssh/sshd_config 配置文件，看看是否有这一行：

UsePAM yes

如果有，请将 yes 改成 no 之后重启 sshd 服务，再次登录后，你应该能发现 systemd ulimit 相关配置已经生效了。

但系统中 PAM 可是在相当多的地方用到了，所以这里我们需要再次修改 pam limit 相关配置，以确保系统中 ulimit 相关的配置一致。需要修改的文件为：/etc/security/limits.conf，请在文件里增加如下内容：

*   soft    nofile  1048567
*   hard    nofile  1048567
*   soft    nproc   65535
*   hard    nproc   65535

修改上述文件后，需要再确认一下以下文件（可能还有更多，但以下这些文件建议确认）：

/etc/pam.d/su
/etc/pam.d/sshd
/etc/pam.d/login
/etc/pam.d/cron

包含以下这行内容：

session required pam_limits.so

请注意，前方高能：细心的小伙伴可能会发现这时通过 su - 切换成 root 后，再看 ulimit，又是没有生效的，怎么回事呢？ man limits.conf 可以找到答案：

NOTE: group and wildcard limits are not applied to the root user. To set a limit for the root user, this field must contain the literal username root.

上述 /etc/security/limits.conf 配置中的通配符 "*" 对 root 用户不生效，我们需要继续在 /etc/security/limits.conf 中增加如下配置：

root    soft    nofile  1048567
root    hard    nofile  1048567
root    soft    nproc   65535
root    hard    nproc   65535

保存后，应该安逸了~

结论：pam 的 limit 设置也会影响 ulimit 相关设置，需要通过配置确保和 systemd 相关内容一致。坑点：通配符 "*" 对 root 用户不生效。

结论

system 的 ulimit 相关设置需要同时调整 /etc/systemd/system.conf 和 /etc/systemd/user.conf；
除了 system 的配置，pam 相关的配置也需要同步调整，主要涉及 /etc/security/limits.conf 和 /etc/pam.d/ 目录下的相关文件；
/etc/security/limits.conf 中的通配符 "*" 对 root 用户不生效，root 用户相关配置需要显式指定；
除了系统级别的配置，用户也可以在 /etc/profile 和 bashrc 等相关配置里显式的修改 ulimit，当你发现上述 3 项配置都没有生效的时候，请检查用户侧的设定，看看是否自己另外指定了；

MongoDB 4.2 流控 FlowControl 机制走读

2022-06-11T22:21:00+08:00

MongoDB 4.2 引入了一个「流量控制」的新特性。该流控机制旨在保持副本集多数提交延迟小于或等于配置的最大值。此最大延迟的默认值为 10 秒。一旦多数提交的复制延迟达到配置的最大值的阈值百分比，流控制机制就会开始限制主节点上的写入。

当该特性开启时，MongoDB 会在给定的周期内（目前实现是 1 秒），分配一定数量的「流控票据」，MongoDB 的数据库库写操作需要通过获取「流控票据」来获取全局 IX 锁。当此给定周期内的票据分发完比后，相关操作需要等待下一个周期（下一秒）的票据刷新分发。部份 MongoDB 内部操作可能会忽略该流控机制，以确保 MongoDB 的正常运行。

接下来我们从算法、配置、源码等几个方面结合来了解一下该流控制机制的实现（本文以 MongoDB 4.2.20 版本的文档及源码为参考）。

环境要求

因为是 4.2 才引入的，所以要求 MongoDB 版本大于等于 4.2.0，并且 featureCompatibility 也要匹配相应的版本；
流控机制只在可以接受写入的节点生效（通过指 replica sets 中的 primary 节点）；
当然，流控开关也是要打开的，默认打开。可以通过 enableFlowControl 进行开关；
Read Concern Majority 必须启用，可以参考 replication.enableMajorityReadConcern 启用；

当以上机制不满足时（亦可理解为流控机制关闭时），MongoDB 总是返回默认的最大数量 _kMaxTickets = 1000 * 1000 * 1000。

流控机制

流控制机制允许每秒获取指定数量的全局 IX 锁。除明确规避流控机制的操作外，全局 IX 锁获取必须首先获取「流控票据」然后才能获取锁。当此给定周期内的票据分发完比后，相关操作需要等待下一个周期（下一秒）的票据刷新分发。MongoDB 通过一个独立的机制每秒刷新一次票数。

// src/mongo/db/storage/flow_control.cpp

FlowControl::FlowControl(ServiceContext* service, repl::ReplicationCoordinator* replCoord)
    ...

    _jobAnchor = service->getPeriodicRunner()->makeJob(
        {"FlowControlRefresher",
         [this](Client* client) {
             FlowControlTicketholder::get(client->getServiceContext())->refreshTo(getNumTickets());
         },
         Seconds(1)});
    _jobAnchor.start();
}

每次/秒刷新 tickets 数量时，getNumTickets 将计算应该允许多少票据以解决 MongoDB 多数提交的滞后问题（复制延迟）。流控机制根据以下因素确定每个周期要补充多少票：

当前多数提交的复制延迟大于配置的目标最大复制延迟；
Secondary 在上一周期应用了多少次操作；
在上一周期中平均每次操作需要获取多少个 IX 锁；

触发流控时 ticket 数量计算

触发流控的 ticket 数量可以通过如下公式理解：

base * k ^ ((lag - threshold)/threshold) * fudge factor

采样方式

采样的频率和数量主要通过如下两个配置参数进行控制：

flowControlSamplePeriod 这个参数的命名比较容易让人困惑，会容易误认为是时间，实际理解是每 N 次采样一次，N 即为 flowControlSamplePeriod 设置的值，值越小的精度越高，所以可能更容易触发流控导致业务降级；

// src/mongo/db/storage/flow_control.cpp

void FlowControl::sample(Timestamp timestamp, std::uint64_t opsApplied) {
    ...
    if (_numOpsSinceStartup - _lastSample <
        static_cast<std::size_t>(gFlowControlSamplePeriod.load())) {
        // Naively sample once every 1000 or so operations.
        return;
    }

flowControlMaxSamples，内存中保存的样本数，默认值为 1000000，每个样本数约为 24 bytes大小，保存 100000 样本数约需 24MB 内存；

采样在 oplog 相关的操作中进行，参考上述 sample 采样逻辑及下述代码，没有发现显式的采样开关，即无论是否启用流控制，采样机制都会执行。

//src/mongo/db/repl/local_oplog_info.cpp

std::vector<OplogSlot> LocalOplogInfo::getNextOpTimes(OperationContext* opCtx, std::size_t count) {
    ...
    // Provide a sample to FlowControl after the `oplogInfo.newOpMutex` is released.
    ON_BLOCK_EXIT([opCtx, &ts, count] {
        auto flowControl = FlowControl::get(opCtx);
        if (flowControl) {
            flowControl->sample(ts, count);
        }
    });
}

延迟正常（未触发流控）时 ticket 数量计算

当多数提交的延迟小于可容忍流控阈值的延迟百分比时（认为服务状态健康），直接将上一期间分配的 ticket 数量做为基数，并增加一个可配置的常量（票据加法），参数名称为 flowControlTicketAdderConstant 默认值为 1000。总和乘以另一个可配置的常量（票据乘数），最终的值为下期分配的新票数。该乘数配置参数名称为 flowControlTicketMultiplierConstant 默认值为 1.05，修改配置需要确保大于 1。

该算法主要是为了确保系统健康时，特别是初始使用了较少的 ticket 时，系统 ticket 数量可以快速得到提升。公式：(lastTargetTicketsPermitted + flowControlTicketAdderConstant) * flowControlTicketMultiplierConstant

// src/mongo/db/storage/flow_control.cpp

int FlowControl::getNumTickets(Date_t now) {
  ...
      if (isHealthy) {
        // The add/multiply technique is used to ensure ticket allocation can ramp up quickly,
        // particularly if there were very few tickets to begin with.
        ret = multiplyWithOverflowCheck(_lastTargetTicketsPermitted.load() +
                                            gFlowControlTicketAdderConstant.load(),
                                        gFlowControlTicketMultiplierConstant.load(),
                                        kMaxTickets);
        ...
      }
  ...
}

配置参数整理

配置参数	说明
enableFlowControl	流控开关 true/false，默认 true
flowControlTargetLagSeconds	可容忍的多数提交延迟，单位为秒，默认 10
flowControlThresholdLagPercentage	可容忍的多数提交延迟百分比，{ gte: 0.0, lte: 1.0 }，该值乘以 flowControlTargetLagSeconds 为实际可容忍的延迟
flowControlMaxSamples	最大的保留样本数
flowControlSamplePeriod	采样周期，注意不是指时间，指：N 次操作采样一次
flowControlMinTicketsPerSecond	最小的 ticket 数量，默认 100。设置过小可能会导致系统需要预热，可以根据系统业务的情况适当调整
flowControlDecayConstant	MongoDB 触发流控时节流的速率，默认值为 0.5
flowControlFudgeFactor	Fudge 因子，默认为 0.95，要求小于 1，但接近 1，不建议调整
flowControlTicketAdderConstant	健康状态时，ticket 加数，以快速增加健康状态时的 ticket 数量
flowControlTicketMultiplierConstant	健康状态时，ticket 乘数，以快速增加健康状态时的 ticket 数量

需留意，MongoDB 启动时，默认的 ticket 数量为 _kMaxTickets = 1000 * 1000 * 1000 即 10 亿，而不是 flowControlMinTicketsPerSecond 的值。通过如下命令可以查看当前的票据情况：

// MongoDB 刚启动时

tmongo40:PRIMARY> db.serverStatus()["flowControl"].targetRateLimit
1000000000

tmongo40:PRIMARY> db.serverStatus()["flowControl"]
{
    "enabled" : true,
    "targetRateLimit" : 1000000000,
    "timeAcquiringMicros" : NumberLong(76),
    "locksPerOp" : 0,
    "sustainerRate" : 0,
    "isLagged" : false,
    "isLaggedCount" : 0,
    "isLaggedTimeMicros" : NumberLong(0)
}

// 触发流控后

tmongo40:PRIMARY> db.serverStatus()["flowControl"]
{
    "enabled" : true,
    "targetRateLimit" : 2015,
    "timeAcquiringMicros" : NumberLong(12064),
    "locksPerOp" : 1,
    "sustainerRate" : 2196,
    "isLagged" : true,
    "isLaggedCount" : 1,
    "isLaggedTimeMicros" : NumberLong(0)
}
tmongo40:PRIMARY> db.serverStatus()["flowControl"]
{
    "enabled" : true,
    "targetRateLimit" : 1014,
    "timeAcquiringMicros" : NumberLong(38346),
    "locksPerOp" : 1,
    "sustainerRate" : 1924,
    "isLagged" : true,
    "isLaggedCount" : 1,
    "isLaggedTimeMicros" : NumberLong(0)
}

日志

触发限流时，可以在 MongoDB 的日志里找到 flowControl 相关的日志。

其他结论

好的限流效果需要根据业务的情况持续调测相关参数，且 MongoDB 的限流算法主节点的处理能力受主节点影响，存在多种不确定因素（如网络），建议谨慎开启。或基于前述情况，建议降低流控敏感度，如放宽对大多数主从提交的延迟阈值容忍，仅在较极端情况下对 MongoDB 触发保护，避免过于敏感反而影响正常业务请求；
根据某业务的线上表现来看，在 CPU、io 吞吐极低的情况下，MongoDB 默认的参数配置仍频繁的触发限流。因此建议仍如 1；

参考文档

enableFlowControl: https://www.mongodb.com/docs/v4.2/reference/parameters/#param.enableFlowControl
source code: https://github.com/mongodb/mongo/tree/r4.2.20

WireGuard 浅显体验

2022-05-15T17:07:00+08:00

WireGuard® 是一个极其简单、快速且现代的 VPN，它利用了最先进的加密技术。目的是提供一种更快、更易配置、更精简的通用 VPN。最初是为 Linux 开发（并且已经合并至 Linux Kernel, >5.6），底层是 VPN，现在支持 Windows、macOS、BSD、iOS、Android 等跨平台。目前还处于活跃的开发当中，但仍不失为一个简易友好，且性能、安全性和兼容性都很棒的 VPN 解决方案。

Linus Torvalds 给予 WireGuard 很高的评价（work of art）：

Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.

安装篇

具体的安装可参考 Installation，笔者使用的操作系统为 Debian bullseye，官方源已经自带，仅需要 root 用户 apt-get install wireguard 一条命令搞定。

配置篇

安装过程比较简单，没有打脸官方所宣传的简单，具体也可以参考官方文档 QuickStart。

场景一：Peer-To-Peer，两台服务器可互通

笔者这里有两台机器，其中服务器 A 为腾讯云的机器，系统内看到的地址为内网地址，在腾讯云配置了公网 eip。

服务器 B 为一台公网的机器，有直接的公网 IP。（这里留下了一个坑点）

生成 WireGuard 公私钥

以下命令需要在服务 A 和服务器 B 执行：

# 生成私钥
wg genkey > wg.private
# 生成公钥
wg pubkey < wg.private > wg.pubkey

生成 WireGuard 配置

分别在两台机器上创建 /etc/wireguard/wg0.conf 文件。

服务器 A 腾讯云机器配置如下：

[Interface]
ListenPort = 57259 # UDP 端口，根据自己的需要设定即可
Address = 172.16.1.1/24 # WireGuard 网络设备 IP 地址，这里使用 172.16.1.1
PrivateKey = uJj+x/... # 在这台服务器上生成的 wg.private 文件内容

[Peer]
PublicKey = W72b9l... # 在服务器 B 生成的 wg.pubkey 文件内容
AllowedIPs = 172.16.1.2/32 # 服务器 B WireGuard 网络设备 IP 地址，也可以开放 /24 网段
Endpoint = 108.xx.xx.xx:34101 # 服务器 B 的公网 IP 地址及 ListenPort

服务器 B 公网机器配置如下：

[Interface]
ListenPort = 34101 # UDP 端口，根据自己的需要设定即可
Address = 172.16.1.2/24 # WireGuard 网络设备 IP 地址，这里使用 172.16.1.2
PrivateKey = kETG3... # 在这台服务器上生成的 wg.private 文件内容

[Peer]
PublicKey = hTfx29g... # 在服务器 A 生成的 wg.pubkey 文件内容
AllowedIPs = 172.16.1.0/24 # 参考服务器 A，这里开放 /24 网段
Endpoint = 118.xx.xx.xx:57259 # 服务器 A 的公网 IP 地址及 ListenPort

之后分别在两台机器上使用命令 wg-quick up wg0 后隧道就建议好了，可以通过 ping 来检查。

到这里还比较顺利，确实非常简单。笔者就转移注意力去开展其他的工作了，过了几分钟回来发现网络断开了，从服务器 A 腾讯云机器单向无法 ping 通 B 服务器，此时从 B 服务器 ping A 服务器后网络恢复（第一个问题）。

为什么呢？

怀疑是腾讯云服务器系统内只能看到内网 IP 的问题，毕竟这里是通过网关转发，在我之前其他的网络试验中已经多次踩中这个坑。继续往下翻 QuickStart 找到答案：

if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives.

解法也比较简单，在上面两台机器的 wg0.conf 配置文件中的 [Peer] 部份分别加上 keepalive 相关的配置即可（默认是 0，也就是不开启，这里我们设置为 25 秒）：

PersistentKeepalive = 25

场景二：能不能内网穿透呢？

再找了一台纯内网的服务器 C，该服务器可以访问外网，但外部网络无法访问该服务器。且不清楚该服务器 C 的外网出口 IP 是什么。

配置内网服务器

参考场景一的内容进行 WireGuard 安装和配置，假设服务器 C 的 WiredGuard 设备地址设置为 172.16.1.3，则配置如下：

[Interface]
Address = 172.16.1.3/24
PrivateKey = aHebd...

[Peer]
PublicKey = hTfx29g...
AllowedIPs = 172.16.1.0/24
Endpoint = 118.xx.xx.xx:57259
PersistentKeepalive = 25 # 处于 NAT 环境的设备需要加上 keepalive 配置

主要差异： ListenPort 的配置取消了，因为这台机器纯内网，我们无法判定最终映射的公网 IP 和端口分别是什么。上述配置保存后，通过 wg-quick up wg0 启动设备即可。

在服务器 A 腾讯云的机器上 /etc/wireguard/wg0.conf 增加该服务器 C 的 peer 配置：

[Peer]
PublicKey = hESH+Md6... # 服务器 C 的 wg.pubkey 内容
AllowedIPs = 172.16.1.0/24
PersistentKeepalive = 25

主要差异： Endpoint 配置取消了，毕竟 A 不知道 C 用的会是哪个公网 IP 和端口。保存配置后，分别执行 wg-quick down wg0 和 wg-quick up wg0 即可。

本以为到这里已经完成配置了，结果第二个问题来了。两台服务器 ping 不通。再次检查配置确认无误，陷入深深的思考~

解决办法：网络不决问防火墙。想到这里因为服务器 C 是在内网，WireGuard 能互通的前提肯定是服务器 C 要先访问服务器 A 的 ListenPort，检查防火墙配置，服务器 A 的 57259 UDP 端口没有对外开放。通过以下命令开放 57259 端口访问：

iptables -I INPUT 1 -p udp -m udp --dport 57259 -j ACCEPT

端口开放后，两台机器之间的互联果然正常了。

一些结论

如果 wg 两端设备都有公网地址可达，分别配置 Address 和 ListenPort 后，两台机器隧道可以互通，通常无需特殊配置；
如果设备位于防火墙或网关后面，需要打开 keepalive 配置；
内网穿透时，做为网关的机器（公网那台）需要开放 ListenPort 的防火墙访问；
根据需要，你可能需要打开设备的数据包转发（net.ipv4.ip_forward = 1）和网络地址转换功能（NAT/MASQUERADE），这里不展开；

Debian 指定内核启动

2022-05-07T12:59:00+08:00

升级完内核发现有一些问题需要回退，但是因为不能直接接触机器终端，需要通过 grub 配置指定内核版本重新启动。

操作系统：Debian 11

涉及文件：

/etc/default/grub
/boot/grub/grub.cfg

操作步骤：

通过命令 grep -e 'menuentry ' -e 'subm' /boot/grub/grub.cfg | awk -F'--' '{print $1}' 找到需要启动的内核菜单名称：

假设上图中的 Debian GNU/Linux, with Linux 5.10.0-13-amd64 是我们期望使用的内核，则需要引用图示 1 和 2 修改 /etc/default/grub。
修改 /etc/default/grub 中的 GRUB_DEFAULT=0 为如下值：

GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 5.10.0-13-amd64"
执行命令 update-grub，成功后重启即可。

当 cgroups 碰上超线程

2022-03-29T11:24:00+08:00

超线程

当英特尔® 超线程技术处于激活状态时，CPU 会在每个物理内核上公开两个执行上下文。这意味着，一个物理内核现在就像两个“逻辑内核”一样。超线程技术就是利用特殊的硬件指令，把两个逻辑内核模拟成两个物理芯片，让单个处理器都能使用线程级并行计算，进而兼容多线程操作系统和软件，减少了 CPU 的闲置时间，提高的 CPU 的运行效率。

虽然采用超线程技术能同时执行两个线程，但它并不象两个真正的 CPU 那样，每个 CPU 都具有独立的资源。当两个线程都同时需要某一个资源时，其中一个要暂时停止，并让出资源，直到这些资源闲置后才能继续。因此超线程的性能并不等于两颗 CPU 的性能。根据 Intel 官方文档反馈，理论情况下在服务器应用程序中可提升 30% 的性能。

怎么确认机器是否开启超线程

通常情况下，我们只需要通过 /proc/cpuinfo 即可确认机器是否开启超线程。当相同的 physical id 和 core id 出现两次时，即表示机器开启了超线程。

![image-20210830174503295](/static/cpus_hyperthreading.png) 图 1. /proc/cpuinfo

以图 1 为例，在 /proc/cpuinfo 中共可以找到 48 个 CPU，根据 physical id 和 core id 的组合，我们可以画出 CPU 架构图如下图 2。其中如 0-24/2-26/../23-47 表示相同 core id，启用了超线程后操作系统看到的逻辑 CPU 对。

![image-20210830175849529](/static/cpu_arch.png) 图 2. 物理 CPU 与逻辑 CPU 关系

CGROUPS

cgroups 是 Linux 内核提供的一种可以限制单个进程或者多个进程所使用资源的机制，可以对 cpu，内存等资源实现精细化的控制，目前市面上相当流行的轻量级容器 Docker 就使用了 cgroups 提供的资源限制能力来完成 cpu，内存等部分的资源控制。

笔者目前主要的工作内容是为公司提供数据库私有云服务，为了有效充分的利用服务器资源，我们会利用 cgroups 对资源进行隔离，根据业务需求提供不等规模的机器资源。其中对 cpu 的隔离是通过 cpuset.cpus 来进行的，通常情况下，我们会保留头部数个 cpu，如 CPU 0-CPU 5 做为系统保留 CPU。其它 CPU 则按顺序，如将 6,7,8、9,10,11,12，13，14 分配给两个不同的实例。

为了业务的可用性考虑，我们的 CPU 分配还是比较充份的，通常 50% 是我们的一个相对安全水位。所以大多数情况下，上面的按序分配并不会带来什么问题。本文主要是探讨极端情况下上述 cpu 分配方式可能造成的问题。

问题

由于共用了物理 CPU，容器之间可能存在 CPU 争抢：

以数据库为例，明明 A 实例的负载并不高，但有时候会忽然「卡」那么一下或者刷个慢查询，但业务并没有发生变化，DBA 也无法追踪到不合理的 SQL 或索引缺失等情况

图 3. 逻辑 CPU 分配案例一

以上图 3 为例，假设我们给 Container A 绑定了 2, 3, 4 共 3 个 CPU，给 Container B 绑定了 26, 27, 28 共三个 CPU，可以看到 2-26, 4-28, 3-27 分别共享了一个物理核心（core id 相同）。根据对超线程的理解：当两个线程都同时需要某一个资源时，其中一个要暂时停止，并让出资源，直到这些资源闲置后才能继续，假设 Container A 的负载较高，则 Container B 是有可能受到影响并导致出现 cpu 等待的情况的，反映到业务，则是：不知道为什么抽风了。
高负载情况下，隔离资源的实际性能表示与标称值不符：

图 4. 逻辑 CPU 分配案例二

以上图 4 为例，假设 0, 1, 2, 45, 46, 47 为保留 CPU（不明确分配实际业务），其它 CPU 按顺序每 6 个一组分配至不同的业务容器，我们可以猜测分配到 21, 22, 23, 24, 25, 26 这 6 个 CPU 的容器会有较少的超线程资源争抢，预计会有更好的性能表现。

下图为某业务的实际测试图，在施加具备让容器满载压力情况下，具备较少超线程争抢的容器拥有较好的性能。这在大多数情况下可能并不是好事：

图5. 某业务使用“图 4. 逻辑 CPU 分配案例二”压力测试情况
- 个别节点拥有较高性能可能造成业务上线压力评估的数据失真；
- 对于分布式场景，各节点的能力承载存在明显不一致可能造成分布式系统的降级甚至雪崩；
上述两个问题本质是一样的，都是因为超线程的争取造成的压力不一致、资源抢占。虽然大多数情况下通过资源的预留减少了上述问题发生的概率，但当问题发生时，一线技术人员极难排查，只能以疑难问题或偶尔抽风等玄学又无奈的口径进行解释。对技术人员的业务技能储备有非常高的要求，需要对硬件架构、操作系统、业务架构等多方面都有较清晰的了解。

参考文档

速率限制算法：固定窗口与滑动窗口

2022-03-28T15:59:00+08:00

在生产环境中，我们经常需要通过一定的办法方案来保护我们的系统（比如 API）免受无意的或恶意的过度使用。在极端情况下，我们还需要对系统进行适度的降级，以确保系统的可用性。速率限制（rate limit）有助于自动化该过程（有时候也会称为流量控制）。

这里我们主要介绍固定窗口计数算法和滑动窗口计数算法。

固定窗口 Fixed Window

固定窗口算法比较好理解，大致的概念如下：

时间被切分成固定大小的窗口，比如 60 秒或 5 分钟等；
每个时间窗口允许通过的请求阈值固定，假定为 N；
每一次请求进来，对当前时间窗口的计数器加 1，假设为 n；
当当前时间窗口的请求计数超过阈值时（n>N），丢弃当前时间窗口进来的所有请求；

整体的理解可以参考下述图例 1（固定时间窗口 1 秒，每秒钟允许通过 3 个请求）：

图 1. 固定窗口算法图例

看起来好像没有什么毛病，在允许的时间窗口内只允许通过预设的请求。为什么还会需要滑动窗口算法，我们看一下固定窗口算法的问题：

以上图为例，假定 14:00:02 秒的 3 个请求是在后 500ms 到达，14:00:03 分的 3 个请求是在前 500ms 到达，实际上一秒内可能通过了超过预设的 3 个请求，系统被击穿（参考下图 2）；
如果这是一个高并发系统，那么有可能存在大量请求等待时间窗口重置的情况，还是以上图为例，一切换新的时间窗口，系统可能马上在短时间内被击穿不可用（踩踏）；

图 2. 固定窗口算法问题

滑动窗口 Sliding Window

为了解决固定窗口在时间窗口切换边界的流量尖峰问题，引入了滑动窗口计数算法。该算法在固定窗口的基础上，将固定窗口进行更细粒度的切分：

将时间划分为多个固定区间，如 200ms；
在每个区间内每有一次请求则计数加 1，并维持固定的时间窗口，如固定时间窗口为 1 秒，则占用 5 个时间区间；
每经过一个区间的时间，抛弃最早的区间，并纳入最新的时间区间；
如果当前时间窗口的请求数量超过了预设限制，则本时间窗口内的后续请求都会被丢弃；

基本算法通过下图 3 概要说明，可以直观发现滑动窗口计算方法可以有效避免窗口切换的边界流量尖峰及踩踏问题。并且在我们需要提高流控精度的时候，可以通过划分更细的时间区间来实现。

图 3. 滑动窗口算法图例

注：算法可以进一步简化，假设当前时间窗口已经过去 25%，目前的请求数为CurrentN，上一次时间窗口共接受 PreN 次请求（权重为 100%-25%=75%），如果 (PreN * 0.75 + CurrentN) > 预设请求阈值 则丢弃本次请求，反之放行本次请求。

参考文档

[How to Design a Scalable Rate Limiting Algorithm with Kong API

记一次 TiDB 时区设置异常问题排查

2019-10-12T22:27:00+08:00

收到同事的反馈，两个配置一模一样的 TiDB 集群，在执行 SELECT NOW(); 操作的时候出现了不一样的结果，A 集群的时间与系统时间一致，B 集群的时间比系统时间少了 8 小时。

由于我们的 OS、TiDB 配置是统一管理的，所以我并不怀疑是因为两个集群当前配置不一样导致的。第一反应肯定是因为在 TiDB 启动之前用了错误的时区（UTC），然后 TiDB 引用了错误的时区导致的这个时间问题。根据常规经验，重启一下 TiDB 进程问题应该能解决。

然而这一次失望了，重启 TiDB 之后，并没有发生什么变化。跟同事要了服务器信息，直接登录到机器上看一下吧。以下是整体的排查过程。

先确认是不是，再查为什么

首先还是确认是不是有这个问题（再研究为什么），根据官方文档，检查了 time_zone 信息，并没有发现异常，有问题的集群和没问题的集群配置也是完全一样的。

mysql> SELECT @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM             | SYSTEM              |
+--------------------+---------------------+
1 row in set (0.01 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%time_zone';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)

mysql>

虽然这里没有发现明显问题，但我们还是发现了一个疑点：我们的服务器，不可能会有 CST 这个时区设置（我们用的是 HKT），但 CST 这个很明显不是问题的原因。

日志是一定要看的

几乎可以这么说，日志就是为了排查问题而诞生的，任何不能马上判断的问题，都应该去翻一下日志，对服务的健康情况进行判断。因为是时区相关的问题，所以直接对 TiDB 的日志做了一个 fgrep -i timezone tidb.log 的操作，没想到真的发现了错误日志，毫无波折，就是这么惊喜。（TiDB 日志打印出来是完整一行的，以下内容我稍微格式化了一下，转化为真正的换行）：

[019/10/09 16:21:42.111 +08:00] [ERROR] [time.go:81] ["locate timezone files failed"] [] [stack="github.com/pingcap/tidb/util/timeutil.InferSystemTZ
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/util/timeutil/time.go:81
github.com/pingcap/tidb/session.writeSystemTZ
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/bootstrap.go:786
github.com/pingcap/tidb/session.doDMLWorks
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/bootstrap.go:935
github.com/pingcap/tidb/session.bootstrap
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/bootstrap.go:290
github.com/pingcap/tidb/session.runInBootstrapSession
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/session.go:1541
github.com/pingcap/tidb/session.BootstrapSession
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/session.go:1460
main.createStoreAndDomain
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/tidb-server/main.go:205
main.main
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/tidb-server/main.go:171
runtime.main
/usr/local/go/src/runtime/proc.go:200"]

几乎可以直接肯定是因为这个报错导致的问题了，但还是需要靠撸代码来证明一下的。

撸代码

根据上述的错误日志，可以知道最终实际执行出错的函数在 util/timeutil/time.go 的 InferSystemTZ 函数里，我们来看下这个函数做了什么：

// InferSystemTZ reads system timezone from `TZ`, the path of the soft link of `/etc/localtime`. If both of them are failed, system timezone will be set to `UTC`.
// It is exported because we need to use it during bootstap stage. And it should be only used at that stage.
func InferSystemTZ() string {
  // consult $TZ to find the time zone to use.
  // no $TZ means use the system default /etc/localtime.
  // $TZ="" means use UTC.
  // $TZ="foo" means use /usr/share/zoneinfo/foo.
  tz, ok := syscall.Getenv("TZ")
  switch {
  case !ok:
    path, err1 := filepath.EvalSymlinks("/etc/localtime")
    if err1 == nil {
      name, err2 := inferTZNameFromFileName(path)
      if err2 == nil {
        return name
      }
      logutil.Logger(context.Background()).Error("infer timezone failed", zap.Error(err2))
    }
    logutil.Logger(context.Background()).Error("locate timezone files failed", zap.Error(err1))
  case tz != "" && tz != "UTC":
    for _, source := range zoneSources {
      if _, err := os.Stat(source + tz); err == nil {
        return tz
      }
    }
  }
  return "UTC"
}

可以看到，TiDB 设置时区的逻辑是首先获取操作系统的 TZ 变量，再从 /etc/localtime 的实际软链地址提取，最后 fallback 为 UTC。这个逻辑还是与官方文档的描述一致的。但是我们的机器上肯定是有 /etc/localtime 文件的，文件肯定也是正确的，为什么会失败呢？再来看一下上述代码里最终分析 /etc/localtime 的函数 inferTZNameFromFileName 都做了什么？

// inferTZNameFromFileName gets IANA timezone name from zoneinfo path.
// TODO: It will be refined later. This is just a quick fix.
func inferTZNameFromFileName(path string) (string, error) {
  // phase1 only support read /etc/localtime which is a softlink to zoneinfo file
  substr := "zoneinfo"
  // macOs MoJave changes the sofe link of /etc/localtime from
  // "/var/db/timezone/tz/2018e.1.0/zoneinfo/Asia/Shanghai"
  // to "/usr/share/zoneinfo.default/Asia/Shanghai"
  substrMojave := "zoneinfo.default"

  if idx := strings.Index(path, substrMojave); idx != -1 {
    return string(path[idx+len(substrMojave)+1:]), nil
  }

  if idx := strings.Index(path, substr); idx != -1 {
    return string(path[idx+len(substr)+1:]), nil
  }
  return "", fmt.Errorf("path %s is not supported", path)
}

代码的注释里明确写了只支持 /etc/localtime 为软链接，代码的逻辑也是通过截取 /etc/localtime 软链指向的具体文件路径来获得时区信息。看一下我们服务器上的这个文件：

$ ls -alh /etc/localtime
-rw-r--r-- 1 root root 1.2K 10月 12 10:11 /etc/localtime

果然是一个文件而不是一个软链接。这下又带来了两个疑问：

如果我改成软链再重启 TiDB 能不能解决问题呢？实践证明，不能解决。这里不再赘述。
函数逻辑很明确是 fallback 了 UTC，根据 SELECT NOW(); 早了 8 小时也可以确认是 UTC，可为什么 system_time_zone 是 CST 呢？

看到的（CST）和实际的（UTC）不一样？

TiDB 在拿不到正确的时区，回落至 UTC 时，最终 UTC 是怎么设置的呢？我们再来看一下上面的错误日志：

github.com/pingcap/tidb/session.writeSystemTZ
/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/session/bootstrap.go:786

在 session/bootstrap.go 我们找到：

// writeSystemTZ writes system timezone info into mysql.tidb
func writeSystemTZ(s Session) {
  sql := fmt.Sprintf(`INSERT HIGH_PRIORITY INTO %s.%s VALUES ("%s", "%s", "TiDB Global System Timezone.") ON DUPLICATE KEY UPDATE VARIABLE_VALUE="%s"`,
    mysql.SystemDB, mysql.TiDBTable, tidbSystemTZ, timeutil.InferSystemTZ(), timeutil.InferSystemTZ())
  mustExecute(s, sql)
}

TiDB 首次启动时，拿到时区信息后，将时区信息写到了 mysql.SystemDB.mysql.TiDBTable，也就是 mysql.tidb，其中 VARIABLE_NAME 为 tidbSystemTZ，也即 system_tz

  // The variable name in mysql.tidb table and it will be used when we want to know
  // system timezone.
  tidbSystemTZ = "system_tz"

继续直接登录机器看一下这张参数的内容在两个集群中有什么不一样：

可以看到，确实是设置了 UTC，那么也可以非常明确是由于这个值引起的了。经过测试，可以通过如下两种方式解决：

更新 mysql.tidb 中 system_tz 为正确的时区，如我们这里为 HKT，并重启 tidb-server 进程后，问题可以得到解决。
根据官方文档设置 time_zone 变量，问题可以得到解决。如果有需要，可以把 system_tz 也修改了，tidb-server 不会自行进行调整：

为什么

到这里，我们可以很明确 TiDB 参数这里导致时间不对的情况了。但是还有几个疑问还没有得到解决：

为什么同样的配置，有一个集群是正常的，一个集群又用了 UTC 呢？

这个情况主要是因为我们的机器有一个初始化的过程，在没有完成初始化的时候，/etc/localtime 确实是一个软链接，并且指向了 /usr/share/zoneinfo/Asia/Hong_Kong，当我们的 tidb-server 进程在这个文件被修改之前启动时，会使用正确的时区。但同时，我们在机器上部署了 puppet 进行统一的配置管理，puppet 会做一个类似 cp /usr/share/zoneinfo/Asia/Hong_Kong /etc/localtime 的操作，将 /etc/localtime 替换为一个文件，这个时候，tidb-server 无法正确分析时区信息，导致 fall back 至 UTC。简单示意如下：
为什么 SELECT @@global.time_zone, @@session.time_zone; 看到的是 CST，但不管是我们的机器还是 TiDB 配置文件都没有引用 CST 这个时区，CST 从哪里来的？

属于 tidb-server 的默认行为，tidb-server 初次启动时，会默认设置为 CST。可以参考 session/bootstrap.go 和 sessionctx/variable/sysvar.go 这里不再展开。
system_tz、@@global.time_zone、@@sessio.time_zone 的关系是什么？system_tz 和 time_zone 两者的生效逻辑是怎样的？
- @@session.time_zone 在新建连接时，值主要依赖于 @@global.time_zone，session 值等同于 global，默认都为 SYSTEM，即 system_tz 值；
- 如果单独修改了 @@session.time_zone ，则当前连接的 time_zone 以 session 设置为准；
- tidb-server 在每次启动的时候会从 mysql.tidb 加载 system_tz 值，并设置系统时区。这也是为什么我们在更新了 system_tz 并重启 tidb-server 后，可以获取到正确时间的原因；
tidb-server 启动时通过 mysql.tidb 设置系统时区的相关代码可以在 session/session.go 找到：

// loadSystemTZ loads systemTZ from mysql.tidb
func loadSystemTZ(se *session) (string, error) {
  sql := `select variable_value from mysql.tidb where variable_name = 'system_tz'`
  rss, errLoad := se.Execute(context.Background(), sql)
  if errLoad != nil {
    return "", errLoad
  }
  // the record of mysql.tidb under where condition: variable_name = "system_tz" should shall only be one.
  defer func() {
    if err := rss[0].Close(); err != nil {
      logutil.Logger(context.Background()).Error("close result set error", zap.Error(err))
    }
  }()
  req := rss[0].NewChunk()
  if err := rss[0].Next(context.Background(), req); err != nil {
    return "", err
  }
  return req.GetRow(0).GetString(0), nil
}

// BootstrapSession runs the first time when the TiDB server start.
func BootstrapSession(store kv.Storage) (*domain.Domain, error) {

小结

其实还蛮普通的一个问题，只是之前碰到比较多的情况是在环境初始化没完成时就启动服务，导致服务出现状况。这次 TiDB 这里刚好反过来，环境初始化未操作之前反而是正常的，初始化之后异常了；
问题的线索其实完完整整的保存在了日志中，流程是否有可以优化的空间有待考证商榷，但日志在排查问题的时候是一定要首先关注的；
/etc/localtime 直接使用文件不是一个合理的方式，TZ 环境变量的优先级也高于 /etc/localtime。这个可以参考 man 文档：
```
Because the timezone identifier is extracted from the symlink target 
name of /etc/localtime, this file may not be a normal file or
hardlink.
```

TiDB DM 数据库同步 STEP BY STEP

2019-09-29T13:08:00+08:00

前段时间，看到了一篇关于数据库选型的文章（MongoDB/TiDB/CockroachDB），忍不住感慨了一句，TiDB 一看就是大户人家，什么工具都可以有，什么工具都迭代得特别快，没有钱没有人，难以想像如何才能驱动得了。TiDB/TiKV/PD/Mydumper/Loader/Syncer/Data Migration/TiDB Lighting/Pump/Drainer ... 光是弄清楚这些组件是用来做什么的，感觉都可以评个高工了 :-)

随着 DM 1.0 GA 的 release，我们也开始考虑将 syncer 迁移至 DM。主要原因还是 syncer 已经太久没有更新了，否则 syncer 这种简易几乎无须部署的工具还是比较对我个人的胃口的，官方很喜欢把工具集群化（可能听起来厉害一点），DM 也是，那就按着最小目标（syncer）折腾一下吧。

DM 的架构文档可以参考官方，整个集群有三个角色 dmctl/dm-master/dm-worker。

DM-master 负责管理和调度数据同步任务的各项操作。
DM-worker 负责执行具体的数据同步任务。
dmctl 是用来控制 DM 集群的命令行工具。

官方也提供了基于 Ansible 的部署工具，如果你不是特别需要了解实际的部署过程，或者你的环境对 ansible 的亲和度比较好的话，可以参考使用 DM-Ansible 部署 DM 集群。在这篇文章里，我们还是希望对于 DM 的部署有一定的了解，另外我们的小目标是实现类似 syncer 功能，因此，让我们 step by step 人肉部署吧。（好吧，吐槽一下，其实本人是很反感什么都要 ansible 再包一层的，无法直接通过文档了解工作方式，还非得去读 ansible 的相关部署文件）。

准备工作

确认工作目录，假定这里为 /home/dm，并确保相关目录已经建立且具备读写权限：mkdir -p /home/dm/log；
确保机器上已经具备相应的命令行工具，如：tar、wget、rsync 或 cp 等；
下载 DM 二进制文件：

wget http://download.pingcap.org/dm-latest-linux-amd64.tar.gz
tar -zxvf dm-latest-linux-amd64.tar.gz
rsync -avz dm-latest-linux-amd64/bin/ /home/dm/bin/

机器列表，这里我们主要熟悉部署过程，且不需要分库分表合并等功能，只实现 syncer 流程，因此 master 和 worker 均只部署在同一台同器：

角色	地址
DM-master	127.0.0.1:8261
DM-worker	127.0.0.1:8262

配置文件

dm-worker

# DM-worker Configuration: worker.toml
# MySQL Server ID, 注意不要和已有的 ID 冲突
server-id = 8262
# 可以理解为 worker 的唯一标识
source-id = "worker-8262"
worker-addr = "127.0.0.1:8262"
# 支持源为 mysql 或 mariadb
flavor = "mysql"
# 是否启用 GTID，开启前需要上游 MySQL 开启 GTID 功能
enable-gtid = true
# MySQL Master/Slave 发生切换时，是否修复 gtid
auto-fix-gtid = true
# 开始同步的位置，我这里使用 GTID，该值为 MySQL Master 上的 Executed_Gtid_Set 值
# relay-binlog-name = "binlog.000140"
relay-binlog-gtid = "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2"
# charset of DSN of source mysql/mariadb instance
charset = ""
# worker 元数据存储目录，需要提前创建好
meta-dir = "/home/dm/meta/worker-8262"
# relay log 的本地存储目录，需要提前创建好
relay-dir = "/home/dm/relay/worker-8262"

# 源数据库，一个 worker 只能对应一个 MySQL 源
[from]
host            = "127.0.0.1"
user            = "dm"
# 该密码为使用 dmctl -encrypt ${你的原始密码} 加密后的字符串
password    = "vUYLfdtQlHLF6Kr4IHg8NkDjiPtVig6p"
port            = 3306

# relay log purge strategy
[purge]
interval            = 3600
expires             = 0
remain-space    = 15

配置不算特别复杂，需要留意的地方都在注释里进行说明了。其中 source-id 请记下来，接着配置 dm-master 需要用到。

再次提醒，MySQL 的密码配置需要使用 dmctl 进行加密处理。

dm-master

# dm-master Configuration: master.toml
log-level       = "info"
log-file        = "/home/dm/log/dm-master.log"
master-addr = "127.0.0.1:8261"

[[deploy]]
source-id = "worker-8262"
dm-worker = "127.0.0.1:8262"

配置文件比较简单，基本上都不需要解释。其中 [[deploy]] 对应一个 worker，可以有多个 [[deploy]] 。目前了解到的，dm-worker 只能通过配置文件并重启 dm-master 进行加载，无法通过 dmctl 进行运行上填加。好在 dm-master 几乎随时都可以重启，所以也不是特别大的问题。

dmctl

# dmctl Configuration: ctl.toml
master-addr = "127.0.0.1:8261"

dmctl 的配置就相当简单了，只需要指定 dm-master 地址。而 dmctl 也是我们与 dm-master 打交道的最直接工作。

集群启动

经过上述的配置（是不是没有想像中复杂），我们已经可以开启集群了：

启动 master: bin/dm-master -config master.toml
启动 worker: bin/dm-worker -config worker.toml

除了跟踪日志输出，确认进程是否正常启动。我们还可以借助 dmctl 来检查当前集群的情况，使用 bin/dmctl -config ctl.toml 连接集群，并通过 query-status 查询集群状态，返回如下（成功）：

» query-status
{
    "result": true,
    "msg": "",
    "workers": [
        {
            "result": true,
            "worker": "127.0.0.1:8262",
            "msg": "no sub task started",
            "subTaskStatus": [
            ],
            "relayStatus": {
                "masterBinlog": "(binlog.000172, 234)",
                "masterBinlogGtid": "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2",
                "relaySubDir": "2ea42e60-a157-11e9-8f2d-0ef02be0adee.000001",
                "relayBinlog": "(, 4)",
                "relayBinlogGtid": "34204ac9-a157-11e9-bc03-c6e9019f8073:1-2,2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558",
                "relayCatchUpMaster": true,
                "stage": "Running",
                "result": null
            },
            "sourceID": "worker-8262"
        }
    ]
}
»

这个时候，系统还没有配置任何同步任务，所以也可以看到显示的是：no sub task started。接下来，我们开始来配置一个最基础的同步任务。

配置并应用同步任务

创建任务配置文件

PingCAP 在任务配置这一块有比较完善的说明了DM 任务配置文件介绍。这里我们以将源库为 abc 迁到目标库 abc_dm 为例子做简单说明：

---
name: test
task-mode: all
is-sharding: false
meta-schema: "dm_meta"
remove-meta: false
enable-heartbeat: false

target-database:
  host: "192.168.143.41"
  port: 3306
  user: "dm"
  password: "vUYLfdtQlHLF6Kr4IHg8NkDjiPtVig6p"

mysql-instances: # 源库及相关的同步规则配置
  -
    source-id: "worker-8262"

    meta:
      binlog-name: binlog.000140
      binlog-pos: 141868
    route-rules: ["user-route-rules-schema"]
    black-white-list: "instance"

routes:
  user-route-rules-schema:
    schema-pattern: "abc"
    target-schema: "abc_dm"

black-white-list:
  instance:
    do-dbs: ["abc"]

上面参数的说明都可以在官方文档找到，这里对几个重要的参数再做补充说明：

参数	说明
meta-schema	DM 会将该 task 对应的 meta 信息，如断点（checkpoint）存储至目标集存中的该数据库
remove-meta	通常我们希望在重启 worker/task 时可以从上次断点继续同步，需要设置为 false
password	需要使用 dmctl 加密
source-id	理解为相应 dm worker 的 source-id
routes	可以在这里配置数据库表的改名规则，具体参考官方文档
filters	这里没有用到，可以过滤相应的 binlog events，如 `drop table` 操作，具体参考官方文档

应用并启动同步任务

使用 bin/dmctl -config ctl.toml 登录 dm master，并执行 start-task test.yaml 即可，确认 test.yaml 文件在当前目录下，成功的话将收到如下返回：

{
    "result": true,
    "msg": "",
    "workers": [
        {
            "result": true,
            "worker": "127.0.0.1:8262",
            "msg": ""
        }
    ]
}

这个时候再执行 query-status 可以看到相应的 dm worker 有了具体的 subTaskStatus 信息：

            "subTaskStatus": [
                {
                    "name": "test",
                    "stage": "Paused",
                    "unit": "Sync",
                    "result": {
                        "isCanceled": false,
                        "errors": [
                        ],
                        "detail": null
                    },
                    "unresolvedDDLLockID": "",
                    "sync": {
                        "totalEvents": "0",
                        "totalTps": "0",
                        "recentTps": "0",
                        "masterBinlog": "(binlog.000176, 234)",
                        "masterBinlogGtid": "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2",
                        "syncerBinlog": "(, 4)",
                        "syncerBinlogGtid": "",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": false
                    }
                }
            ],

这个时候我们通过 mysql 登录目标数据库，可以看到多了 dm_meta 和 abc_dm 两个数据库，其中 dm_meta 里面有两张表：

test_loader_checkpoint 其中 test 是任务的名称，这张表存储的是全量同步的 meta 信息；

            id: worker-8262
      filename: abc.t3.sql
     cp_schema: abc
      cp_table: t3
        offset: 156
       end_pos: 156
   create_time: 2019-09-29 12:03:59
   update_time: 2019-09-29 12:04:00

test_syncer_checkpint 其中 test 是任务的名称，这张表存储的是增量同步的 meta 信息；

            id: worker-8262
     cp_schema: abc
      cp_table: xxy
   binlog_name: binlog|000001.000176
    binlog_pos: 538
     is_global: 0
   create_time: 2019-09-29 12:11:25
   update_time: 2019-09-29 12:11:25

组件升级

dm-master

dm-master 主要负责 dmctl 的通讯，维护任务及 Sharding DDL lock 信息，重启后会与 dm-worker 重启这些信息，所以除了影响 dmctl 短暂的使用，可以随时重启，升级也就比较简单了：下载新版本 -> 覆盖旧 binary -> 重启。

dm-worker

dm-worker 在本地维护了 meta 信息，在下游（目标）数据库维护了断点（checkpoint）信息，升级也是按：下载新版本 -> 覆盖旧 binary -> 重启即可。唯一需要注意的有：

尽量避免在 sharding DDL 同步过程中重启 DM-worker。

当然，本身对数据的敬畏之心，即使没有 sharding，也不推荐在 DDL 的过程中重启 dm-worker。

dmctl

命令行交互工具，直接升级即可：下载新版本 -> 覆盖旧 binary。

问题处理

dm-worker 挂了，并且本地的 meta 信息都丢失了怎么办？

通常不需要担心，找回按原来的 worker.toml 再启动 worker 即可。其中配置文件中的 relay-binlog-gtid 或 relay-binlog-name 的位置信息可能在源数据库已经过期，可以从目标集群的 meta 库找回，或者直接从源数据库集群上使用一个相对靠前的位置信息替换即可。

确认新的 worker 已经启动后，再次通过 dmctl 执行 start-task test.yaml 即可，task 的配置文件不需要修改，断点信息会从目标数据库中的 meta 库直接获取。

总结

官方的组件（概念）特别多，ansible 的包装让用户对相关组件的工作流程了解门槛大大提升。实际部署流程比想像中较为简单。从可靠性来看，还是比较推荐放弃 syncer（较长时间未更新了），并使用 dm 做为替代工具。

MySQL Seconds_Behind_Master 忽大忽小？莫慌

2019-09-07T22:33:00+08:00

本周在某次开会的时候，忽然收到了大量的 MySQL Seconds_Behind_Master 落后的报警轰炸（落后时间随机，几百到几万秒不等），但是当我们的值班 DBA 登录 MySQL 通过 show slave status\G 查看时，发现都是 0，通常我们认为这个时候复制是正常的。那么是什么情况导致了报警的发生呢？

DBA 值班同学也比较没有头绪，我们首先做了以下几件事情：

确认监控插件是否变更？收到的答复是没有；
我们自己是否有变更？收到的答复是没有。

事后打脸了，有一位同学做了报警策略的变更，从原 X 时间内只发送第 N 条报警修改成了 X 时间内只发送第 1 条报警。该策略的变更也会导致该报警的轰炸，但是他变更的时间是在报警轰炸之后，跟此次报警轰炸原因没有正相关；

登录多个实例确认都是误报后，先通告产品，明确是误报事件，让产品不用担心，等待 DBA 查明原因；

接下来我们会议正常进行，由某位 DBA 同学对此问题进行持续跟进，这个时候了解到某报警系统正在维护，猜测与他们有关系。但是即使是与他们有关系，这个落后的时间又是如何得来的呢？暂时 DBA 值班同学也没有很好的 GET 到头绪，DBA 老司机可能当时不是特别在状态，有点懵。

刚好会议环节进入非重点环节，偷偷转移精力排查了一下，做为 DBA 门外汉，首先想到的是我要确认是不是 MySQL show slave status 里真的出现了随机的落后数值，所以我做了最原始的一件事情：写了一个 2 秒执行一次 show slave status 的脚本对 Secons_Behind_Master 进行检查，果然在脚本执行了几分钟后出现了非 0 的数值，且是一个较大的超出实际线上情况的数值。（这里已经确认了是 MySQL 本身会有这个情况出现）

接下来怎么办呢？门外汉的第一反应当然是查手册啦（手册大多数时候都是解毒良药），几乎是没有耗费时间的，直接在 MySQL 官方文档里关于这个问题的非常重要的一句说明：

when the slave I/O thread is still queuing up a new event,
Seconds_Behind_Master may show a large value until the SQL thread 
finishes executing the new event.

MySQL Replication 通常情况下有两个工作线程，I/O 线程用于获取 MySQL Master 的 Binlog，SQL 线程用于将获取到的 Binlog Events 在 Slave 从库上进行回放。

上面的描述我们通过字面简单进行了理解：当 I/O 线程仍在排队等待一件新事件时，Seconds_Behind_Master 有可能返回一个较大的随机值，直到 SQL 线程完成该事件的重放。

那么这里我们已经可以确认了，MySQL 是会出现这个情况的，并且是正常的，至少这个报警轰炸是不用特别担心了。那为什么忽然就炸出来了呢，在后面几分钟后我们得到了几个信息，确认了原因：

该报警原先的设置是 X 时间内只发送第 N 条报警：X 时间内并不一定总会出现 >= N 次的随机 Seconds_Behind_Master 飙升（并且被监控插件获取到）；即使出现 >= N 次，在 X 时间内也只会发送一条报警，所以这个问题一直并没有被注意到；
从报警平台的同事了解到，确实在维护过程中，报警策略匹配有问题，导致 X 时间内只发送第 N 条 这个策略没有生效，所有报警都发了出来；
如前述，某同事确实做了策略变更，该变更可以明确是错的，但跟上述的轰炸没有正相关。

这个时候我们整体的原因已经比较清楚了，恢复生效的策略，并同步通告相关产品具体的情况，让产品安心是我们服务的目标之一。

但这里也暴露了几个问题：

报警平台维护变更出现了一定的问题，导致策略失效；
部分 DBA 同学在某些环节对系统的了解并不够完整、也不够专业（我们都需要不断学习积累的，我自己也是学习中，能理解）；
DBA 同学在做策略变更的时候也没有在团队内部进行同步，存在管理和规范遵守上的问题；

以上问题需要我们进行反思，并在团队内进行解决。但是 MySQL Seconds_Behind_Master 是否还有监控的价值呢？对可能导致 Seconds_Behind_Master 异常的情况这里做个简单的总结：

Replication 启动时，Slave 会在主库执行 SELECT UNIX_TIMESTAMP() 并进行主库和从库的系统时间差值对比，以避免由于系统时间差异对于 Seconds_Behind_Master 的时间产生影响。但如果是 Replication 启动后的时间异常，还是会对 Seconds_Behind_Master 产生影响，因此确保系统时间的同步非常重要（ntpd）；
当 Master 和 Slave 间的网络较差时，I/O 线程不能快速的获取 Binlog Events，SQL 线程处理速度是有可能超过 I/O 线程的，那么这个时候即使是 0，也不代表主从同步是正常的。（良好的网络环境是主从同步的基础保障）
当 I/O 线程被关闭时，该值可能为 NULL。（可以理解为特殊情况）；

Seconds_Behind_Master 怎么用？

结合以上情况，我认为 Seconds_Behind_Master 还是一个很重要的同步是否落后的参考值的，只是可能我们可以做得更完善一些，比如在获取的时候，可以通过二次获取进行判断，当获取到较大值时，再次获取一次当前值进行确认。

另外，如果需要较为严格的同步监控，建议通过 Binglog 的位置：

Master_Log_file/Read_Master_Log_Pos
Relay_Master_Log_File/Exec_Master_Log_Pos

进行判断，如果(Relay_Master_Log_File, Exec_Master_Log_Pos) 和 (Relay_Master_Log_File, Read_Master_Log_Pos)位置相等且 Seconds_Behind_Master=0，那么我们可以认为目前的同步是「同步」的。（开启 gtid 的话，比对 Executed_Gtid_Set 我认为也是没有毛病的）

The End

后续相关技术内容的总结，也会逐步更新至微信平台（微信目前确实也是技术内容流转的一个好渠道），欢迎关注个人公众号（也算给自己立个 flag 吧，希望 flag 永不倒）：

在 Mac 中对 iPhone 手机网络进行抓包的方法

2018-11-02T19:58:00+08:00

通过数据线连接 Mac 笔记本，并通过 itunes 查询手机的 UUID
Mac 提供了一个工具 rvictl （rvi=Remote Virtual Interface）可以为连上的 iphone 手机创建一个虚拟网络设备，不管手机用的是移动网络还是 WIFI，均可以通过该设备进行抓包。启动虚拟设备的命令如下：

rvictl -s ${uuid}

如果成功启动，将返回：

Starting device xxxxxxxx [SUCCEEDED] with interface rvi0

其中的 rvi0 即为可用于抓包的虚拟设备。

如果操作失败，并返回 bootstrap_look_up(): 1102 错误，请通过如下命令启动服务，并重复 rvictl -s ${uuid} 的操作即可：

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.rpmuxd.plist
之后就可以通过 tcpdump 命令进行抓包了，如：

tcpdump -i rvi0 -s 0 -vvv dst host x.x.x.x -w test.pcap
之后可以通过 wireshark 打开 test.pcap 进行查看。通常你可以使用 brew cask install wireshark 安装 wireshark.

怎么通过 iTunes 往手机上安装 ipa 包？

旧版本的 iTunes，在设备信息里有个「应用」入口，并可以在这里安装 ipa 文件。这次顺便发现 iTunes 没有了这个入口，刚拿到 ipa 包时，有点不知道怎么办。原来，只要将将文件拖到 iTunes 对应的设备里，就会自动安装了。（拖到下面截图红色框框部份）

一次「安全」的变更将 redis cluster 送进了孤岛

2018-07-16T00:51:00+08:00

鉴于 redis 没有有效的鉴权方法（特别是 redis cluster），为了防止人为疏忽导致系统防火墙未被有效开启，我们决定对线上的 redis 增加显示监听内网 IP 配置：

bind 127.0.0.1 ${本机内网 IP}

在我们看来，这是一个不可能出现问题的变更，因此也没有专门安排测试。事实证明，没有保持敬畏之心的我们还是太天真了！

线上配置发布后，重启 redis 服务，一切都很顺利，进程成功启动。然后，灾难开始降临，业务开始反馈 redis 缓存无法读写，查看 redis 日志，发现：

Cluster state changed: fail

尝试通过 redis-cli 连接进行操作，连接没有问题，但当我们尝试执行 get a 操作时，集却群反馈错误：

-CLUSTERDOWN The cluster is down

首要事件是保证服务可用，我们第一时间回退配置，重启后 redis 服务恢复正常。

问题回放

开启 Debug 模式，发现有大量的 createing socket: invalid argument 怀疑是 redis 拿了 bind 中的第一个 IP 为节点 IP，导致集群中所有节点的 IP 为 127.0.0.1，因此集群的通信出现问题（事后 review 代码确认跟第一个 IP 有关系，但不是导致所有节点的 IP 为 127.0.0.1）。

1616:M 02 Jul 11:02:25.407 # Cluster state changed: ok
......
13236:M 02 Jul 11:02:27.104 . Unable to connect to Cluster Node [10.x.x.x]:16379 -> creating socket: Invalid argument
13236:M 02 Jul 11:02:27.104 . Unable to connect to Cluster Node [10.x.x.x]:16379 -> creating socket: Invalid argument
......
1616:M 02 Jul 11:02:38.438 # Cluster state changed: fail

有了上面的怀疑之后，我们尝试修改 bind 的配置，将 127.0.0.1 放到后面，即：

bind ${本机内网 IP} 127.0.0.1

重启集群发现问题果然没有出现，感觉自己好机智（进行源码分析后，发现自己还是想的太简单了）。

源码分析

redis 版本：3.2.11

根据 Cluster state changed: fail 我们定位到，redis 是在 cluster.c 的 clusterUpdateState 函数里进行集群的状态判断：

当节点状态为 CLUSTER_NODE_FAIL 或 CLUSTER_NODE_PFAIL 时，节点被标记为不可达；
当不可达的 master 节点大于 quorum 时，集群被标记为不可用；

    /* Compute the cluster size, that is the number of master nodes
     * serving at least a single slot.
     *
     * At the same time count the number of reachable masters having
     * at least one slot. */
    {
     ...
                if ((node->flags & (CLUSTER_NODE_FAIL|CLUSTER_NODE_PFAIL)) == 0)
                    reachable_masters++;
     ...
    }

    /* If we are in a minority partition, change the cluster state
     * to FAIL. */
    {
        int needed_quorum = (server.cluster->size / 2) + 1;

        if (reachable_masters < needed_quorum) {
            new_state = CLUSTER_FAIL;
            among_minority_time = mstime();
        }
    }

    /* Log a state change */
    if (new_state != server.cluster->state) {
        ....
        /* Change the state and log the event. */
        serverLog(LL_WARNING,"Cluster state changed: %s",
            new_state == CLUSTER_OK ? "ok" : "fail");
        server.cluster->state = new_state;
        ...
    }

redis cluster 主要是通过 cluster.c 中的 clusterCron 定期判断收集集群的状态，也是在这个函数里我们发现了最主要的探测函数 anetTcpNonBlockBindConnect 及非常符合异常特征的参数名称 NET_FIRST_BIND_ADDR

            fd = anetTcpNonBlockBindConnect(server.neterr, node->ip,
                node->port+CLUSTER_PORT_INCR, NET_FIRST_BIND_ADDR);
            if (fd == -1) {
                /* We got a synchronous error from connect before
                 * clusterSendPing() had a chance to be called.
                 * If node->ping_sent is zero, failure detection can't work,
                 * so we claim we actually sent a ping now (that will
                 * be really sent as soon as the link is obtained). */
                if (node->ping_sent == 0) node->ping_sent = mstime();
                serverLog(LL_DEBUG, "Unable to connect to "
                    "Cluster Node [%s]:%d -> %s", node->ip,
                    node->port+CLUSTER_PORT_INCR,
                    server.neterr);
                continue;
            }

anetTcpNonBlockBindConnect 函数位于 anet.c 文件中，该函数调用了另一个函数 anetTcpGenericConnect，NET_FIRST_BIND_ADDR 在这里的实际作用为 source addr，问题原因已经呼之欲出了。我们再次定位 anetTcpGenericConnect 函数，找到以下内容：

        if (source_addr) {
            int bound = 0;
            /* Using getaddrinfo saves us from self-determining IPv4 vs IPv6 */
            if ((rv = getaddrinfo(source_addr, NULL, &hints, &bservinfo)) != 0)
            {
                anetSetError(err, "%s", gai_strerror(rv));
                goto error;
            }
            for (b = bservinfo; b != NULL; b = b->ai_next) {
                if (bind(s,b->ai_addr,b->ai_addrlen) != -1) {
                    bound = 1;
                    break;
                }
            }
            freeaddrinfo(bservinfo);
            if (!bound) {
               anetSetError(err, "bind: %s", strerror(errno));
               goto error;
            }
        }

通过以上内容，我们可以确认 redis cluster 在健康检测，建立 socket 连接时，尝试绑定了 socket 源地址，那么 NET_FIRST_BIND_ADDR 内容究竟是什么呢？这个我们在 server.h 文件中找到了答案，确实是 bind 配置中的第一个 IP，也就是我们这里的 127.0.0.1
```
/* Get the first bind addr or NULL */
#define NET_FIRST_BIND_ADDR (server.bindaddr_count ? server.bindaddr[0] : NULL)
```

问题结论

redis cluster 在检测节点健康状态时，尝试与其它节点建立连接，但强制使用了 bind 配置中的第一个 IP 为建立 socket 的源地址
以上案例，当配置了监听 127.0.0.1 时，redis cluster 将尝试使用本地地址 127.0.0.1 去和一个外部节点建立链接，因此失败了；
基本的解决方法：使用 bind 配置时，确保将可进行通讯的 IP 放在第一个；
有没有其它问题：如果这是一个新建的 cluster 集群，那么在使用 redis-trib.rb 进行初始化集群时，该配置将导致 redis-trib.rb 工具长期阻塞，无法成功执行；
所有支持 cluster 的 redis 版本均受影响（包括 unstable 分支）；

其它

私以为强制使用 bind 第一个 IP 进行通讯的方法略有不妥，如果检测健康状态时一定需要指定源地址的话，兴许做出如下调整会有一定的优势：

当未初始化时（集群节点未明确 IP 地址），建立 socket 连接，不要指定源地址，由操作系统自行分配源地址即可；
当 redis cluster 初始化时，可以使用初始化时指定的节点 IP 做为源地址；
redis 在 anet.c 文件里，其实还提供了 anetTcpNonBlockBestEffortBindConnect 函数，这个函数如果通过绑定源地址建立 socket 链接失败后，会再次尝试由系统分配源地址的方式（不绑定），健康检查函数换成这个也不失为一个好办法；

最（chao）后（xi）：对于这次故障，没有借口，我们不能也不该出现这样的失误！我们将认真复盘改进自动化运维技术和发布验证流程，敬畏每一行代码，敬畏每一份托付。

MongoDB 随机查询获取一条或 N 条记录的方法

2018-05-24T12:14:13+08:00

熟悉 MySQL 的同学应该都知道可以通过类似如下语句简单的获取一张表里随机的 N 条记录：

SELECT * FROM table ORDER BY RAND() LIMIT N;

在 MongoDB 里应该如何操作呢？官方在 3.2 版本带来了直接的解决方案：

$sample (aggregation)

具体应该如何操作，官方也给出了一个示例，假设 Collection users 有如下记录：

{ "_id" : 1, "name" : "dave123", "q1" : true, "q2" : true }
{ "_id" : 2, "name" : "dave2", "q1" : false, "q2" : false  }
{ "_id" : 3, "name" : "ahn", "q1" : true, "q2" : true  }
{ "_id" : 4, "name" : "li", "q1" : true, "q2" : false  }
{ "_id" : 5, "name" : "annT", "q1" : false, "q2" : true  }
{ "_id" : 6, "name" : "li", "q1" : true, "q2" : true  }
{ "_id" : 7, "name" : "ty", "q1" : false, "q2" : true  }

那么可以通过命令 db.users.aggregate( [ { $sample: { size: N } } ] ) 获取随机的 N 条记录，如：

mongos> db.users.aggregate( [ { $sample: { size: 3 } } ] )
{ "_id" : 7, "name" : "ty", "q1" : false, "q2" : true }
{ "_id" : 4, "name" : "li", "q1" : true, "q2" : false }
{ "_id" : 1, "name" : "dave123", "q1" : true, "q2" : true }
mongos> db.users.aggregate( [ { $sample: { size: 3 } } ] )
{ "_id" : 7, "name" : "ty", "q1" : false, "q2" : true }
{ "_id" : 3, "name" : "ahn", "q1" : true, "q2" : true }
{ "_id" : 2, "name" : "dave2", "q1" : false, "q2" : false }
mongos>

$sample 会使用如下两种方式来获取随机的 N 条记录，具体使用哪种方式取决于如下条件：

$sample 处于聚合管道的第一阶段；
N 小于总文档数量的 5% ;
集合（Collection）中的文档数量大于 100；

当以上 3 个条件都满足时，$sample 将通过伪随机的游标来获取记录。当任一条件不满足时，$sample 将进行集合扫描，并通过随机排序来选择相应的 N 条记录。

需要注意的是：

当使用随机排序来获取记录时，排序操作会有 100 MB 的内存限制，具体可以参考 $sort and Memory Restrictions；
$sample 有可能多次返回同一条记录（document）；
尝试在一张十亿级的 Collection 上获取 1W 条随机记录，耗时约 2.5 秒，供参考；

参考文档：

https://docs.mongodb.com/manual/reference/operator/aggregation/sample/
https://jira.mongodb.org/browse/SERVER-533

《OKR 工作法》读书笔记

2018-01-30T09:50:00+08:00

目标用来明确方向，关键结果则用来量化目标，使团队和个人聚焦在一个有挑战性的目标上。

确定目标，确保团队聚焦
- 目标要有明确方向并鼓舞人心
- 目标要有时间期限
- 目标必须真正属于你
  
  思考，哪些是关键成果，哪些是目标：销售额提升 30%/用户增加一倍/收入增加到 500 万美元/完成一轮融资/拿下 XX 市场/推出一个最小化可行产品
讨论关键结果，复盘 OKR
评估 OKR 实施成果
影响目标达成的关键因素
- 没有给目标设置优先级
- 缺乏充分沟通，导致没能准确理解目标
  
  目标完成的进度必须在每周会议和邮件中汇报，分解出的项目任务必须能支撑目标的达成；
- 没有做好计划
  
  承担、庆祝与盘点
- 没有把时间花在重要的事情上
  
  重要的事情通常不紧急，紧急的事情通常不重要思考：计划应该是为了重要不紧急还是紧急不重要？
- 轻易放弃
害怕失败，不给自己挑战机会，隐藏实力，导致目标设置太低期望过高，没有能力实现没有坚持跟进目标，直到最后一周才发现没有进展（注意前面的，需要持续复盘、评估、沟通）

OKR 就是要通过不断实践、总结，发不断发现、挑战团队的潜力，不要把这个过程当作汇报、考核的结果。没有完成，一起思考为什么会这样、怎么改进。目标达成，那就设置更有挑战的目标。把精力聚焦在学习总结、挖掘潜力和高效执行上。

其它建议：

如何评估绩效：持续沟通，不地加以指导和校正。管理者和员工各自分享自己的观点与想法，这样可以减少误解，问题也能得到快速解决。年终评估的事实大家可以通过持续的沟通提前知道。
目标里不要有传统的绩效考核指标。
OKR 进度确认（如周会）是一次谈话，而不是汇报（A做了什么B做了什么，这叫流水帐）或指示。
《OKR 工作法》
OKR 练习册

网易游戏 MySQL-MongoDB 运维及 DBA 招聘

2017-11-15T22:51:00+08:00

以下岗位部门均属于网易在线游戏事业部。其中 MongoDB 运维及运维开发工程师可选工作地点为广州或杭州。

相关数据库产品均服务于如《荒野行动》、《梦幻西游》、《大话西游》、《阴阳师》、《我的世界》、CC等网易游戏海量用户业务。如果需要也有更深入了解的，也可以给我留言或者微信（二维码戳我）私我。同时欢迎推荐及转发。

岗位一：MySQL DBA 点我投递简历

工作职责

参与内部MySQL SaaS开发和维护工作；
优化数据库，提高数据处理效率；
负责数据库新技术的调研和测试；
负责处理故障，服务请求，运维环境优化；
和开发团队及其他部门进行沟通协作。

职位要求

精通MySQL等数据库系统使用，精通SQL语句和优化；
熟悉Linux系统操作；
了解网络，有一定的故障排查和处理能力；
熟悉shell脚本编程，会Python、Java者优先；
有大型数据库和大规模服务器管理经验优先；

岗位二：MongoDB 运维工程师点我投递简历

职位描述：

负责 MongoDB 等数据库平台的配置管理、流程管理；
响应用户需求，提供协助或技术解决方案，配合业务完成数据库集群的部署、升级、扩容、缩容等；
通过全方位、立体化监控系统快速发现和处理故障；
配合优化数据库服务运维规范、工作流程、应急预案等，确保任何突发情况都能高效响应；
汇总用户需求，并设计技术需求方案，促进产品发展；

职位要求：

熟悉 Linux 系统以及工具命令等使用，熟悉主流开源软件的配置及调优，有底层基础技术研发经历的优先；
熟悉至少一种程序设计语言，有 Shell、Python 等脚本编程语言经验者优先；
对计算机硬件设备、网络设备有一定了解，熟悉 TCP/IP 以及具有丰富的网络知识；
熟悉 MongoDB 数据库的日常使用；
掌握 MongoDB 的管理及构建，包括但不限于集群构建、性能调优、备份恢复；
具备良好的沟通表达能力和服务意识，较强的团队合作意识，快速处理突发事件的能力；
有大型 MongoDB 商用部署实施及运营经验者优先，有 OCP 认证者优先。

岗位三：运维开发工程师（数据库平台）点我投递简历

职位描述：

负责内部数据库相关产品的管理平台、自动化流程开发工作；
与产品、PM、运维同学协作，积极高效推动产品开发；
与用户及其他部门进行沟通协作；

职位要求：

1 年或以上前后端开发工作经验；
对开发有浓厚兴趣，HTML/CSS/JS 基础扎实，熟悉Angulajs、Reactjs、Vue.js等MVVM框架中的一种；
有至少一种 server 端开发经验，熟悉 Python、PHP 语言开发者优先；
至少一种熟悉Web开发框架（如Django/Flask/Tornado）；
对 HTTP 协议、网页性能优化有一定的理解；
熟悉 MySQL、MongoDB、Redis 等数据库应用开发优先；
能够编写高扩展、易维护的代码，熟练且规范使用代码管理工具；

岗位四：高级运维工程师（DNS方向）点我投递简历

职位描述：

负责 DNS 及配套系统部署、维护及运维环境、服务优化；
日常系统运维、服务请求、故障处理等技术支持；
网络、系统等维护配套系统部署、维护；
和项目开发团队及其他部门进行沟通协作；
负责新技术的调研和测试。

职位要求：

熟悉 Linux 系统操作；
熟悉 shell 脚本语言编程，会 Python 者优先；
了解 TCP/IP 网络，有一定的故障排查和处理能力；
熟悉 DNS 协议、BIND，有相关运维经验，并能够快速实施部署、配置和排障；

LXC 如何找出容器对应的 veth 设备

2017-03-29T11:42:00+08:00

LXC 使用 veth 模式时，如果宿主机上创建了很多容器，那么宿主上将存在大量的 vethXXXX 设备，肉眼难以直接确认每个虚拟容器使用的是哪个 veth 设备。

在我的记忆中，方法比较复杂，且之前忘了记录下来，已经遗忘。今天重新尝试使用另一方法获取匹配信息，这里做下记录：

虚拟机（容器）执行 ethtool -S eth0 拿到如 peer_ifindex: 16，其中 eth0 为在虚拟机（容器）内对应的设备名称；
宿主机执行：ip link show | grep '^16:'，其中 16 为第一步拿到的 peer_ifindex，通过该命令拿到的 vethXXXX 即为虚拟机（容器）使用的设备。

记一次 Apache 性能调优

2017-03-23T09:44:00+08:00

手上有一组 web 服务，使用 apache 对外提供服务，其中apache 使用 worker 模式，这堆 web 服务器有以下一堆毛病：

apache 长期占用大量 CPU，负载长期居高不下。
每天 rotate log 的指令不能被 apache 处理，通过 lsof 可以看到被删除的日志文件没有正确关闭。

通过监控、日志统计，发现 qps 并不高，单台机器 qps 为600 左右（机器为 16 核、32G 内存），一开始以为是我代码性能问题，各种查找高消耗节点，无果。再次对服务器的整体情况及 apache 文档进行审视。

通过阅读 apache 官方文档在 worker 这里最重要的三个设置参数有 ServerLimit * ThreadsPerChild >= MaxClients ，但我们服务器上的配置远大于 qps（理论上，实际并发数会小于 qps）。尝试调小以上参数以接近 qps 数值，服务器负载没有发生明显变化。

再次观察系统负载（top）发现，apache 进程的 pid 一直在产生变化，产生了新的怀疑，是不是因为「频繁的销毁、创建 apache 进程」导致的开销过大，造成 cpu 负载居高不下？

再次阅读文档，其中两个会导致进程销毁的设置分别为：

MaxRequestsPerChild

The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is 0, then the process will never expire.

这个值，我们的设置是 0，所以不会是因为这个设置导致的。

MaxSpareThreads

For worker, the default is MaxSpareThreads 250. These MPMs deal with idle threads on a server-wide basis. If there are too many idle threads in the server then child processes are killed until the number of idle threads is less than this number.

我们原来的值设置为 75，怀疑是因为这个值设得太小了，尝试将此值调整至与 MaxClients 相等，重启 apache ，发现负载开始持续下降，top 中 apache 进程 pid 几乎没有产生变化，服务正常，qps没有明显下降（未导致服务不可用）。新的配置如：

<IfModule mpm_worker_module>
    StartServers          2
    ServerLimit          12
    MinSpareThreads      25
    MaxSpareThreads     768
    ThreadLimit         128
    ThreadsPerChild      64
    MaxClients          768
    MaxRequestsPerChild   0
</IfModule>

至此问题解决，附优化前后的负载对比图：

优化前：

优化后：

pip 升级 pip 失败

2016-05-19T12:11:00+08:00

今天在使用 python pip 安装一个 python 包的时候，一直提示：

# pip install --upgrade pip
Requirement already up-to-date: pip in /usr/local/lib/python2.7/dist-packages
You are using pip version 8.1.1, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

尝试按说明执行 pip install --upgrade pip ，没有任何报错，但一直升级不成功，百思不得解，在查看 man pip 的时候，找到如下选项：

-v, --verbose
    Give more output. Option is additive, and can be used up to 3 times.

尝试执行 pip install --upgrade pip -vvv 终于有更多提示：

1 location(s) to search for versions of pip:
* http://example.url/simple/pip/
Getting page http://example.url/simple/pip/
Starting new HTTP connection (1): example.url
"GET /simple/pip/ HTTP/1.1" 403 247
Could not fetch URL http://example.url/simple/pip/: 403 Client Error: Forbidden for url: http://example.url/simple/pip/ - skipping
Installed version (8.1.2) is most up-to-date (past versions: none)
Requirement already up-to-date: pip in /usr/local/lib/python2.7/dist-packages/pip-8.1.2-py2.7.egg
Cleaning up...

这时才发现，原来在我的 ~/.pip/pip.conf 配置文件里，index-url 使用了一个已经废弃的地址，删除文件后重新升级，一切恢复正常。

这么重要的 debug 信息，pip 默认竟然不输出，继续百思不得其解。:-)

Mac OSX Yosemite 10.10 WIFI 掉线修复

2014-11-17T14:35:00+08:00

原先用的是 Mac Air 11，通过Time Machine迁移至 Mac Retina 13，最后升级成 Yosemite 10.10 的，系统已经用了一段时间的，最近才忽然出出WIFI掉线的问题。

而且此掉线比较奇怪，WIFI Connection正常，TCP/UDP/ICMP包均不正常，并且我试过在ping/safari/ssh等均异常的情况下，我某正在下载内容的应用（genymotion），却坚持到了最后，并成功下载完了近200M的内容，所以基本排除了无线路由的问题。

重启电脑无效，网上搜到这么一编文章：别忙升级，苹果 Yosemite 频现 WiFi 断线综合症

虽然前面两种方法无效，但第三种方法还是给了我启示的，凭直接猜测应该是：

/Library/Preferences/SystemConfiguration

这个目录，进行这个目录，果然看到一堆与wifi关键字的文件：

$ ls
NetworkInterfaces.plist             com.apple.smb.server.plist
com.apple.airport.preferences.plist com.apple.wifi.message-tracer.plist
com.apple.captive.probe.plist       preferences.plist

把这些文件删掉（我是先备份了一下的，建议你也这样做），重启Mac。注意本次重启，是不会自动连上之前使用的wifi的，需要自己去点击连接一下，然后问题就解决了。

后来在网上看到 Fix Wi-Fi Problems in OS X Yosemite 这编文章，其实只要删除：

com.apple.airport.preferences.plist
com.apple.network.identification.plist
com.apple.wifi.message-tracer.plist 
NetworkInterfaces.plist 
preferences.plist

这些文件就可以了，解释也很到位，比oschina那个靠谱多了。:-)

2014-11-18 昨天折腾完，今天收到Apple Store的更新提醒，10.10.1 fix了wifi这个问题了

查询 dns server 使用的bind版本

2014-07-07T20:21:00+08:00

其实命令很简单，但我发现我老记不住，所以做个记录吧（我总是把version.bind记成bind.version，orz）

 dig @${server} TXT CHAOS version.bind

${server}换成你想查询的dns服务器IP地址即可，如：

dig @8.8.8.8 CHAOS TXT version.bind

其实通常情况下出于安全考虑，大多数我们是查询不到版本信息的（系统管理员禁用了）

bind 可以通过如下设置禁用版本号查询：

options {
    version none;
}

或者你可以将此值设置为某个固定字符串，如 "someone like you"

crontab 同时显式指定day of month和day of week的特殊说明

2014-05-09T13:31:00+08:00

man 5 crontab:

           field         allowed values
           -----         --------------
           minute        0-59
           hour          0-23
           day of month  1-31
           month         1-12 (or names, see below)
           day of week   0-7 (0 or 7 is Sun, or use names)

Note: The day of a command's execution can be specified by two fields -- day of month, and day of week. If both fields are restricted (ie, are not *), the command will be run when either field matches the current time. For example, ''30 4 1,15 * 5'' would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Fri-day.

来自wikipedia的说明（http://en.wikipedia.org/wiki/Crontab）：

While normally the job is executed when the time/date specification fields all match the current time and date,
there is one exception: if both "day of month" and "day of week" are restricted (not "*"),
then either the "day of month" field (3) or the "day of week" field (5) must match the current day.

以设置crontab： 11 14 27 3 3 为例，下面两个类型的时间都能满足该表达式：

3月里的每一个周三
3月27日

Linux系统上通知网关更新arp

2014-03-19T16:02:00+08:00

经常会有在线更换Linux服务器IP的操作，该操作带来的一个问题是: 我们已经执行了修改IP的操作，但由于网络上（网关）的ARP缓存暂未更新，导致在某一段时间内，该服务器会有网络不通的情况存在。

因此，我们需要在变更IP的同时，通知网关刷新ARP缓存。

首先清除本地ARP缓存:

/bin/ip neigh flush dev eth0

其次向网关发送本机的ip/mac地址

/usr/sbin/arping -v -c 2 -S 1.1.1.144 -s 00:17:a4:8d:0e:98 -p 1.1.1.1

1.1.1.144 为本机IP

00:17:a4:8d:0e:98 为本机MAC地址

1.1.1.1 为网关

Java 发起Http Post请求

2014-02-19T17:16:00+08:00

对于一个 Java 小白，每完成一个新的功能，都表示相当不易，就连 Apache HttpClient 偶都表示没搞明白，看起来好像不同版本还有不同的方法，没办法，还是借助于 Google，拼凑出了这一段代码，记录以备自己后用。

功能：使用 http post 方式访问某使用了 CNNIC 证书的站点（cnnic，唉，好多不信任）

/*
 * Java POST Example
 */

import java.io.IOException;
import java.net.MalformedURLException;
import java.net.ProtocolException;
import java.net.URL;
import java.net.URLEncoder;
import java.io.DataOutputStream;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.logging.Level;
import java.util.logging.Logger;

import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.security.KeyStore;


import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocketFactory;

/**
 *
 * @author Greg （原链接：http://sigterm.sh/2009/10/simple-post-in-java/）
 */
public class SimpleHttpPost {

    /**
     * Pretend you're a script...
     */
    public static void main(String[] args) throws Exception {
        URL url = null;

        /* 加载CNNIC证书开始 */

        X509TrustManager sunJSSEX509TrustManager;
        // 加载 Keytool 生成的证书文件
        char[] passphrase;
        String p = "changeit";
        passphrase = p.toCharArray();
        File file = new File("java.cnnic.cacert");
        System.out.println("Loading KeyStore " + file + "...");
        InputStream in = new FileInputStream(file);
        KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
        ks.load(in, passphrase);
        in.close();

        // 构造 javax.net.ssl.TrustManager 对象
        TrustManagerFactory tmf =
        TrustManagerFactory.getInstance("SunX509", "SunJSSE");
        tmf.init(ks);
        TrustManager tms [] = tmf.getTrustManagers();

        // 使用构造好的 TrustManager 访问相应的 https 站点
        SSLContext sslContext = SSLContext.getInstance("SSL", "SunJSSE");
        sslContext.init(null, tms, new java.security.SecureRandom());
        SSLSocketFactory ssf = sslContext.getSocketFactory();

        /* 加载CNNIC证书结束 */
        try {
            url = new URL("https://demo.site.url/uri/");
        } catch (MalformedURLException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        HttpsURLConnection urlConn = null;
        try {
            // URL connection channel.
            urlConn = (HttpsURLConnection) url.openConnection();
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        // Let the conn use SSL
        urlConn.setSSLSocketFactory(ssf);
        // Let the run-time system (RTS) know that we want input.
        urlConn.setDoInput (true);

        // Let the RTS know that we want to do output.
        urlConn.setDoOutput (true);

        // No caching, we want the real thing.
        urlConn.setUseCaches (false);

        try {
            urlConn.setRequestMethod("POST");
        } catch (ProtocolException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        try {
            urlConn.connect();
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        DataOutputStream output = null;
        BufferedReader input = null;

        try {
            output = new DataOutputStream(urlConn.getOutputStream());
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        // Specify the content type if needed.
        //urlConn.setRequestProperty("Content-Type",
        //  "application/x-www-form-urlencoded");

        // Construct the POST data.
        String content =
          "username=" + "randomuser" +
          "&password=" + "wrongmd5string";

        // Send the request data.
        try {
            output.writeBytes(content);
            output.flush();
            output.close();
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }

        // Get response data.
        String str = null;
        try {
            input = new BufferedReader(new InputStreamReader(urlConn.getInputStream()));
            while (null != ((str = input.readLine()))) {
                System.out.println(str);
            }
            input.close ();
        } catch (IOException ex) {
            Logger.getLogger(SimpleHttpPost.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

Java 使用自签证书访问https站点

2013-12-26T10:18:00+08:00

最近被 Java 使用自签证书访问 https 的问题折腾得体无完肤，做为一名 Java 小白，我也忍不住想感慨一下，不同 Java 程序员的水平差别真的好大，有些根本无法沟通，都不知道他们怎么胜任日常的编码工作的=,= 同时做为一个 Java 黑，我觉得，好吧，更黑了。。

anyway，经过各种折腾，至少总结出了以下两种使用自签证书访问 https 站点的办法。

方法一

拿到相应的 https 站点证书后（好吧，我这里是cnnic.crt，顺便吐槽一下万恶的 cnnic 证书，各种不信任）：

keytool -import -alias ${alias} -keystore ${JAVA_HOME}/jre/lib/security/cacerts -file ${path-to-certificate-file}

其中

${alias} 请替换为你想使用的名称，比如我这里是 CNNIC
${JAVA_HOME} 请替换为你自己的 JAVA_HOME 目录，比如我这里是 /usr/lib/jvm/java-6-openjdk
${path-to-certificate-file} 请替换为你的ca证书路径，比如我这里就是当前目录的 cnnic.crt

那么，我需要完整执行的命令就是：

keytool -import -alias CNNIC -keystore /usr/lib/jvm/java-6-openjdk/jre/lib/security/cacerts -file cnnic.crt

如果 keytool 要求你输入密码，在你没有变更过的情况下，该值默认为英文 changeit 。

方法二

有些同学表示，他们的服务器不允许导入证书，或者他们是一个很大的集群，不适合每台都导入，那怎么办呢？方法就是在每次访问的时候，程序自己加载相应的证书，但是在加载证书之前，你还是需要使用 keytool 工具将原ca转换成 Java 可以读取的证书格式，命令同方法一，只是 keystore 的位置你可以放在你的程序可以读取的任一路径，如我这里：

keytool -import -alias CNNIC -keystore java.cnnic.cacert -file cnnic.crt

之后在你的 Java 程序里，使用 keystore 加载该证书，并附加该证书创建 https 请求即可。

从 Java 官方 docs 和网上拼凑了小样例一枚，请君参照并自行完善：

import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.security.KeyStore;


import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import java.net.URL;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocketFactory;

public class LoadCert {
    public static void main(String[] args) throws Exception {

        X509TrustManager sunJSSEX509TrustManager;
        // 加载 Keytool 生成的证书文件
        char[] passphrase;
        String p = "changeit";
        passphrase = p.toCharArray();
        File file = new File("java.cnnic.cacert");
        System.out.println("Loading KeyStore " + file + "...");
        InputStream in = new FileInputStream(file);
        KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
        ks.load(in, passphrase);
        in.close();
        // 构造 javax.net.ssl.TrustManager 对象
        TrustManagerFactory tmf =
        TrustManagerFactory.getInstance("SunX509", "SunJSSE");
        tmf.init(ks);
        TrustManager tms [] = tmf.getTrustManagers();
        // 使用构造好的 TrustManager 访问相应的 https 站点
        SSLContext sslContext = SSLContext.getInstance("SSL", "SunJSSE");
        sslContext.init(null, tms, new java.security.SecureRandom());
        SSLSocketFactory ssf = sslContext.getSocketFactory();
        URL myURL = new URL("https://replace.to.your.site.real.url/");
        HttpsURLConnection httpsConn = (HttpsURLConnection) myURL.openConnection();
        httpsConn.setSSLSocketFactory(ssf);
        InputStreamReader insr = new InputStreamReader(httpsConn.getInputStream());
        int respInt = insr.read();
        while (respInt != -1) {
            System.out.print((char) respInt);
            respInt = insr.read();
        }
    }
}

OpenID4Java 使用dumb模式（stateless）并禁用 discovery

2013-12-25T12:20:00+08:00

使用无状态模式（dumb mode/stateless）发起 OpenID 认证请求：

manager = new ConsumerManager();
manager.getRealmVerifier().setEnforceRpId(false);
// 强制manager使用无状态模式
manager.setMaxAssocAttempts(0);

禁用 discovery

// 不要使用manager.discover构造discoveries
// List discoveries = manager.discover(userSuppliedString);
// 使用人肉构造discoveries
List discoveries = new ArrayList();
discoveries.add( new DiscoveryInformation( new URL("http//real.openid.server.url") ) );

ssh client 通过 socks5 proxy 登录远程服务器

2013-12-20T12:20:00+08:00

今天某同学需要登录某国家服务器（A），但从我朝过去网络延时非常大发现从岛国过去的速度相当快，但因为岛国的服务器（B）不适合加该同学的帐号因此做了一个 socks5 proxy ，然后本地 ssh client 通过该 proxy 登录A服务器

ssh -o ProxyCommand='nc -x ${proxy_server}:${proxy_server_port} %h %p' xxx.xxx.xxx.xxx

如：

ssh -o ProxyCommand='nc -x 127.0.0.1:7070 %h %p' 8.8.8.8

需要注意的是，nc需要使用 OpenBSD 版本，非 Linux 默认版本（该版本不支持）通常，类 Debian 的衍生版本，都可以通过如下命令直接安装：

apt-get install netcat-openbsd

非OpenBSD 可能报如下错误：

/bin/nc: invalid option -- 'x'

Mac OSX iTerm2 终端UTF-8和GBK编码自由切换

2013-10-29T16:43:00+08:00

老树使用的是Mac OSX系统，平时终端都是使用iTerm2替代默认的Terminal进行使用。

考虑到各种兼容性，个人一直使用的是UTF-8编码，但由于老树管理着大量服务器，并且可能使用的是GBK或者其它编码，经常由于终端环境编码的不同，导致登录服务器出现乱码，或者需要处理GBK文件时，要使用iconv进行多次编码转换，相当麻烦。

好在iTerm2使用了比较友好的Profile配置及切换方式，首先我的默认配置（Default Profile）使用了UTF-8编码：

我另外建立了一个Profile，叫GBK：

并编写了一个非常简单的切换脚本：

#!/bin/bash
# 使用GBK Profile
echo -e "\033]50;SetProfile=GBK\a"
# 环境编码切换为GBK
export LANG=zh_CN.GBK
export LC_ALL=zh_CN.GBK
# 更改当前 iTerm2 tab title
echo -ne "\033]0;"$@"\007"
$@
echo -ne "\033]0;"${PWD/#$HOME/~}"\007"
# GBK任务完成后，自动切换回默认编码（UTF-8）
echo -e "\033]50;SetProfile=Default\a"
export LANG=zh_CN.UTF-8
export LC_ALL=zh_CN.UTF-8

将以上内容保存为一个叫grun的文件，并赋予可执行权限，同时加到系统可执行目录（PATH）

当我需要登录一台GBK编码的服务器时，只需要

grun ssh ${hostname}

即可

sshd无法使用secureFX传输文件

2013-09-24T15:58:00+08:00

某同学表示，某些机器无法使用secureFX进行文件传输。

正常情况下：

i RECV : AUTH_SUCCESS
i RECV : Server Sftp Version: 3
i SEND : RealPath(raw) .
i Resolved RealPath: /home/demo
i SEND : OpenDir /home/demo

而无法传输文件的服务器则是如下日志：

i RECV : AUTH_SUCCESS
i Changing state from STATE_CONNECTION to   STATE_TRANSPORT_STOPPING.
i Changing state from STATE_TRANSPORT_STOPPING to STATE_CLOSING.
i Changing state from STATE_CLOSING to STATE_CLOSED.

查看/etc/ssh/sshd_config配置，发现缺少sftp的相关配置，在该配置文件中增加：

Subsystem   sftp    /usr/libexec/openssh/sftp-server

然后重启sshd服务，问题解决。

Django Admin 使用 filter_horizontal 不生效

2013-09-23T15:25:00+08:00

考虑到Django 1.0.2 admin的功能实在太弱了，今天冒着大风险，将某系统的Django进行了升级（升级至Django 1.2.7）。

Django 1.2.7 admin在使用ManyToManyField的时候，默认使用垂直filter_vertical方式进行显示与选择。此方式在选项比较多的时候，难以直观的看出哪些选项被选中，如下图所示：

决定使用更直观的方式，filter_horizontal，设置比较简单，只要在admin.py里对应的模块下，添加类似如下内容即可：

filter_horizontal = ['example']

filter_horizontal显示方式如下图所示：

但是，当我设置了此选择后，发现出现了奇怪的问题，如下图：

没有报错，但也没有出现设想中的选择框。经过研究，发现，原来是因为我对应的字段ips，在models.py里定义的时候，verbose_name使用了字符串，而不是unicode，如下：

ips = models.ManyToManyField( IPData, verbose_name = "使用IP" )

调整为

ips = models.ManyToManyField( IPData, verbose_name = u"使用IP" )

问题解决。使用string是因为我们这些是一些老旧的系统，新项目必须果断的抛弃string，拥抱unicode吧！

pelican增加自定义jinja template filters

2013-09-11T19:46:00+08:00

pelican官方文档没有显式的指明应该如何自定义jinja template filters.

在制作标签云的时候，不想写复杂的javascript，更不想又import一份javascript进来，所以决定自己搞一个比较简单的标签云

pelican默认的tag排序比较简单，为了能有比较“云”的感觉，决定对tag加个随机排序

查了Jinja的文档，没有随机排序的filter。由于我使用了virtualenv，所以最简单粗暴的解决方案是直接修改了Jinja的源码，添加了随机排序的功能

不过对于稍微有些“洁癖”的好，这样改后，心理上非常难受，决定到pelican社区，看看是否有幸添加个patch

当然，更幸运的是在github找到了此commit:

https://github.com/getpelican/pelican/pull/96

原来有个JINJA_FILTERS的设置，那一切就好办了, 增加自定义模块jinja_filters.py

import random

def shuffle( value ):
    """ Jinja template filter for shuffling list/tuple """
    if not isinstance( value, list
            ) and not isinstance( value, tuple ):
        return value
    random.shuffle( value )
    return value

在pelican配置文件里填加:

from jinja_filters import shuffle

JINJA_FILTERS = { 'shuffle' : shuffle }

尝试重新编译生成html文件，顺利完成。

配置Bind使用MySQL dlz模式

2013-09-09T16:18:00+08:00

** 安装MySQL/Bind with dlz **

略过，bind dlz安装，只需在编译的时候增加 --with-dlz-mysql 选项即可。

** 创建 MySQL 数据库 **

根据自己的需求创建即可，如使用如下命令创建一个名为 dns 的数据库：

CREATE DATABASE dns DEFAULT CHARSET UTF8;

使用 use dns 切换进 dns 数据库后，使用如下命令创建一张 dns_records 表：

CREATE TABLE `dns_records` (
`zone` varchar(255) NOT NULL,
`host` varchar(255) NOT NULL,
`type` varchar(12) NOT NULL,
`data` varchar(255) NOT NULL,
`ttl` int(11) DEFAULT '600',
`id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

这里以域 example.com 为例，说明如上字段意义，假设我需要有一条 www.example.com 的记录指向 1.1.1.1 这个IP，应该增加哪些内容：

zone:

域，这里指 example.com

host:

主机名（名字），这里为 www

type:

记录类型，这里为A

data:

域名资源数据，这里为IP地址 1.1.1.1

ttl:

域名TTL，为任意整数（建议不要低于120，即2分钟）

将该数据库授权给某用户（后续bind-dlz配置需要用到）：

grant select on dns.* to dns@localhost identified by 'dns';

用户名为 dns ，密码也为 dns ，只允许本地主机 localhost 访问，并只给予了 select 权限。

** Bind-dlz配置 **

这里只涉及dlz的配置，其它named.conf的配置不涉及

dlz "your custom description" {
    database "mysql
        {host=localhost dbname=dns user=dns pass=dns}
        {select zone from dns_records where zone = '$zone$'}
        {select ttl, type, data from dns_records where host = '$record$' and zone='$zone$'}";
};

your custom description:

管理员自行添加的描述

配置完成。

Django multiple select option with title

2013-09-09T15:02:00+08:00

from django import forms
from django.utils.encoding import force_unicode
from django.utils.html import escape, conditional_escape

class SelectMultipleWithTitle(forms.SelectMultiple):
    """ multiple select optihon with title """
    def render_option(self, selected_choices, option_value, option_label):
        option_value = force_unicode(option_value)
        selected_html = (option_value in selected_choices) and u' selected="selected"' or ''
        return u'<option value="%s"%s title="%s">%s</option>' % (
            escape(option_value), selected_html,
            conditional_escape(force_unicode(option_label)),
            conditional_escape(force_unicode(option_label)))

install Facebook scribe on Debian Squeeze

2013-09-08T13:03:00+08:00

系统:

Debian Squeeze 6.0 amd64

thrift: 0.8.0

hadoop: 0.20.2 cdh3 hadoop-0.20_0.20.2+923.142

scribe: git current version

首先安装各种库，包括但不局限于:

python-dev maven2 ant sun-java6-jre sun-java6-jdk bison flex gcc make autoconf libevent-dev libboost-all-dev git-core

之后:

sudo update-alternatives --set java /usr/lib/jvm/java-6-sun/jre/bin/java #确保使用的不是openjdk

安装thrift:

tar -zxvf thrift-0.8.0.tar.gz

cd thrift-0.8.0

./configure --prefix=/usr/local/thrift-0.8.0

make

sudo make install

安装fb303:

cd thrift-0.8.0/contrib/fb303

sh boostrap.sh

./configure --prefix=/usr/local/fb303-0.8.0 --with-thriftpath=/usr/local/thrift-0.8.0 CPPFLAGS="-DHAVE_INTTYPES_H -DHAVE_NETINET_IN_H"

make

sudo make install

安装hadoop:

使用apache官方下载的版本编译各种不成功，其中一个错误（编译scribe时出现）:

HdfsFile.cpp:255: error: ‘hdfsConnectNewInstance’ was not declared in this scope

ConnectNewInstance是在hadoop 0.21之后的版本才出现的，由于我这边hadoop的服务器是0.20.2，所以只能使用cloudarea版本

由于我在在编译时，cloudarea页面无法下载对应版本hadoop(或者跳转到apache页面)

只好使用如下方式进行下载，首先，修改/etc/apt/source.list，增加

deb http://archive.cloudera.com/debian squeeze-cdh3u2 contrib

deb-src http://archive.cloudera.com/debian squeeze-cdh3u2 contrib

然后使用apt-get source hadoop-0.20进行下载

tar -zxvf hadoop-0.20.2.tar.gz

mv hadoop-0.20.2 /usr/local

cd /usr/local/hadoop-0.20.2

sudo ant compile-c++-libhdfs -Dislibhdfs=true #由于cdh3/apache提供的hadoop包内的libhdfs库不一定能使用，重新编译c++的libhdfs库

安装scribe:

git clone https://github.com/facebook/scribe.git

cd scribe

sh bootstrap.sh

./configure --prefix=/usr/local/scribe-2.2 --with-fb303path=/usr/local/fb303-0.8.0 --with-thriftpath=/usr/local/thrift-0.8.0 --with-hadooppath=/usr/local/hadoop-0.20.2 --enable-hdfs CPPFLAGS="-DHAVE_NETDB_H=1 -fpermissive -DHAVE_INTTYPES_H -DHAVE_NETINET_IN_H -I/usr/local/hadoop-0.20.2/src/c++/libhdfs -I/usr/lib/jvm/java-6-sun-1.6.0.26/include -I/usr/lib/jvm/java-6-sun-1.6.0.26/include/linux" LDFLAGS="-L/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64 -L/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/server -L/usr/local/hadoop-0.20.2/build/c++/Linux-amd64-64/lib"

make

sudo make install

其它配置:

由于我这里各软件包都是自定义安装路径，需要配置一下ld加载路径，编辑(增加) /etc/ld.so.conf.d/scribe.conf

/usr/local/thrift-0.8.0/lib/

/usr/local/hadoop-0.20.2/build/c++/Linux-amd64-64/lib/

/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/server/

保存退出后

sudo ldconfig

Windows OpenVPN GUI记住用户名和密码

2013-09-08T12:51:00+08:00

日常工作中经常使用VPN，由于Server端要求进行用户名和密码校验，在第一次链接的时候，OpenVPN Client会弹出输入用户名和密码的窗口。

如果网络比较稳定的情况下，这个还没什么问题，网络不稳定的时候，每次弹开，都会弹出重新验证的窗口，加上我自己的密码比较长，不胜其烦

我使用的版本（2.3.1），实际上已经支持保存密码的功能（旧版本可能需要重新编译），在ovpn配置文件里增加:

auth-user-pass pass.txt

之后在ovpn配置文件所在目录建立一个pass.txt的文件，第一行为用户名，第二行为密码即可。

PS：这样对自己电脑的安全性要有足够的保证，否则密码泄露就得不偿失了。

Debian系统添加全局根证书（CNNIC）

2013-09-08T12:25:00+08:00

鉴于CNNIC的证书默认被不信任，导致了应用在访问某些使用cnnic证书的ssl站点时，请求失败。

虽然我也不喜欢cnnic，但没办法，这是反抗不了的事情。

过程如下（需要root权限）：

apt-get install ca-certificates #一般情况下应该是已经有安装的了

mkdir -p /usr/share/ca-certificates/local #建立local目录是为了方便区分这是自己填加的证书，可以自定义，但一定要在/usr/share/ca-certificates目录下

将cnnic的证书复制至/usr/share/ca-certificates/local目录，请注意，证书的后缀必须修改为.crt

dpkg-reconfigure ca-certificates #选中刚才添加的local/cnnic.crt证中，确定，即可

小生说大声讲

用 Hammerspoon 搞定远程锁屏与 SMB 动态挂载

01 我的双 Mac 工作流与两个真实痛点

痛点一：Mac mini 远程屏幕共享——「人在不锁，人走即锁」

痛点二：大文件跨机共享——告别 Git 冗余，动态挂载外挂盘

02 解决方案：Hammerspoon 小工具解决大问题

场景 1：精准控制 Mac mini 锁屏策略

场景 2：USB-C 直连 / Tailscale 多通道智能挂载

03 总结与体会

上下文、压缩与缓存：大模型使用者必须搞懂的三个概念

0. 先给一个心智模型

1. 上下文（Context Window）

1.1 官方定义

1.2 所以"100 万上下文"到底指什么

1.3 关键推论：模型是无状态的，每轮都在重发全部历史

1.4 Context Rot：为什么"塞满"是个坏主意

1.5 当前主流模型的窗口大小

1.6 窗口满了会发生什么（API 层面）

1.7 一个容易被忽略的机制：Context Awareness

1.8 Extended Thinking 与窗口的关系

2. 压缩（Compaction）

2.1 什么情况下应该压缩

2.2 压缩的通用流程

2.3 Claude：官方 API 的服务端压缩

2.4 Claude：更精细的替代方案——Context Editing

2.5 Claude Code：自动压缩的实际行为

2.6 Codex：压缩机制与配置

2.7 压缩对本次 session / 任务的影响

3. 缓存（Prompt Caching）

3.1 什么是缓存

3.2 缓存命中率

3.3 计费影响：缓存到底省多少

3.4 计费之外：缓存失效还影响延迟

3.5 什么情况下缓存会失效

（A）API 层面的失效规则

（B）Claude Code 层面的失效规则

（C）Claude Code 的缓存生命周期（TTL）

（D）Claude Code 的缓存作用域（容易踩坑）

3.6 OpenAI / Codex 的缓存管理

4. 三者的相互作用

5. 日常实践：怎么用好一个 session

5.1 会话开始时（决定了后面 80% 的效率）

5.2 会话进行中

5.3 关于休息和恢复

5.4 关于目录（容易忽略的一条）

5.5 健康度自检

6. 速查表

压缩阈值

缓存 TTL

相关环境变量（Claude Code）

一句话记忆

参考文档

Skill、Subagent 与 Agent 究竟是什么？从一个月度总结实战谈 AI 原生架构

一、 形象比喻：企业团队的运作模型

二、 真实需求场景：每月仓库变化统计与月报生成

为什么单纯靠“主 Agent + 提示词”很笨重？

三、 架构设计与落地实现

1. 第一步：打造 Skill（静态 SOP 与工具箱）

2. 第二步：定义并派生 Subagent（动态分析员工）

3. 第三步：生成结构化月度报告

四、 核心追问：Subagent 究竟保存在哪里？

1. 运行态实体 (Runtime Entity)

2. 配置与定义持久化 (Persistence)

五、 工程总结：何时用 Skill？何时用 Subagent？

CPU、GPU、TPU 到底谁更“聪明”？从逻辑运算到光互连，一篇看懂 AI Infra

一、先把三兄弟放在一张表里

二、三种芯片，三种花钱方式

CPU：为“不可预测”买单

GPU：用人海掩盖等待

TPU：为“确定性”重排一切

边界正在互相渗透

三、AI 负载长什么样

主体是矩阵乘法

精度是第二根杠杆

三种执行模型

四、真正的主角：内存墙

Roofline：一道除法看穿性能

从一颗芯片到一座集群

五、“GPU 逻辑不强”，对，也不对

论位运算和整数，GPU 不弱，甚至很强

一、形象比喻：企业团队的运作模型

二、真实需求场景：每月仓库变化统计与月报生成

三、架构设计与落地实现

四、核心追问：Subagent 究竟保存在哪里？

五、工程总结：何时用 Skill？何时用 Subagent？

坑一：`swift run` 启动后，窗口躲到了别人后面