一个准备开源的小工具仓库，历史提交里的一行注释残留着开发机绝对路径（形如 D:\某目录\...）。当前文件早已清干净，直到有人把某个历史 commit 的链接发来，才发现历史里 5 个 commit 仍带着它——改文件根本改不到历史。本文记录 git filter-repo 全历史改写、逐提交重签 GPG、强推，以及最终删库重建的完整过程。结论先说：改写历史不等于清除历史，公开平台会缓存不可达对象；防再犯要靠提交前的自动门禁。适用环境 Windows 11 + Git for Windows（bash）+ Python 3.11，处理时间 2026-09-13。

一、症状与第一手数据

#

仓库公开后不久（2026-09-13），有人把某个历史提交的链接发给站主，问了一个问题：这个提交的修改记录里暴露了本机路径（可能之前的提交也有），有什么好的处理方法吗。

这个提交本身是一条「chore: 移除注释中的本机路径（脱敏）」。也就是说，最早发现泄漏后已经修过一轮：仓库公开前做最终审计时，在构建脚本 web/build_web.py 第 6 行抓到了泄漏——那行注释里直接写了开发机绝对路径（形如 D:\某目录\某仓库）。当时的处理是把注释改成「项目根目录」，提交（就是那条「脱敏」提交）、重打 tag、重建 Release——当前内容已经干净。但问题恰恰出在这次"修复"本身：它的 diff 显示的是被删除的那一行，而那一行里就是完整路径。任何人打开这个提交的页面都能看到路径；更糟的是，之前的提交里文件还带着它。

用一条命令把全历史每个提交的 tree 都扫一遍（关键词换成你自己的泄露特征词）：

for c in $(git rev-list --all); do
  hits=$(git grep -l -I -E "本地路径特征词|AppData|C:\\Users" $c -- 2>/dev/null)
  [ -n "$hits" ] && echo "$c $(git log -1 --format=%s $c): $hits"
done

结果很干净利落：泄漏只在一行注释里，且只出现在 5 个历史 commit（全部指向同一个文件 web/build_web.py）；提交信息本身没有任何痕迹。当时的提交顺序也印证了泄漏路径：最初的 feat 提交新增这一行，其后 4 个中间提交一直带着它，直到「脱敏」提交删除——删除只是最后一步，前 5 个版本里它一直在。全仓库当时共 7 个 commit、2 个 tag。

二、根因

#

Git 的提交是一个内容寻址链表：commit 对象指向 tree，tree 再指向每个文件的 blob。改掉当前文件再提交，只会在新 commit 里换上新 blob；历史上每一个旧 commit 仍指向自己那份旧内容。所以"文件已清理"和"历史已清理"是两回事。

第二个坑更隐蔽：“脱敏"提交本身把路径搬进了 diff。git 的提交记录是公开面的直接表达，任何一次提交的增删行都会永久展示；即使那条提交的目的是删除，被删除的原文也完整留在页面上。

还有一个教训：首轮修复时宣称"公开前做了最终 grep 复查”，但那次复查本质只扫了工作区/当前内容，没有遍历 git rev-list --all 的每一个提交。用 git grep 检查当前文件，是发现不了历史泄漏的。

三、处置过程（含走过的弯路）

#

1. 改写前先备份

#

用 git bundle 把全部 refs 打包成一份备份（改动前的历史以此为准），再装 git-filter-repo（pip 安装）。

git bundle create <备份路径> --all
python -m pip install git-filter-repo

注意：这份备份打包的是旧的、含路径的历史，它本身绝不能推出去，确认一切稳定后可删。

2. filter-repo 全历史替换

#

准备替换表，长串优先（避免短串先命中、长串匹配不到），把路径特征替换成无信息的占位注释：

D:\某目录\某仓库==>项目根目录
D:\某目录==>项目根目录

执行：

python -m git_filter_repo --replace-text 替换表.txt --force

实际输出：Parsed 7 commits，New history written in 0.31 seconds; now repacking/cleaning...，Completely finished after 0.72 seconds。对小型仓库，改写本身是秒级操作。替换表里的规则一长一短，正是为了先命中长串：若短串先匹配，长串会被截成残片，替换结果不干净。

一个值得注意的副产物：那条「移除注释中的本机路径」的提交，唯一改动就是删除路径行；替换后它的内容与父提交一致、diff 为空，被 git-filter-repo 自动当空提交清理（7→6 个提交）。“清路径"的提交从历史上消失了——这反而是好事，因为它不再作为"把路径亮出来"的页面存在。改写后全历史重扫应为空，两个 tag 按内容自动重指到改写后的对应提交。

3. 逐提交重新 GPG 签名

#

历史改写必然使所有提交哈希变化，GPG 签名（基于提交内容）全部失效，git log 里签名状态显示 N。用 rebase --root 对每个提交重新签名：

git rebase --root --exec 'git commit --amend --no-edit -S'

（gpg 不在 PATH 时，命令要加 -c gpg.program=<gpg 可执行文件路径>。）重签后全部提交显示 G（Verified）；两个 tag 用 -a -s 重新打签名，git tag -v 校验输出显示签名算法为 EDDSA，随后强推。

4. 上防再犯门禁：check_privacy.py + CI + pre-commit

#

趁历史改写完、还没推上去的窗口，写了一个不到 70 行的隐私检查脚本 scripts/check_privacy.py：遍历 git 跟踪文件（或只查暂存区），命中即退出码 1。规则如下：

脚本跳过二进制与图片后缀（.exe/.zip/.dll/.pyc/.png/.ico/.jpg 等）和自身；--staged 模式只扫暂存区（给 pre-commit 钩子用）。

全文如下，连同启用它的本地钩子一起（点开即可复制；只用 Python 标准库，无第三方依赖）：

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""隐私检查：扫描仓库跟踪的文件中是否残留本机绝对路径等痕迹。

CI（每次 push/PR）与本地 pre-commit 钩子共用；命中即退出码 1。
用法:
    python scripts/check_privacy.py            # 扫描 git 跟踪的全部文件
    python scripts/check_privacy.py --staged   # 只扫描暂存区（pre-commit 用）
"""
import re
import subprocess
import sys

for _s in (sys.stdout, sys.stderr):
    try:
        _s.reconfigure(encoding="utf-8", errors="replace")
    except Exception:
        pass

# 每条：正则、说明。注意 (?!...) 负向断言避免误伤 https:// 这类正常文本。
PATTERNS = [
    (re.compile(r"(?<![A-Za-z0-9])[A-Za-z]:[\\/]"), "Windows 绝对路径（如 C:\\ 或 F:/）"),
    (re.compile(r"AppData[\\/](?:Local|Roaming)"), "Windows 用户配置目录"),
    (re.compile(r"C:[\\/]Users[\\/]"), "Windows 用户目录"),
    (re.compile(r"/home/[A-Za-z0-9_.-]+/"), "Linux 家目录"),
    (re.compile(r"/Users/[A-Za-z0-9_.-]+/"), "macOS 家目录"),
    (re.compile(r"%LOCALAPPDATA%|%APPDATA%|%USERPROFILE%"), "本机环境变量路径"),
]

SKIP_FILES = {"scripts/check_privacy.py"}          # 本文件含规则字面量，跳过自身
SKIP_SUFFIX = (".ico", ".png", ".jpg", ".zip", ".exe", ".dll", ".pyc")


def tracked_files(staged):
    if staged:
        out = subprocess.run(["git", "diff", "--cached", "--name-only", "--diff-filter=ACM"],
                             capture_output=True, text=True, check=True).stdout
        return [p for p in out.splitlines() if p.strip()]
    out = subprocess.run(["git", "ls-files"], capture_output=True, text=True, check=True).stdout
    return [p for p in out.splitlines() if p.strip()]


def main():
    staged = "--staged" in sys.argv[1:]
    hits = []
    for path in tracked_files(staged):
        if path in SKIP_FILES or path.endswith(SKIP_SUFFIX):
            continue
        try:
            with open(path, encoding="utf-8", errors="ignore") as f:
                for lineno, line in enumerate(f, 1):
                    for rx, desc in PATTERNS:
                        m = rx.search(line)
                        if m:
                            hits.append((path, lineno, desc, m.group(0)))
        except (OSError, UnicodeError):
            continue
    if hits:
        print("✘ 检测到可能的隐私痕迹（本机路径），请脱敏后再提交：")
        for path, lineno, desc, frag in hits:
            print(f"  {path}:{lineno}  [{desc}] 命中：{frag}")
        print("\n提示：改用相对路径或占位符（如『项目根目录』『示例目录A』）。")
        return 1
    print("✓ 隐私检查通过：未发现本机绝对路径痕迹")
    return 0


if __name__ == "__main__":
    sys.exit(main())

#!/bin/sh
# 本地 pre-commit 钩子：提交前扫描暂存区是否含本机路径等隐私痕迹。
# 启用方式（仓库根目录执行一次）：
#   git config core.hooksPath scripts/hooks
python scripts/check_privacy.py --staged || {
    echo "提交被拦截：请先处理上述隐私痕迹（或临时用 git commit --no-verify 跳过）。"
    exit 1
}

上线第一天它就立了功：本地首跑立即命中 README.md:67——README 里演示命令行用法写的示例路径（形如 D:\某目录\...）被判为 Windows 绝对路径。演示路径虽是占位用途，但规则不留模糊地带：把示例改成无盘符的「目录A...」占位，提交通过。

门禁分两处挂上：

• CI：workflow 里在语法检查之后、内核一致性验收之前加一步 python scripts/check_privacy.py，每次 push 都跑，命中即失败；
• 本地：scripts/hooks/pre-commit 里跑 --staged 模式；在仓库根目录执行一次 git config core.hooksPath scripts/hooks 即生效。

5. 弯路：强推之后，旧 commit 依然可达

#

一切就绪后 git push --force origin main 与 git push --force origin --tags 强推。GitHub 侧确认远端 main 已换成干净历史（最新提交即门禁提交，状态 G），Release 完好。然后探测三个旧 SHA，结果如下：

这是本篇最值钱的一点：改写历史 ≠ 清除历史。force push 让旧对象在引用层面"不可达”，但公开平台会保留不可达对象一段时间（作为旧链接缓存），不会立即物理删除；被分享出去的旧 commit 链接，打开仍能看到那行路径和完整 diff。

6. 终局：删库重建

#

接受现状不符合"彻底清除"的目标（旧链接还挂着路径），于是选了最彻底也最省心的方案：删除仓库，同名重建。

gh repo delete <账号>/<仓库> --yes                # 删除
gh api repos/<账号>/<仓库>                        # 确认 404
gh repo create <账号>/<仓库> --public --source . --remote origin --push
git push origin --tags                            # 触发 tag 构建

执行要点：删除后先用 API 确认返回 404 再重建（同名）；重建后推 main 与两个 tag，同一刻三个 CI run（main 提交 + 两个 tag）排队构建，Release 由 tag 触发自动重建；顺手补上仓库描述与 9 个 topics。

四、验证

#

判定"解决"的标准是旧链接彻底失效：

• 删库重建后，三个旧 SHA 探测全部返回 HTTP 422 No commit found for SHA: ...（GitHub REST 对不存在的提交返回 422 而非 404）；当年被分享出去的那个链接也失效了；
• 新仓库为 PUBLIC，描述与 9 个 topics 就位；
• 3 个 CI run（main + 两个 tag）全部 success；两个 Release 由 tag 触发重建完毕，资产齐全（可执行程序、GUI 压缩包、网页版、SHA256SUMS 校验文件）；
• 远端 web/build_web.py 第 6 行确认为「项目根目录」，全历史零泄漏；
• 门禁提交在远端日志显示 G（Verified）。

怎么判断"没解决"：复制旧 commit 链接直接打开，还能看到 diff 和那行路径——说明不可达对象还活着。

五、留给后来者的清单

#

六、碎碎念

#

事后清理这一趟，成本不在改写本身（秒级），而在连锁动作：重签全部提交、重建 tag、删库重建、等 CI 重打 Release、一个个探测旧 SHA。而这一切的起因，只是提交时多写的一行注释，加一次只扫工作区、没扫历史的"复查"。

对开源仓库来说，历史就是公开面，任何一次提交都可能在未来某个时刻被人翻开。比事后清理便宜得多的做法，是让机器在提交发生前拦一道：一条正则、一个 CI 步骤、一个 pre-commit 钩子。最后再强调一遍备份的事：改写前的备份里还躺着那行旧路径，别把备份当成普通仓库推上去，确认干净稳定后记得删掉。

一台 512MB 的 Ubuntu 云主机（跑 sing-box 代理）某天突然"整机失联"：云控制台显示实例正在运行、静态 IP 没变，SSH、代理端口、云厂商的浏览器终端却全都不通，只有重启才恢复。一天之内，两台同配置的机器先后中招。根因不是网卡、不是运营商、也不是云厂商，而是无人值守自动更新（unattended-upgrades）把内存打满，全局 OOM 连带把负责网络配置的 systemd-networkd 拖进 Failed，默认路由与 DNS 随后消失——机器"活着但没网"。适用环境：Ubuntu 22.04 LTS（内核 6.8.0-1063-aws）、systemd-networkd、512MB 云主机，时间 2026-09-09 至 09-10。

一、症状与第一手数据

#

两台机在不到一天里先后病倒。本文主角（下称 A 机）于 2026-09-10 早晨 08:00（CST）前后失联；另一台同配置机器（下称 B 机）在约 19 小时前——09-09 06:18 UTC——以同样的链条先倒下，失联约 18 小时才被发现。

A 机失联时的观测数据：

• 云控制台：实例状态"正在运行"，静态 IP 未变；实例历史无任何停止/回收动作 → 云侧没动过它。
• 外部探测：SSH（非标准端口）与代理入站端口全部 TCP 超时、无 SYN-ACK（不是拒绝），ICMP 不通。
• 浏览器终端：报 UPSTREAM_ERROR [515]——云厂商会话管理 agent（SSM）连不上元数据服务 169.254.169.254，控制台通道本身也断了。
• 自建监控 agent 主动出站上报心跳，最后一次心跳 23:55:24 UTC。入站与出站同时中断 → 故障在整机/网络层，不在 sing-box 进程层。
• 对照：其余地域节点全部正常，云厂商状态页无对应事件 → 排除全局网络故障与区域事故。

排查期间还踩了个坑：本机经代理/TUN 测端口会"乐观握手"——本地应用立刻拿到 SYN-ACK，实际转发到上游才算成功，第一轮误报"已恢复"。改用两台异地干净观测点直连复测，才确认 09:13 控制台重启后 sing-box 09:13:52 自动拉起、监控 09:13:55 恢复上报，失联时长约 74 分钟。

重启后从前一次启动的 journal 里挖出完整的故障链日志：

# A 机（最后一段崩溃现场）
Sep 10 07:07:33 systemd-networkd[342]: ens5: Could not set route: Connection timed out
Sep 10 07:07:33 systemd-networkd[342]: ens5: Failed
Sep 10 07:08:13 kernel: oom-kill: ... global_oom, task_memcg=/system.slice/apt-daily-upgrade.service, task=unattended-upgr
Sep 10 07:08:13 kernel: Out of memory: Killed process 14467 (unattended-upgr) total-vm:469680kB, anon-rss:150328kB ... oom_score_adj:0
Sep 10 07:08:38 kernel: Out of memory: Killed process 14650 (unattended-upgr) anon-rss:163744kB
Sep 10 07:12:15 kernel: agent invoked oom-killer ... Out of memory: Killed process (unattended-upgr)
Sep 10 08:00:09 sing-box: ERROR router: missing default interface
Sep 10 08:00:23 agent: lookup <监控域名> on 127.0.0.53:53: server misbehaving
Sep 10 08:04:51 ssm-agent: 169.254.169.254 connect: network is unreachable
Sep 10 09:13:36 systemd[1]: systemd-networkd.service: Deactivated successfully.  ← 重启

# B 机（早 19 小时的同一套日志）
Sep 09 06:18:11 systemd-networkd[352]: eth0: Could not set route: Connection timed out
Sep 09 06:18:11 systemd-networkd[352]: eth0: Failed
Sep 09 06:18:11 kernel: Out of memory: Killed process 51149 (localedef) total-vm:127980kB, anon-rss:115752kB

两机同源：都是 512MB 内存、Swap: 0、日常 apt-daily-upgrade（unattended-upgrades）触发全局 OOM。B 机先倒、无人察觉；A 机随后复现，才把问题翻出来。

二、根因

#

链条是这样走的：

1. 内存被打满。512MB 实例、无 swap，日常占用已接近一半（journald 约 28MB、multipathd 约 27MB、sing-box 约 25MB、snapd 约 21MB，加 buff/cache 可用只剩约 200MB）。unattended-upgrades 升级时再吃 150MB+，内存耗尽。
2. 负责网络的服务先被拖死。内存耗尽后内核迟滞，systemd-networkd 执行设置路由的操作超时，报 Could not set route: Connection timed out 后进入 Failed 状态——它一死，DHCP 租约不再续期。
3. OOM killer 动手，但为时已晚。全局 OOM 触发，被杀的是 unattended-upgr（150MB）和 localedef（115MB）这类升级进程；此时 networkd 已死，路由/DNS 只是时间问题。约 53 分钟后默认路由消失（A 机 08:00:09），DNS 随后失效。
4. 机器"活着但没网"。内核还在跑、进程还在、云面板显示 running，但没有任何网络路径：出站不行、入站更不行，SSH、代理、控制台终端全部不可达。没有 panic、没有 oops、连 hung task 都没有——journal 里除了内核那几行 OOM 和 networkd 两行 Failed，再无痕迹。常规搜 panic/error 什么也扫不出来。

两个值得注意的点。其一，OOM killer 实际杀掉的是升级进程，networkd 是"超时自杀"；但加固前它的 OOMScoreAdjust=0、Restart=on-failure，在全局 OOM 里一样是零保护的候选，这次没被挑中纯属运气——这决定了下面的加固方向。其二，这种故障不留明显崩溃痕迹，B 机失联 18 小时没有任何人发现，正是因为面板显示正常、日志"看起来很干净"。

三、处置过程（含走过的弯路）

#

弯路一：本机测端口误报恢复。 本机经 TUN/代理测目标端口，本地应用立刻拿到 SYN-ACK，第一轮三个端口全部"OPEN"；干净外部源直连才暴露真相：全部超时。结论必须以非本机的观测点为准。

弯路二：自动重启被误关又恢复。 处置中一度把 50unattended-upgrades 的 Automatic-Reboot 从 true 改成 false，理由"去掉多余的重启"。随后确认一个名实问题：机器每周日凌晨的重启不是 cron——手动重启 cron 早在几天前加固时已删除（末次触发 09-06）；真正在做凌晨自动重启的是 unattended-upgrades 的 Automatic-Reboot-Time "02:00"（另一台机 08-20、08-22 两次 02:00 重启即它所致）。而站主平时不会定期登录机器，若关掉这个开关，装了内核更新也永不生效——最终改回 true 并以 apt-config dump 验证生效。这里想对读者说明取舍：关掉 Automatic-Reboot 的代价，就是内核安全更新要等下次人工重启才生效；无定期登录习惯的机器不建议关。

上机复核：另一套并行加固已生效。 出手前先复核现状，发现当天早些时候已经有另一批加固配置落在两台机器上（不是本次操作加的）：apt 服务的内存 cgroup 上限（MemoryMax=250M / MemoryHigh=200M）、networkd 的 OOMScoreAdjust=-1000 + Restart=always、multipathd 停用、以及一个 net-watchdog 路由看门狗。逐项验证确实生效，且与本次新增的 swap 不冲突——fstab 里 /swapfile 只有一条、无重复挂载，findmnt --verify 通过。这套思路比"只加 swap"更对：卡住 OOM 源头（apt 内存升到 250M 就在自己的 cgroup 内被杀，整机不受影响），而不是等它打死网络栈再救。

本次补做的处置：

1. 2GB swapfile：fallocate -l 2G → mkswap → swapon，写进 /etc/fstab（/swapfile none swap sw 0 0）。作用：吸收突发内存压力，让 OOM 尽量不发生。注意 swap 只是缓冲不是解药——OOM 一旦真的发生，netfilter 之外的任何进程都可能被随机挑中，网络栈仍可能中招。
2. 清理纯代理机用不上的定时器：禁用 motd-news.timer、update-notifier-download.timer、update-notifier-motd.timer（每日拉资讯/弹更新通知，代理机上无用途，省网络与内存）；保留 apt-daily、apt-daily-upgrade（安全更新）、fstrim、e2scrub_all、logrotate、dpkg-db-backup、net-watchdog。顺手停用 multipathd（无多路径存储，白占约 27MB）。
3. 补上离线告警：自建监控的离线告警此前未开，B 机失联 18 小时无人知晓。开启后同类失联约 3 分钟（grace 180 秒）内推送到消息通道。
4. 规格决策：站主否决升配（加内存每月约 +2 美元，对纯代理机不划算），以"swap + 内存 cgroup 上限 + OOM 保护 + 路由看门狗"组合替代。

看门狗逻辑（每 2 分钟，OnBootSec=3min、OnUnitActiveSec=2min、AccuracySec=15s）：

#!/bin/bash
LOG=/var/log/net-watchdog.log
if ! ip -4 route show default | grep -q .; then
  echo "$(date -Is) NO-DEFAULT-ROUTE -> restarting systemd-networkd" >> "$LOG"
  systemctl restart systemd-networkd
  sleep 10
  if ip -4 route show default | grep -q .; then
    echo "$(date -Is) recovered" >> "$LOG"
  else
    echo "$(date -Is) STILL-DOWN" >> "$LOG"
  fi
fi

它只治网络栈这一层，机器彻底卡死时它自己也跑不起来——所以它是兜底，不是主力；主力仍是掐住 OOM 源头。

四、验证

#

加固后用可观测指标逐项复核（两台机同批）；另外注意 OOMScoreAdjust 对已运行的进程要下次启动才生效，核实取值即可，不必为此强行重启 networkd。

实机后的观察：swap 建立后已开始承接压力（一台 8MB、一台 35MB），说明 512MB 上日常内存就是紧的。遗留的边界：apt 被限制在 250M 后，个别大升级可能因内存不足失败但机器没事——失败目前没有独立告警（监控只报在线/离线），需要的话可加一个"升级任务失败"探针。

五、留给后来者的清单

#

• 第一步永远是看内核日志里有没有 OOM：journalctl -k --since "1 day ago" | grep -iE "Out of memory|Killed process"。整机"活着但没网"时，这是最快的定位动作。
• 面板 Running + 静态 IP 未变 + 入站出站同时断（监控 agent 的主动上报也停）= 先怀疑整机资源/网络栈层，别急着找运营商。
• 小内存机器给 apt 体系套内存 cgroup 上限：apt-daily 与 apt-daily-upgrade 各建 drop-in，MemoryMax=250M、MemoryHigh=200M。
• 给网络服务保命：systemd-networkd drop-in 设 OOMScoreAdjust=-1000、Restart=always、RestartSec=10s。
• 路由看门狗（上文的 shell 脚本）作为兜底；记住它只治网络栈，机器彻底卡死时无效。
• 加 swap 只解决"尽量不发生 OOM"，不解决"OOM 发生时谁被挑中"；两者定位不同，别混为一谈。
• 自动重启开关的取舍：无定期登录习惯就保留 Automatic-Reboot "true"，否则内核更新永不生效。
• 本机经代理/TUN 测端口会乐观握手，端口存活判断一律用异地干净源。
• 这类故障不留崩溃痕迹，离线告警必须开——监控不告警等于没监控。

六、碎碎念

#

B 机先倒下 19 小时无人发现，A 机再倒才被重视——两台的差别只是先后，不是运气。回头想，“机器活着但没网"大概是运维里最容易被误判为运营商/云厂商问题的一类故障：面板一切正常，探测全部超时，谁都会先怀疑链路。实际上只要先花十秒钟看一眼内核日志里有没有 Out of memory，这整场排查就结束了。小内存机器上，自动更新这种"每天都在跑、从来不看结果"的任务，往往是隐藏的定时炸弹；给它套上 cgroup 上限、给网络服务戴上护具，再留一个看门狗兜底，这套组合拳对 512MB 级别的云主机都适用。

一个服务端渲染的 WordPress 站每隔几天就出现一次约 1 分钟不可用：访客和监控探针同时超时或 504，随后自行恢复，发生频率与外部抓取器、扫描器的活动正相关。本文记录这次排查。适用环境：WordPress + Hestia 控制面板（nginx→Apache 反向代理栈）+ php-fpm 8.3 + 前置 Bunny CDN，2026-09 实测。结论先行：根因不是网络、不是重启，而是这条链路上没有任何一层 HTML 缓存——CDN 的 Smart Cache 设计上永不缓存 text/html，源站又对每个页面发 no-cache，于是每次匿名访问都是完整回源跑一遍 PHP。

一、症状与第一手数据

#

监控服务在最近 5 天报告了 3 起约 1 分钟的掉线（表 1）。每次都没有明确的错误码：多数探测点是超时，个别探到源站 504；站点没有重启、没有 OOM、没有网络变更，掉线是"自己好的"。频率上与外部请求活动强相关。

判据来自监控探针的请求计数：探针在源站日志里的基数是每分钟 3–4 次，掉线分钟翻到 9–12 次——监控判定 down 后会对每个探测地点重试，请求量放大就是掉线指纹。用这一条从源站日志反推出全部掉线时刻，与监控 CSV 完全对齐，还为历史补齐了一串同型记录（每隔 2–4 天一次的整点后 :09 分钟 503 风暴）。

三个现场都指向同一个事实：php-fpm 池被突发请求打满。16 个 worker 的池子被 61 并发、250 个 404、或插件更新风暴任一撑爆，与站点共用同一池的监控探针立即跟着失败。

但"被打满"只是最后一环，真正要回答的是：为什么区区几十个并发就能打满整站？ 对响应头做一次"判缓存真伪"的检查，答案立刻浮出来。

# 改造前，公网连打 5 次匿名首页/文章，每次都一样
HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: no-cache
cdn-cache: MISS
cdn-cachedat: 09/17/2026 23:43:10   ← 等于请求当刻
cdn-requestpullsuccess: True
cdn-requestpullcode: 200

cdn-cache: MISS + cdn-cachedat 等于请求当刻 + 每次都 cdn-requestpullsuccess: True，这是一个"每次都现拉"的指纹。对照验证：同一批请求同步出现在源站 Apache 访问日志里——CDN 每收到一次页面请求，就回源运行一整次 PHP。

同一时刻的静态资源是完全不同的待遇：

所以准确的说法不是"CDN 没工作"——静态资源它是干活的；是 HTML 流量从没被缓存过，一直是原样转给源站的。

二、根因

#

把链路一层层看过去，结论是：三层都没有 HTML 缓存。

第三层的机制值得展开。Bunny 的 Smart Cache 默认只缓存白名单里的静态扩展名（图片/字体/文档/代码），把 HTML 这类当作"动态内容"无条件放行回源，其设计理由是"防止把敏感的个性化内容误缓存给别人"。文档给出的绕过方式只有一条：写 Edge Rule，用 Override Cache Time 动作覆盖。

而源站这边，WordPress 生态里有插件在给每个页面发 Cache-Control: no-cache（卸载插件留下的持久化行为）。于是双重叠加：

• Smart Cache 说：text/html 永不缓存；
• 源站说：这个响应不许缓存；
• 连"用 Edge Rule 强制缓存 N 分钟"也被第二条否决——Bunny 不为标了 no-cache 的响应建缓存。

结果就是：CDN 提供了一整套"带宽能力"（TLS/HTTP2、DDoS 吸收、静态资源缓存、图片优化），唯独对 HTML 是纯中转。这个站的每一次页面浏览，都等价于有人直接访问源站。

三、处置过程（含走过的弯路）

#

这一节比答案更值钱：Bunny 面板上的 HTML 缓存开关和 Edge Rule 强制缓存，我们实测都走不通，而且有一个开关比不开更糟。

弯路 1：面板的"静态 HTML"开关把全站变成 BYPASS

#

先试 Bunny 官方路径的第一条：开 Optimizer 的"静态 HTML"开关。开启的瞬间，面板自动在拉区生成两条 Edge Rule：一条 action=OverrideCacheTime 且参数为 0（即永不缓存）、带 cookie 触发器，另一条是 BypassPermaCache，两条的 URL 触发器都是全站通配符。

实测（开启后连打匿名页面、带 cookie 请求、静态资源）：

edge try1   200 0.549s   cdn-cache: BYPASS   ← 不是 HIT，是显式旁路
edge try2   200 0.080s   cdn-cache: BYPASS
css try1    200 0.055s   cdn-cache: BYPASS

连静态资源也从 HIT 掉成 BYPASS——这个开关把它自动生成的规则当作唯一裁定，全站绕开缓存，比不开更糟。回退后边缘静态资源恢复 HIT。

弯路 2：Edge Rule 强制缓存时间仍然无效

#

第二条路按文档来：自己写 Edge Rule，按响应 content-type: text/html + status 200 覆盖缓存时间 600 s。先后试了两种动作（OverrideCacheTime 与 OverrideCacheTimePublic），再不断收窄触发器（全站 → 单篇文章 → 去掉可疑触发器），结果一致：

article try1   200 0.595s   cdn-cache: MISS    origin: EXPIRED
article try2   200 0.076s   cdn-cache: MISS    origin: HIT
article try3   200 0.078s   cdn-cache: MISS    origin: HIT

边缘依旧 MISS，只是源站层自己命中（说明这时已有一层 nginx 代理缓存在工作——它属于第二层，与边缘无关）。排除触发器问题后结论收敛：卡点是源站显式发的 Cache-Control: no-cache——Bunny 拒绝为这类响应建缓存，什么 Edge Rule 都覆盖不了。官方两条路径在我们这里失效的原因由此明确：它们的前提都是源站先把头发对。

弯路 3（侦查层面）：防火墙日志里的大量 BLOCK 不是攻击

#

排查早期（另一个掉线窗口）宿主防火墙日志持续刷着数千条 BLOCK 记录，第一反应很像被扫描或攻击。逐一核对策略后确认：那是防火墙默认拒绝策略对容器 DNS 查询的常规拦截——软件默认行为，不是攻击信号。它确实造成容器内 DNS 不可用等一系列副作用（另案修复），但与掉线窗口无关，窗口内源站全程 200。排障时先分清"策略性拦截噪音"和"真正的 5xx/断流"，否则会在默认行为上浪费整个调查阶段。

最终方案：两层缓存 + 发布即清除

#

教训汇总成一句话：要让 CDN 缓存 HTML，得先让源站对"值得缓存的请求"发出可缓存的头。落地四步：

1. 源站头正确化（WordPress mu-plugin，在 send_headers 钩子里按最终优先级覆盖）：
   • 匿名 + 无查询串 + 非后台/API/Feed 的 HTML：Cache-Control: public, max-age=0, s-maxage=600（边缘缓存 10 分钟，浏览器每次验证）；
   • 登录/评论者/密码页 cookie、wp-admin、AJAX、REST、查询串、预览、404：Cache-Control: no-cache, no-store, must-revalidate, private。
2. 边缘层：关闭 Smart Cache（EnableSmartCache=false），让 Bunny 完全按源站头决定；只留一条 Edge Rule 做旁路——cookie 匹配 wordpress_logged_in/wordpress_sec/wp-postpass/comment_author 等，或路径匹配 /wp-admin/*、/wp-login.php、/wp-json/*、/xmlrpc.php、/wp-cron.php，一律缓存时间 0。
3. 源站层：控制面板的反向代理模板切成 caching（nginx proxy_cache：200 缓存 5 分钟，301/302 与 404 缓存 10 分钟）；cookie 与 POST 自动置 $no_cache=1 旁路；X-Update 请求头既绕过读取又写回新副本。
4. 发布即清除：bunnycdn 官方插件只有后台手动清除按钮、没有发布钩子，所以由同一个 mu-plugin 在发布/更新/评论事件里触发：CDN 全区 purge + 对受影响 URL 发带 X-Update 的回源请求刷新源站层。注意回源刷新必须请求干净 URL——nginx 缓存键包含查询串，带缓存破坏参数会写进另一个键，等于没刷新。

另有一处与缓存无关的独立优化：给不存在的静态资源直接返 404。扫描器打的 /wp-content/themes/xxx/style.css 原本会被 try_files → fallback 交给 WordPress，渲染出 46.6 KB 的主题 404 页（又是一次完整 PHP 引导）。改为在 nginx 层对 /wp-content/、/wp-includes/ 下带静态扩展名且文件不存在的请求直接返回 404（2.9 KB）。实现要点：必须用 location ^~ 前缀写法——普通 location ~ 会被控制面板 vhost 内嵌的正则位置抢先，写了不生效（同样是实测踩坑）。

四、验证

#

最终结构与实测数字（公网路径，全部经过 CDN）：

改造前同路径匿名页回源约 0.5 s；改造后匿名命中只要零头，而且源站请求量归零。

洪峰复现（关键验收）：拿 09-17 的真实洪峰形态（60 个请求、并发 20、混打真实页面）重放：

• 全部 200，平均 67 ms、最大 95 ms，没有一个超过 1 s；
• 源站 Apache 日志只多了 9 条（绝大多数请求没碰 PHP）；
• 源站负载从 0.13 升到 0.22，探针请求全程 50–70 ms 正常。

对照改造前同类洪峰：504 + 30 秒级排队。那个"1 分钟掉线"的机制被从根上拿掉。

发布即清除验证：手动执行一次 purge 路径后，边缘立即转 MISS，下一次请求自动回温 HIT；源站缓存条目由 X-Update 请求刷新而非等过期。

怎么判断没解决（反向验收）：匿名页 cdn-cache 仍是 MISS，且源站访问日志与访客请求同步增长——两者出现任何一个，说明 HTML 又回到"每次现拉"状态（常见诱因：源站头又被某个插件改回去、Smart Cache 被重新打开、旁路规则误伤匿名流量）。

五、留给后来者的清单

#

1. 先判缓存真伪，再谈缓存配置。三个响应头一次到位：
   • cdn-cache: MISS 且 cdn-cachedat 等于请求当刻 → 每次都回源，没吃到边缘缓存；
   • 同一批请求同步出现在源站日志 → 每次都跑了完整渲染；
   • 对照静态资源是否 HIT → 区分"CDN 坏了"与"HTML 没缓存"。
2. 查"链路上有没有一层 HTML 缓存"，三个看着有其实没有：WP_CACHE=true 但 advanced-cache.php 不存在（常量空转）；控制面板 microcache 需按域开启、vhost 没有对应指令等于没开；CDN 拉区若延续源站 no-cache 头，边缘也不会缓存 HTML。
3. Bunny HTML 缓存配方（本文实测可跑通）：Smart Cache 关闭 → 源站 mu-plugin 只对"匿名 + 无查询串"的 HTML 发 public, max-age=0, s-maxage=600，其余一律 no-cache, private → 一条 Edge Rule 做 cookie/后台路径旁路 → 边缘与源站各配一层缓存 → 发布/评论时双层清除（全区 purge + X-Update 干净 URL 回源）。
4. 旁路清单别漏：登录/评论者/密码页 cookie、wp-admin、wp-json、xmlrpc.php、wp-cron.php、带查询串、POST、预览、404。漏掉任何一个，轻则缓存错页面，重则把登录后的页面发给别人。
5. 用 API 改边缘规则注意部分更新语义：未提交的字段会被重置为默认值，改完拉全量配置核对漂移。回滚路径各一步：删 mu-plugin 文件、模板切回 default、删旁路规则、Smart Cache 重新打开。

六、碎碎念

#

把这次调查串起来的其实是最后一条因果链：这套架构里，16 个 worker 的 php-fpm 动态处理池就是整站吞吐上限。CDN 不缓存 HTML，“读一个页面"和"跑一次完整渲染"就变成同一件事；池子被打满（抓取器、插件自动更新、扫描器 404），新请求全部排队直至超时——而监控探针探的就是贴着你首页的 PHP 渲染，和访客挤在同一池子里。池满那一刻，监控和访客看到完全相同的"1 分钟黑洞”。

之前把池子从 8 扩到 16、把图片交给 CDN 优化，都只是把黑洞往后推了推。真正让它消失的，是承认 CDN 的 HTML 缓存坑、把源站头发对、再把"页面浏览"从 PHP 渲染里剥离出来。给博客做缓存的价值也在这里：它不只是面板上的命中率数字，更是让"监控探针"和"真实访客"两种流量不再挤同一个池子。以后若再见同型症状，先看两个响应头，再决定要不要碰防火墙。

本站原先跑在 Ghost 6 上（Node/Express + SQLite，单容器）。这篇记录把它整体换成 Hugo + Blowfish 静态站的全过程：迁移前实测的对照数据、内容与 URL 的搬家方式、版本化部署与回滚，以及过程中踩到的十个坑。适用环境：Ghost 6.64 / Hugo 0.166.0 extended + Blowfish 主题 / nginx:alpine 容器 + Nginx Proxy Manager + systemd / 前置 Bunny CDN，2026-09-18 实测。结论先说：值得迁，但"省内存、省带宽"不是理由——客户端那一千 KB 里最肥的一块与换不换平台无关；真正的理由是内容变成 git 里的 Markdown、发布链路可验证、回滚变成一条命令。

一、迁移前先把"更轻便"量出来

#

迁移前本站的规模：4 篇文章、5 个标签、3 个附件脚本、一共 12 条 URL。全部实测数据如下（不是文档推断，是在真实环境里量出来的）。

服务端：

客户端（页面全资源，含 CSS/JS/字体/图标）：

上线后实测：首页联网传输 63.7 KB（迁移前 1008 KB，大约 1/16）。

但客户端这份收益不该记在迁移头上。 那 764.8 KB 的 mermaid 是旧主题里一行无条件加载造成的：

<script defer src="{{asset 'js/mermaid.min.js'}}"></script>

全站没有任何一张 mermaid 图，把这一行删掉或改成按需判断，留在原平台也能拿到同样的页面瘦身。同理静态资源缓存、图片优化这些，都是 CDN 与主题层面的事，与换不换引擎无关。

二、为什么迁：维护面，不是内存

#

把迁移前的账摊开看，真正的过度工程在 CMS 这一侧：4 篇纯文本内容，养着一套完整的 Node 运行时 + SQLite + Admin API + 登录 + 两步验证 + 主题模板手术，外加一条相当脆弱的发布路径——签名用的是十六进制密钥（必须先解码再作 HMAC key，用错就 401）、更新内容必须带特定参数否则静默不生效、必须有乐观锁字段、某些接口直接抛 501 只能绕过 API 改数据库、换新设备登录会被强制邮箱验证码拦下。这些都不是能力，是维护面。

换成静态站之后，值得写在纸上的收益只有三条：

1. 内容主权。内容从数据库行变成 git 仓库里的 Markdown 文件，版本、差异、审阅、回滚、增量全是现成的。
2. 发布链路可验证。写 .md → 构建 → 同步，构建可以在本地跑通再上线；运行态的故障面（Node 运行时、数据库、后台登录）收缩成一个"构建管线"，而它失败时线上可以不受影响。
3. 现在迁最便宜。4 篇内容、无图片、无会员、无评论、无注册，URL 一共 12 条。内容越多、外链越多，迁移只会更贵。

反过来说，不建议为了省内存而迁：宿主机的内存本来就不缺这一百多 MiB；而迁移会把"跟着 CMS 镜像升级"的维护精力，换成"Hugo 版本窗口 + 主题兼容"的维护精力——故障面是换了种类，不是消失了。

唯一不可逆的东西是 URL 与订阅（RSS 的 <guid>），所以整套方案按"先保 URL 与订阅、再谈别的"的顺序设计。

三、处置过程

#

1. 内容搬家：从数据库的 HTML 列，而不是导出 JSON

#

内容源直接取 CMS 数据库的 html 列（避免二手导出数据），用一次性脚本转成 Markdown。保真度实测：表格（6 张）、围栏代码块（含语言标注）、引用块全部保留；把两边归一化后做 token 级比对，差异只剩 Markdown 记号本身（转义下划线、分隔线、列表序号）。

过程中有一个必须知道的坑：CMS 在数据库里把站点地址存成了占位符（形如 __GHOST_URL__），渲染时才替换成真实地址。直接迁移会得到一堆 __GHOST_URL__/content/files/... 的死链，脚本里必须把它替换成站内相对路径。附件（3 个 PowerShell 脚本）落到 static/content/files/<年>/<月>/，URL 与迁移前逐字节一致，构建即发布。

清洗分两步：先用扫描脚本列出所有反斜杠转义（这个平台的转换器会给词内下划线加转义），确认哪些是 Markdown 记号、哪些是 Windows 路径里的真反斜杠，围栏代码块一律不动，再动手还原。

2. URL 保平：12 条旧地址一条不漏

#

文章 URL 形态用配置项固定住（[permalinks] posts = "/:slug/"），所以三篇文章的地址原样不变。需要额外处理的是其余地址：

标签页有个静态站特有的坑：新引擎里给标签写 slug: 不生效（实测 0.166 版本），必须写 url:，否则标签页地址会变成中文名的拼音或原文，与旧地址对不上。写法是给每个标签建一个索引页，front matter 里写 url: "/tags/<旧 slug>/"。

还有一个只有反代环境才会遇到的坑：301 的目标必须写死 https://。源站在反向代理后面，看到的请求协议是 http，如果 301 用相对路径或 $scheme，访问者会被降级跳回 http 再被跳一次。正确写法是显式 return 301 https://$host/<新路径>;。

3. RSS 订阅连续性：<guid> 必须是旧的那一串

#

这是整个迁移里最容易翻车、又最容易被忽略的一处。RSS 条目的 <guid> 是不透明字符串，迁移前的引擎用的是数据库内部的文章 id；而 Hugo 默认拿永久链接当 <guid>。两者一换，所有老订阅者会在切换当天把已有的旧文章当成新文章重收一遍。

处理方式：从旧站的 /rss/ 里把每篇文章的 <guid> 取回来写进 front matter，再用一个自定义的 layouts/rss.xml 覆盖默认模板——front matter 里有 guid 就用它，没有才退回永久链接；同时用 mainSections = ["posts"] 把独立页面（关于页等）踢出 feed。

模板里另有一个语法坑：XML 声明必须走模板函数输出，字面写会被转义成 <?xml：

{{ printf "<?xml version=\"1.0\" encoding=\"utf-8\" standalone=\"yes\"?>" | safeHTML }}

验证方式是逐条比对：feed 条数、每条 <guid> 与线上旧 feed 逐个一致、XML 可解析。

4. 部署：版本化目录 + 符号链接原子切换

#

落地结构：

/srv/site/
├── src/        内容仓库的工作副本（构建前 fetch + reset）
├── releases/   每次构建一个带时间戳的目录
├── bin/        hugo 二进制（锁定版本，不跟随包管理器）
├── scripts/    构建与部署脚本
├── deploy/     systemd 单元等部署配置
├── logs/       部署与自动部署日志
└── current -> releases/<时间戳>   符号链接，网站根目录指向它

部署脚本的语义固定为六步：拉取内容 → 构建到新的 releases/<时间戳> → 校验关键产物非空 → 原子替换 current 符号链接 → 配置有变化则同步并让容器 reload → 只保留最近 5 份。

这样做的意义是"发不出去"不等于"站挂了"：构建失败或校验不通过时 current 不动，线上继续跑上一版。

服务容器是 nginx:alpine，只接内网（不映射公网端口），由反向代理转发，前面挂 CDN。回滚有两档：

• 回上一版产物：把 current 指回上一个 release 目录（nginx 每个请求都会重新解析符号链接，不需要重启）。
• 回旧平台：把反向代理的转发目标改回 CMS 容器，再把它启动起来（容器与数据一直保留，切换前的数据库行与生成的配置文件都有备份）。

Hugo 的版本是硬约束：主题声明了兼容窗口（extended 0.163–0.166），所以本地二进制、服务器上的二进制、主题三者必须一起动，不追新。

自动部署用 systemd timer 每 5 分钟检查一次远端仓库：有新提交就跑部署脚本，没有就静默退出（不写日志，避免日志噪音），失败时发一条即时通知。两个实测细节：timer 的多时刻要拆成多行 OnCalendar= 写（单行逗号串或 *:0/5 这类重复语法会解析失败或算不出下一次排期）；验收要看服务单元的启动时间戳是否往前推进，只看 list-timers 的"下次触发时间"不算数。

5. 十个坑（全部实测）

#

四、验证

#

上线后的核对清单（全部实测）：

两件必须做的事：

回读断言。 “推送成功"不等于"已上线”。构建静默崩溃、缓存没清、权限位丢了，都能让推送成功而页面不变；部署脚本的退出码看不出这些。所以每次发布后都要回读一次目标 URL，确认新内容真的可见——这是静态站最典型的失败模式。

CDN 缓存清除。 前置 CDN 会缓存 HTML，改版后不清缓存读者还会看到旧页。清除接口按 URL 逐个调用，切换当天把那十几条地址（含已废弃的旧地址）全部清了一遍。

五、留给后来者的清单

#

• 迁移前先量数据：镜像、内存、页面全资源体积都实测再拍板；动机锚定"内容主权 + 发布链路"，别为省内存带宽而迁。
• 内容源取数据库的 HTML 列，别用导出 JSON；先查有没有站点地址占位符。
• URL 保平做成清单：文章用永久链接配置对齐、标签页写 url: 而不是 slug:、其余用 nginx 301 收口，目标写死 https。
• RSS 的 <guid> 沿用旧值，否则老订阅者重收旧文；XML 声明用模板函数输出。
• 部署用"版本化目录 + 符号链接原子切换 + 产物校验"，构建失败不动线上；只留最近几份。
• 站点目录别放 /root（0700 会让容器里的 worker 全站 403）；容器别直接挂符号链接，挂父目录。
• 附件进版本库前先算体积：几个小脚本可以忽略；将来若要放二进制包（压缩包/可执行文件），考虑对象存储或另建仓库，别让 git 历史无限长。
• Windows 下提交任何脚本前，先确认执行位没有丢。
• 发布闭环固定为：构建 → 部署 → 清缓存 → 回读断言，缺一步就可能误报成功。
• 动手前先把回滚路径写下来（旧容器与数据留几周），改反向代理前备份数据库行与生成的配置文件。

六、碎碎念

#

这次迁移之所以能在一天内做完，是因为站点足够小：4 篇文章、12 条 URL。规模再大一点，任何"迁移"都会变成一场项目。过程中真正花时间的不是搬家本身，而是那十个坑——它们几乎都跟"两层抽象叠在一起"有关：容器里看权限、容器外看符号链接、反代后面看协议、CDN 前面看缓存、主题里面看样式表产物。排错时先把这条链拆开，逐层确认身份，比猜配置快得多。

另一件值得记住的事：旧平台上那行无条件加载 764 KB 脚本的代码，算下来比换成静态站带来的服务端收益还大。主题里一行代码的技术债，可能比平台选择本身更值钱——迁移前后都值得先把这行找出来。

一台"看起来一切正常"的 Windows 11 IoT 企业版 LTSC 2024（24H2）机器，从一次普通的 Windows 更新失败开始，走过七轮覆盖安装、数十条命令、三次多模型会诊，最后不得不格盘重装。这篇回顾把整个历程的病症、误判、实验和最终结论，用平实的语言讲清楚。

一、缘起：一个"普通"的更新失败

#

某天系统提示：

2026-08 安全更新 (KB5121003) 安装错误 - 0x800f0991，并要求持续安装 Windows 以修复系统文件和组件。

点"修复"按钮，没用。重启，没用。错误码永远挂在 Windows 更新页面上。

机器是 Windows 11 IoT 企业版 LTSC 2024（Build 26100.6972）——注意，这个系统是"精简/优化版"LTSC 镜像装出来的，不是微软官方原版。当时谁也没想到，这个出身会在半年后酿成一场七连败的战役。

二、病灶的真相：组件库与磁盘文件脱节

#

第一轮诊断就发现了诡异之处：系统声称装了 7900/8457/8972/9156 几个时代的组件，但关键系统文件（ntoskrnl、ntdll、DismCore）各自停留在不同版本，混装了四个时代的东西。实证结果是：UBR 停留在 6972，说明 2025 年 10 月之后再没有一次更新真正完整落地过。

也就是说：这台机器从装好的那天起，就在"带病运行"。能开机、能上网、能打游戏，但系统内部的账本（组件库记录）和仓库（磁盘文件）早就对不上了。

这是精简版 LTSC 的第一个大坑：“能正常用"不等于"系统健康”。精简优化镜像为了体积删掉了大量组件，删的时候如果动到了组件库的元数据（而非仅仅卸载应用），系统不会当场报错，而是把病根埋在半年后你第一次想打补丁的那一天。

三、常规手段全灭（Stage 1：患者尝试自救）

#

我们按教科书顺序试了一遍，全部失败：

这一阶段的关键结论：这不是一次"更新失败"，而是服务子系统整体坏死——它不认识新格式的包、读不懂自己的账本、连修复工具都跑不完。传统偏方（清缓存、DISM、sfc、疑难解答）对这种病全部无效。

四、外科手术之路：slipstream 为什么数学上不成立（Stage 2）

#

既然本机服务栈是坏的，那就绕开它——自己做一个新镜像来覆盖安装？这条路我们走得最远，也最有教育意义：

1. uupdump 没有 LTSC：这个著名的镜像生成站只有零售 SKU，微软把 LTSC 从 UUP 公开通道里排除了，做不了。
2. 官方评估 ISO 比你机器还旧：微软官方 LTSC 2024 评估镜像还是 26100.1742（GA 版本），比机器上的 6972 还老，不能用于升级。
3. WIM 挂载注入失败（0xc1510111）：本机挂载驱动也是坏的。
4. 解包→注入→重新打包（apply/add-package/capture）：解包成功，但注入基线包依然 552——宿主的 DismCore（老）不认新格式。
5. 装上 ADK 现代 DISM 再注入：能解析 MSWIM 了，甚至成功装入了 SSU（服务栈更新），但 SSU+LCU 必须处于同一个服务会话，否则报 1726（RPC）/ schema.dat 拒绝访问。
6. 最后一击：检查点（Checkpoint）机制。2024 年后的累积更新是"检查点基线 + 增量"结构，9168 的增量基于 8972 基线，而对 GA（1742）镜像意味着要连锁安装 8 个月的检查点更新——离线注入在数学上不成立。

结论：手工集成镜像这条路，被微软的更新架构（MSWIM/PSF 格式 + 检查点模型 + 服务会话绑定）彻底封死。这也是普通用户"做个新镜像升上去"的普遍误区——在 2024 年之后的系统上，这条路已经走不通了。

五、覆盖安装七连败（Stage 3：换镜像强攻）

#

拿到第三方集成镜像（一个号称 26100.9168 的 25H2 镜像，实则 26200），开始覆盖安装。七次，七次失败，全部同一个面错误：

无法安装 Windows 11
0xC1900101 - 0x20017
在启动(SAFE_OS)操作阶段安装失败

0xC1900101 是著名的"回滚错误码"，屏幕上写"驱动错误"，但 minidump 里全是半年前的旧文件——SAFE_OS 阶段根本没有真实内核崩溃，屏幕提示是回滚状态机的误报。真正的死因一次比一次挖得深：

• 第 1 次：卡巴斯基。迁移阶段写注册表 HKCU\Software\KasperskyLab 被拒（0x00000005）——杀软的自保护驱动拦截了系统迁移。卸载卡巴后，死因变了。
• 第 2 次：PITR.dll 缺失。收尾阶段移除回滚快照时找不到 C:\Windows\System32\OOBE\PITR.dll（组件库里有，System32 副本丢了——精简版后遗症）。从 WinSxS 补回后，死因又变了。
• 第 3~7 次：SPDeserializeOperations: saw unrecognized object header '0x0'。操作队列反序列化崩溃——这是核心死因，也是最终判决书。

为了排除嫌疑，我们做了这些干净利落的实验：

最终归因：旧系统注册表层的 setup 组件类型注册元数据已经坏死——序列化端写出的对象，反序列化端不认。这不是缺 DLL、不是残留、不是介质问题，是"账本本身烂了"，任何文件层面的修复都无效。

六、7 次失败之后的决策：为什么只能格盘

#

把决策过程说清楚，这件事才算讲完：

1. 非破坏手段穷尽：清理、补文件、换介质、拔设备、多模型会诊（GPT/Kimi/Gemini/DeepSeek/Claude 三轮回诊全部指向同一个结论）。剩余方案胜算全部 <5%。
2. 止损线：同一错误点出现三次以上且每次实验变量被严格排除，就必须停止"再试一次"的冲动。第七次拔盘实验是最后一个被允许的实验（因为它从未被验证过），失败后即无条件转重装。
3. “安全网"是幻觉：覆盖安装的所谓"保留系统回退"在这个场景里毫无意义——旧系统本身就是病，回退回去等于回到病里。
4. 重装成本其实很低：备份全部个人数据（robocopy 三小时）→ 格式化 C 盘 → 全新安装 26100.9168（45 分钟）→ 数据归位。干净系统激活自动延续（OEM 数字授权），Windows 更新第一晚就自动装上了新补丁。

关键认知：7 次失败换来的不是"再试一次”，而是"确信重装是唯一解"。排错的价值在于把不确定性清零，而不是把可能性耗尽。

七、LTSC 精简版能离谱到什么程度（教训清单）

#

这台机器的病历拿出来，每一行都是一条反例：

• 组件库记录与磁盘文件脱节：声称装了 4 个时代的组件，实测系统文件混装 4 个时代的版本，而没有任何报错。
• System32 文件黑洞：PITR.dll、UnBCL.dll 说没就没——精简工具删除组件时连核心运行时都敢动。
• DismCore 老到不认新包：缩写为 552 的怪错误，本质是旧服务栈解析不了 2024 年后新格式的更新包。
• 升级时的连环爆：卡巴拦截（外部因素）→ PITR 缺文件（文件被删）→ 序列化坏死（元数据损坏），一次比一次深，像剥洋葱。
• 第三方镜像的坑：“原版集成"镜像把 26100.9168 集成成了 26200（跨分支！）；wiminfo 的版本元数据被抹掉；号称"完整+适量精简"的镜像里没有 IoT 版索引（只有 EnterpriseS，装不上你机器的 SKU）；7.6GB 的"无驱版"连版本号都查不到。

给后来者的三句话： 1. LTSC/精简镜像装完先打一次更新验证：机器能开机能上网，不代表服务栈健康。装好系统第一件事是打满更新，如果更新失败，趁数据少赶紧重装。 2. 升级失败看日志，不看屏幕：0xC1900101 的屏幕文案是"驱动错误”，真因全在 C:\$WINDOWS.~BT\Sources\Panther\setuperr.log 和 SetupDiag 里。 3. 错误码是一个阶梯：0x800f0991（载荷缺失）、0x80070228/552（服务栈不认包格式）、0xC1900401（检查点基线缺失）、SPDeserializeOperations 0x0（元数据/序列化坏死）——越靠后的错误越接近"没救了"的判决。

八、最终的最终

#

• 机器现在是：Windows 11 IoT 企业版 LTSC 2024，26100.9168，已激活，更新畅通。
• 数据：桌面/文档/音乐/邮件/浏览器/微信文件，100% 回归（连浏览器打开的标签页都救了回来，见第二篇）。
• 教训：“能用"和"健康"是两回事。精简版 LTSC 用它的方式为你省了空间，而你终将在某一天用一次格盘重装偿还。

适用场景：重装系统后（即使还用同一个用户名），文件/文件夹属性里出现"未知账户"， 或者旧硬盘（包括移动硬盘）上的文件提示"拒绝访问"。 原理：Windows 重装会生成新的机器 SID，旧文件的所有者和权限条目里记录的是旧 SID。

需要什么

#

• Windows 10/11，PowerShell 7 (pwsh)（没有的话管理员运行：winget install Microsoft.PowerShell）
• 管理员权限（运行时会弹 UAC，点"是"）
• 要修复的硬盘全部接好

使用步骤

#

1. 修复（改所有权 + 替换所有旧 SID）

#

管理员 PowerShell 7 中运行：

pwsh -NoProfile -ExecutionPolicy Bypass -File fix_sids.ps1 -Roots "D:;E:;F:;G:;H:;I:"

• -Roots 换成你自己的盘符列表，分号分隔；不要包含系统盘 C:；不填则自动选择除 C: 外所有卷
• 脚本会先做一次自检（在临时目录造测试数据验证修复逻辑），通过后才开始处理真实数据
• 每块盘的处理顺序：takeown /r 批量改所有者 → 逐个对象替换旧 SID（所有者/组/权限条目，含从父目录继承的）
• 进度写入 %TEMP%\hermes_acl\fix_sids.log；跑完看日志末尾：err=0 fails=0 即完美

2. 恢复盘符（可选，重装后 Windows 会重新分配盘符）

#

先确认重装前各盘是什么字母（旧笔记/习惯），再编辑 restore_letters.ps1 里的映射表，然后管理员运行：

pwsh -NoProfile -ExecutionPolicy Bypass -File restore_letters.ps1

3. 验证（确认"未知账户"清零）

#

pwsh -NoProfile -ExecutionPolicy Bypass -File acl_scan.ps1 -Roots "D:;E:;F:;G:;H:;I:;C:\Users"

结果文件在 %TEMP%\hermes_acl\acl_scan_result.txt：bad = 0 即全部修复。 （C:\Users\Public 下出现 S-1-5-3/S-1-5-4 是 Windows 系统默认 SID，属正常，不是问题。）

注意事项

#

• 修复期间不要关机、不要拔盘；被其它程序占用中的文件可能被跳过（日志里 SET_ERR），关掉程序后重跑一次即可
• 跳过 $RECYCLE.BIN、System Volume Information、Recovery（系统自己会重建，不用管）
• 权限级别（完全控制/修改/只读等）原样保留，只是把旧身份换成新身份；不会破坏自定义权限
• 修复结果只对"这台机器"有效：把盘插到另一台电脑上，那台电脑仍会显示未知（NTFS 权限按机器记）。多机共用建议额外加 Authenticated Users 权限
• 中途断掉也没关系：脚本幂等，重跑会继续处理剩下的

常见问题

#

工具包下载

#

三个脚本（管理员 PowerShell 7 运行，均为明文、程序员友好）：

• acl_scan.ps1 — 扫描验证（bad = 0 即修复完成）
• fix_sids.ps1 — 一键修复（自检 + takeown + SID 替换）
• restore_letters.ps1 — 恢复盘符映射

重装 Windows 后，把浏览器数据从备份里拷回去，打开 Brave 却发现"因安全原因"丢了打开的标签页、固定标签页和扩展程序数据。本文基于 2026-08-26 与 2026-08-31 两轮实战（Default 完整恢复 + 另一个 Profile 扩展全丢后完整救回），讲清楚 Chrome/Brave 的数据机制、正确的备份/恢复姿势，以及所有试错后验证出的唯一正道。

一、先搞懂四个机制，你就成功了一半

#

机制 1：会话文件分两套，只有一套能救你

#

Chrome 系浏览器的标签页恢复依赖两类文件：

① 活动会话文件（会无辜失踪的那套） - User Data\Default\Current Session / Current Tabs - User Data\Default\Last Session / Last Tabs

这是"进行中会话"的实时快照。浏览器正常关闭时，会主动删掉它们——所以当你看到"备份里没有 Session 文件"，不代表没救，而是浏览器最后一次是干净退出的（这恰恰是好事）。

② 会话恢复快照（真正救你命的那套） - User Data\Default\Sessions\Tabs_1389xxxxx（标签页状态，十几 MB） - User Data\Default\Sessions\Session_1389xxxxx（每个标签的数据） - User Data\Default\Session Storage\（表单、页面局部状态）

这套文件由"会话恢复系统"持续落盘，浏览器退出时不会删除，专门用于崩溃恢复和"继续上次会话"。备份时只要这套文件在，标签页就能救回来（含最后写盘时刻的状态）。多 profile 同理：Profile N\Sessions\ 也在。

机制 2：扩展注册在哪——Secure Preferences，不是 Preferences（实战修正）

#

扩展的注册（启用的扩展清单、安装时间、来源）在 Secure Preferences 文件的 extensions.settings 里，不在 Preferences 里。 这是最容易踩的认知误区：

Secure Preferences 的 MAC 用 Local State 里的 os_crypt 密钥计算。手改 Secure Preferences 任何一个受保护字段 → MAC 失效 → 浏览器丢弃整个受保护区（扩展注册清空，只剩内置扩展）→ 写回一份"干净"的文件。

机制 3：“安全原因"重置的真实触发条件（实战修正）

#

旧认知：“外部修改了 Preferences 文件 → 重置”。实测真正的触发条件是：Extensions\ 目录与 Secure Preferences 里的注册不一致：

• 目录里有"未注册"的扩展本体 = 疑似外部注入 → 整体重置（清空注册 + 删除整个 Extensions 目录内容）
• 注册了但本体目录缺失 = 疑似被破坏 → 同上

也就是说：把扩展本体拷进 Extensions\ 目录这个"标准操作”，在注册已被清空的状态下反而会触发重置并删掉你刚拷进去的东西。 这是本次目标 Profile 恢复中反复被重置删目录的根因。

它重置什么、保留什么：

⚠️ 注意：扩展被"卸载"时（比如从 chrome://extensions 移除，或强制安装策略被移除）会连带删除 Local Extension Settings 和 IndexedDB 里该扩展的数据——这与"安全重置"不同，重置通常保留数据目录，卸载会删。所以卸载类操作前务必先备份数据目录。

机制 4：加密链——Local State 的密钥，重装后就换掉了

#

User Data\Local State 里保存着加密主密钥（os_crypt.encrypted_key，DPAPI 加密）。它保护： - Secure Preferences 的 MAC（防篡改校验） - 密码库 Login Data、Cookie 的解密

重装 Windows 后：DPAPI 上下文（用户 master key）随旧系统消失 → 备份里的 Local State 的 encrypted_key 解不开 → 浏览器静默生成新密钥并重写 Local State。后果：

• 备份里所有 Secure Preferences（旧密钥 MAC）→ 全部校验失败 → 首次启动各 profile 的扩展注册被逐 profile 重置（哪个 profile 先被打开就先重置哪个）
• 备份里的密码库/Cookie（旧密钥加密）→ 无法解密，视为空库（新密钥下重新登录）

所以：重装后"从备份整体回拷 User Data"必然经历一次"安全原因"重置，扩展注册必丢。这不是操作失误，是机制使然。 书签/历史/标签页（不加密的 SQLite/快照）不受影响。

二、备份的正确姿势（事前，最重要）

#

1. 完全退出浏览器（关闭所有窗口 + 托盘图标退出，确认 brave.exe 无进程）。运行中备份会漏掉锁定的文件。
2. 整体拷贝 User Data 目录（9~10GB），绝不只拷 Default： %LOCALAPPDATA%\BraveSoftware\Brave-Browser\User Data\ ← 整个目录 里面包含：Local State、Default\ 及所有 Profile N\、Sessions 快照、扩展本体与数据。
3. 校验：拷贝后对比文件数与总大小（差 5% 以内正常，差 20% 以上有问题）。
4. 不要修改任何文件，也不要做"精简"（例如裁剪备份时把 Brave 目录删掉——本次事故的伏笔就是裁剪备份时以为"已恢复"而删了 Brave 目录，事后只剩 原始备份包 里的副本）。

一句话：关浏览器、全量拷 User Data、一个字节都不要改、备份别裁剪。

三、恢复的正确姿势（事后，实战验证版）

#

第 0 步：认清现实

#

重装系统后从备份回拷，扩展注册必丢（机制 4）。目标不是"整体回拷免重置"，而是：

1. 恢复数据（LES / IndexedDB / Local Storage / Sessions——都不受 MAC 保护，可从备份任意合并）
2. 重新安装扩展本体（唯一正道：Chrome 商店，见下）

第 1 步：恢复数据目录（任意合并，安全）

#

关闭浏览器后，从备份把缺失的数据目录拷回（robocopy 合并，只补不删）：

Local Extension Settings\   ← 扩展设置/chrome.storage（重置会删部分，卸载会删全部）
IndexedDB\                  ← 扩展数据库（站点/脚本数据等）
Local Storage\              ← 站点本地存储
Sessions\ + Session Storage\ ← 标签页快照（若当前已恢复会话可跳过）

不要碰 Secure Preferences（MAC 保护区）和 Extensions\（放未注册本体 = 触发重置）。

第 2 步：商店重装扩展（唯一正道）

#

扩展 ID 由 manifest 里的 key（公钥）派生（SHA256(key) 前 16 字节，每字节高低 nibble 映射 a-p，共 32 字符）。商店扩展的 ID 是稳定公开的 → 从商店重新安装，ID 必然与原来相同 → 已恢复的 Local Extension Settings / IndexedDB 数据自动挂载（Chrome 按 ID 找数据目录）。

操作（每个扩展）： 1. 打开商店直链 https://chromewebstore.google.com/detail/<扩展ID> 2. 点「添加到 Brave」（或"添加至 Chrome"） 3. 点 Brave 弹出的「添加扩展程序」确认框 ← 这一步只能手动点，任何自动化都点不了浏览器 UI 弹窗 4. 验证：打开扩展面板/设置页，没有欢迎页 = 数据完整挂载

商店安装 = 正常扩展（自动更新、无特殊状态）。ID 相同的商店版会直接挂载旧数据目录里的数据。

第 3 步：验证

#

• chrome://extensions 列表里扩展齐全、无"已损坏"标记
• 打开每个扩展的设置页：配置/脚本/数据在（无欢迎页、无空白）
• 固定标签页：手动重新固定（防篡改保护区内，不值得硬碰）

四、本次实战的完整踩坑记录（目标 Profile 恢复全历程）

#

背景：8/28 恢复时 其余三个 profile 的扩展本体拷回了，目标 Profile 的 Extensions\ 漏拷（空目录）。8/31 第一次打开目标 Profile → 注册 10 条 vs 本体 0 个 → 触发重置 → 注册清空（只剩 2 个内置）+ 删空目录。用户看到"扩展记录消失"。

以下方案全部实测失败，勿再尝试：

最终成功路径：数据目录从备份恢复（LES + IndexedDB）→ 用户手动商店安装 5 个扩展 → 数据自动挂载（扩展数据完整回归）。全程唯一需要用户动手的就是点确认弹窗。

其他实战细节： - 固实/非固实压缩包 提取单文件用 UnRAR.exe e -y -idq <rar> <精确路径> <dest>\，python subprocess 传参避免 shell 转义地狱；路径前缀匹配必须单反斜杠 - 验证运行时扩展状态用 CDP：brave.exe --profile-directory="Profile N" --remote-debugging-port=9333 --remote-allow-origins=*，然后在 chrome://extensions 页面上下文执行 chrome.management.getAll()（商店页面等普通页面没有该权限，返回空不代表没装） - install_signature.ids（Preferences 里，不受保护）是扩展 ID 的可靠参照，可用于核对应恢复哪些扩展

五、常见的错误做法（避雷表·扩充版）

#

六、一图流速查

#

备份：关浏览器 → 整体拷 User Data → 校验大小文件数 → 存档（别裁剪）
重装后恢复：
  1) 关浏览器 → 合并拷回数据目录（LES/IndexedDB/Local Storage/Sessions）
     ⚠️ 不要碰 Secure Preferences 和 Extensions\
  2) 打开浏览器（扩展注册已被重置，只剩内置 —— 正常现象）
  3) 逐个商店重装扩展（https://chromewebstore.google.com/detail/<扩展ID>）
     → 点「添加到 Brave」→ 点确认弹窗「添加扩展程序」（必须手动）
  4) 打开扩展设置页：无欢迎页、数据在 = 完成
确认一切正常 → 才删除备份

七、最后的碎碎念

#

浏览器数据是最珍贵的数字资产：书签是索引，密码是钥匙，标签页是"我还没读完的世界"，扩展是生产力。重装系统前花十分钟按上面的姿势备份，重装后就不会经历"安全原因"四个字带来的心跳骤停。

记住四件事：Local State 必须一起拷；Secure Preferences 一个字节都别改；扩展注册必丢是机制使然，数据目录才是要救的；扩展本体用商店重装（ID 不变 → 数据自动挂载），确认弹窗手动点。