随手记

macOS 上用 dd 制作 Windows 安装 U 盘后提示缺少驱动的原因

Fri, 12 Jun 2026 00:00:00 +0800

最近在 macOS 上制作 Windows 安装 U 盘时踩了一个坑：用 dd 把 Windows ISO 原样写进 U 盘后，机器可以从 U 盘启动，也能进入 Windows 安装界面，但安装器很快提示缺少驱动，或者在选择安装位置之前就卡在“Install Driver to Show Hardware / 缺少介质驱动程序”这一类界面。

这个现象和 TaurusXin 记录的那篇文章很像。他遇到的是用 Etcher 写 Windows 安装盘后，安装器提示缺少驱动；我这里换成 macOS 下的 dd，结果仍然类似。表面看像是 NVMe、RST、VMD、USB 控制器驱动问题，实际更可能是启动 U 盘的制作方式不适合 Windows 安装 ISO。

后面实测可行的方案是：在 macOS 上改用 WinDiskWriter 重新制作 U 盘，并勾选 Patch Installer Requirements 和 Install Legacy BIOS Boot Sector，重新引导后就可以继续正常安装。

现象：能启动，但安装器继续读不到安装文件

典型过程是这样的：

# 示例：不要照抄执行，diskN 必须先确认清楚
sudo diskutil unmountDisk /dev/diskN
sudo dd if=Win11.iso of=/dev/rdiskN bs=4m status=progress
sync

写完之后，U 盘看起来已经“烧录成功”：

BiRefNet 深度解读：从图片分割到镜架边缘形态优化

Tue, 09 Jun 2026 00:00:00 +0800

开头：BiRefNet 到底在做什么

BiRefNet 可以先粗略理解成一个高质量前景分割模型。它拿到一张图片之后，不是直接输出一张透明 PNG，而是先输出一张 mask：

白色区域：要保留的主体
黑色区域：要删除的背景
灰色区域：边缘、不确定或半透明过渡

如果我们要做商品抠图，最终流程通常是：

原始图片
↓
BiRefNet 预测 mask
↓
mask 作为 alpha 通道
↓
得到透明背景 PNG

比如一副眼镜放在白色桌面上，BiRefNet 要判断每个像素属于眼镜还是背景。真正的难点不在于“整副眼镜在哪里”，而在于鼻托、镜腿、镜框内侧边缘、镜片孔洞这些细节是否干净、连续、圆润。

这篇文章按一个完全不懂深度学习的人也能理解的方式，解释 BiRefNet 的工作链路，并重点讨论一个很实际的问题：如果模型整体已经抠得很准，但镜架鼻托边缘还有毛刺和不规整，下一步应该怎么修。

总览：BiRefNet 的基本分工

可以先把 BiRefNet 拆成两个大部分：

图片
↓
backbone：提取视觉特征
↓
decoder / refinement：融合特征并生成 mask
↓
输出前景 mask

更通俗一点：

backbone = 看图并提取证据
decoder = 根据证据画出最终 mask

backbone 不直接输出“这个像素是前景、那个像素是背景”。它输出的是很多层特征图。decoder 才负责把这些特征图融合起来，变成最终可用的分割结果。

Backbone：不是空模型，而是视觉特征提取器

很多人第一次听到 backbone，会以为它是一个空权重模型。其实不是。

backbone 是整个网络里的视觉主干，它负责把原始 RGB 像素转换成模型内部能理解的特征。以一张 1024x1024 图片为例，原始输入大概是：

[3, 1024, 1024]

这里的 3 是 RGB 三个颜色通道。进入 backbone 后，它可能输出多层特征：

USB 转 SATA / NVMe 桥接芯片在 Linux 下的兼容性对比

Fri, 22 May 2026 00:00:00 +0800

很多 2.5 寸硬盘盒、M.2 SATA 硬盘盒、M.2 NVMe 硬盘盒看起来只是“USB 外置硬盘”，但真正决定 Linux 体验的，经常是里面那颗 USB 桥接芯片和它的固件。

同一块 SSD，换一个桥接芯片，可能会出现完全不同的结果：一个盒子能跑 UASP、能 fstrim、能读 SMART；另一个盒子只跑 usb-storage，或者大文件写入时反复 USB reset。本文把常见的 ASMedia ASM1153E、JMicron JMS 系列、Realtek RTL 系列放在一起，对 Linux 下的兼容性做一个偏实用的对比。

先给结论

如果只是给 2.5 寸 SATA SSD/HDD 做 USB 外置盒，ASM1153E 和 JMS578 都很常见，也都支持 UASP。ASM1153E 的整体口碑偏稳，但 TRIM/SMART 仍然受固件影响；JMS578 功能完整、价格低、出货量大，但不同固件之间差异明显。

如果是 NVMe 转 USB，JMS583 和 RTL9210/RTL9210B 是常见选择。JMS583 是早期大量普及的 USB 3.1 Gen2 转 NVMe 桥，规格漂亮，但旧固件、散热和某些主机组合下更容易遇到掉盘或重置；RTL9210/RTL9210B 后来在很多硬盘盒里成为更常见的“稳妥选择”，但也不是免疫，仍然要看固件版本和具体硬盘。

Linux 下不要只看商品页写的“支持 UASP / 支持 TRIM”。更可靠的判断顺序是：

USB-SATA 桥接芯片的 UAS 兼容性问题排查

Wed, 20 May 2026 09:30:04 +0800

通过 USB 外接硬盘时，如果遇到磁盘看起来一直很忙，但实际吞吐很低，问题不一定出在文件系统或硬盘本体上。一次比较典型的场景是：USB-SATA 桥接芯片声称支持 UAS，但它的固件实现不稳定，Linux 自动启用 UAS 后反而触发命令超时、USB 设备重置，最终表现成系统层面的 I/O 卡顿。

这篇文章记录一次这类问题的现象、原因和处理方式。

问题现象

故障最直观的表现是：外接硬盘几乎不可用，但监控上又看不出正常的高吞吐。

常见现象包括：

iostat 中磁盘 %util 长时间接近或等于 100%；
实际 r/s、w/s、rkB/s、wkB/s 并不高；
await、svctm 或应用侧读写延迟异常升高；
文件复制、解压、数据库读写、备份任务间歇性卡住；
偶尔出现 Input/output error；
dmesg 或 journalctl -k 中反复出现 UAS abort、SCSI timeout、USB reset。

可以先用下面这些命令观察：

iostat -xz 1

dmesg -T | grep -Ei 'uas|usb|reset|abort|I/O error|blk_update_request'

journalctl -k -b | grep -Ei 'uas|usb|reset|abort|I/O error'

比较典型的内核日志类似这样：

uas_eh_abort_handler ...
scsi host... uas_eh_device_reset_handler
usb ... reset SuperSpeed USB device number ...
blk_update_request: I/O error, dev sdX, sector ...

如果这些日志和外接硬盘卡顿时间点高度重合，就要怀疑 USB 存储协议层的问题。

在 Docker 中部署 mihomo，并让本机与局域网电脑接入

Tue, 19 May 2026 00:00:00 +0800

mihomo 是 Clash.Meta 的延续版本，常见用法是把它作为一个代理内核运行在一台长期在线的机器上，然后让本机、手机、Windows 电脑、Linux 电脑都通过这台机器访问代理服务。

这篇文章记录一个最实用的部署方式：在 Docker 里运行 mihomo，宿主机负责提供端口，局域网里的其他设备只需要把 HTTP / SOCKS 代理指向这台机器即可。

总览：先看整体链路

假设运行 Docker 的机器局域网 IP 是 192.168.1.10，mihomo 在这台机器上监听 7890 端口：

Windows / Linux / 手机
 |
 | HTTP / SOCKS 代理：192.168.1.10:7890
 v
Docker 宿主机：192.168.1.10
 |
 | mihomo 容器
 v
按规则直连或走代理节点

关键点只有三个：

mihomo 配置里开启 allow-lan: true。
mihomo 监听地址使用 bind-address: "*" 或宿主机局域网 IP。
Docker 把 7890 端口暴露给局域网。

第一步：准备目录

在准备用作代理网关的机器上创建目录：

mkdir -p ~/mihomo/config
cd ~/mihomo

后面所有文件都放在 ~/mihomo 目录里：

客户端、Skill 与 MCP：大模型如何调用本地能力

Sat, 16 May 2026 08:35:00 +0800

很多人第一次接触大模型工具调用时，容易把几个角色混在一起：大模型是不是直接读取了本地文件？Skill 是不是一个可执行插件？MCP Server 是不是直接连到了模型？

实际链路更清晰，也更安全：模型只看见客户端发给它的上下文和工具定义；真正访问本地文件、数据库、命令行或服务的是客户端；MCP 是客户端调用本地能力的一种标准接口；调用结果再被客户端作为新消息发回模型。

总览：先看完整链路

一次完整交互可以拆成四步：

客户端读取用户问题，并加载本地 Skill、系统提示词、可用工具列表。
客户端把这些信息整理成一次模型请求，发给大模型。
大模型判断需要调用工具时，不直接执行本地动作，而是返回一个 tool_call 请求。
客户端根据 tool_call 调用本地 MCP Server，把结果作为 tool 消息回填给模型，模型再基于结果继续回答。

这里最重要的边界是：模型提出“我要调用什么”，客户端决定“能不能调用、怎么调用、结果如何回传”。

Skill 是什么：给模型看的操作说明

Skill 可以理解成一份本地能力说明书。它通常不是让模型直接执行的程序，而是一组面向模型的规则、流程、约定和示例。

例如，一个写博客的 Skill 可能告诉模型：

# Blog Writing Skill

- 写中文技术文章。
- 文件名必须是英文小写 slug。
- 创建文章前先读取已有标签。
- 图片必须通过 blog MCP 上传。
- 创建后再次读取文章确认 frontmatter 和图片引用。

客户端在发起模型请求前，会把匹配到的 Skill 内容放进上下文。于是模型知道：当前任务不是随便写一段 Markdown，而是要按照这个博客系统的规范完成“查标签、写正文、上传图片、创建文章、验证结果”这些步骤。

注意，Skill 本身不等于工具。它更像操作手册：告诉模型什么时候应该做什么、输出应该长什么样、有哪些约束不能违反。

MCP 是什么：给客户端调用的本地能力接口

MCP Server 则更接近真正的本地工具提供者。它把本地能力包装成结构化接口，比如：

{
 "name": "blog.create_post",
 "description": "创建一篇 Hugo 博客文章",
 "input_schema": {
 "type": "object",
 "properties": {
 "title": { "type": "string" },
 "content": { "type": "string" },
 "tags": {
 "type": "array",
 "items": { "type": "string" }
 },
 "draft": { "type": "boolean" }
 },
 "required": ["title", "content"]
 }
}

客户端启动或连接 MCP Server 后，会拿到这些工具定义。随后客户端可以把工具名、描述和参数结构告诉模型，让模型知道有哪些工具可用。

在 macOS 上打包 Windows EXE 的好办法：用 GitHub Actions 自动编译

Fri, 15 May 2026 12:00:00 +0800

如果你平时在 macOS 上写 Python 脚本、桌面小工具或命令行工具，最后却要发给 Windows 用户使用，最容易遇到的问题就是：我能不能直接在 Mac 上打包出 .exe？

结论先说清楚：不建议在 macOS 本机强行交叉打包 Windows EXE。更稳的办法是把代码推到 GitHub，让 GitHub Actions 在 Windows 环境里自动打包。

这篇文章按使用教程来写，从准备项目、创建 workflow、触发构建、下载产物，到常见问题排查，完整走一遍。

总览：为什么要用 GitHub Actions 打包 EXE

PyInstaller 这类打包工具通常不是“万能交叉编译器”。也就是说：

要打 Windows .exe，最好在 Windows 上运行打包命令。
要打 macOS 应用，就在 macOS 上打。
要打 Linux 可执行文件，就在 Linux 上打。

这不是 GitHub Actions 的特殊限制，而是很多 Python 原生依赖、动态库、运行时文件和系统 API 都跟目标操作系统绑定。你在 macOS 上直接打包，得到的通常是 macOS 可执行文件，而不是 Windows 真正可用的 .exe。

GitHub Actions 的思路是：

macOS 本地开发
 -> git push 到 GitHub
 -> GitHub Actions 启动 Windows Runner
 -> 安装 Python 和依赖
 -> 执行 PyInstaller
 -> 上传 exe 产物
 -> 在 Actions 页面下载

这样做的好处是：

从标量、向量到张量：深度学习里的“数字容器”到底是什么？

Thu, 14 May 2026 09:55:14 +0800

刚接触深度学习时，很多人会被一堆词劝退：标量、向量、矩阵、张量、维度、形状、通道、批次……这些词看起来像数学课，其实它们背后的核心很简单：深度学习处理的东西，本质上是一堆数字；这些概念只是说明数字被怎样摆放。

你可以先把它们理解成不同大小、不同结构的“数字容器”：

标量：一个数字。
向量：一排数字。
矩阵：一张表格。
张量：更通用的多维数字容器。

这篇文章不要求你有高等数学基础。我们只抓住一个目标：以后看到 shape = (32, 3, 224, 224) 这种写法时，你知道它大概在说什么。

先建立直觉：模型只认识数字

人看到一张猫的图片，会说“这是一只猫”。但神经网络不能直接理解“猫”这个字，也不能像人一样直接理解图像含义。它真正拿到的是数字。

比如一张图片，在计算机里通常可以表示成很多像素点；每个像素点又可以用数字表示颜色。文本、声音、表格数据也一样，最后都要转成数字，模型才能计算。

所以深度学习里的问题，经常会变成：

这些数字怎么组织？模型每一步拿到的数字长什么样？

这就是标量、向量、矩阵、张量这些概念的用处。

标量：一个单独的数字

标量就是一个数。

例如：

3
0.01
-2.7

在深度学习中，很多结果都是标量：

学习率 0.001 是一个标量。
某次训练的损失值 1.26 是一个标量。
一个分类结果的概率 0.87 也可以是一个标量。

标量没有方向，也没有一排、一列、几行几列这些结构。它就是一个孤零零的数字。

如果用“维度”来描述，标量通常可以理解为 0 维。这里的 0 维不是说它不重要，而是说它没有展开成列表或表格。

向量：一排数字

向量是一组按顺序排好的数字。

例如：

[170, 65, 23]

你可以把它理解成一个人的三个特征：身高 170、体重 65、年龄 23。单个数字只能表达一个量，一排数字就可以一起描述一个对象。

在机器学习里，一个样本经常会被表示成一个向量：

[面积, 卧室数量, 楼层, 距离地铁距离]

如果我们要预测房价，就可以把每套房子变成这样一排数字。模型拿到的不是“这套房子不错”这种自然语言，而是一组可以计算的数。

向量通常可以理解为 1 维。这里的 1 维指的是它只有一个方向可以数：从左到右数第 1 个、第 2 个、第 3 个……

RapidOCR 入门：英文 OCR 识别、常规测评与使用注意事项

Wed, 06 May 2026 11:17:28 +0800

OCR 这类工具最容易被误用：看起来只要把图片丢进去就能得到文字，但真正放到项目里时，还会遇到图片质量、方向、字体、语言、速度、批量处理和错误纠正等问题。本文以一个最小的 RapidOCR 英文识别项目为例，整理它适合做什么、怎么跑起来、怎么做常规测评，以及使用时需要注意哪些细节。

本文不是完整排行榜式横向评测，而是偏工程落地的使用说明：先让脚本能稳定运行，再用一组可复现的指标判断它是否满足当前业务。

RapidOCR 是什么

RapidOCR 可以理解为一个轻量级 OCR 推理方案。当前示例项目使用的是 rapidocr-onnxruntime==1.2.3，底层通过 ONNX Runtime 执行 OCR 模型推理，典型链路包括：

文本检测：先在图片中找出可能包含文字的区域。
方向分类：判断文本是否需要旋转或方向修正。
文本识别：对检测出来的文字区域逐行识别。
结果整理：输出文本框、文字内容和置信度等结果。

在这个项目里，我们只保留最常用的输出：把图片中的文字逐行打印出来。它适合做轻量脚本、批处理、小工具、后台任务，也适合在正式接入大系统前做 OCR 方案验证。

适用场景

RapidOCR 更适合这些场景：

识别清晰图片里的英文、数字、短标签、票据字段、车牌周边信息等。
在本地或服务器上离线运行，不想依赖外部 OCR API。
希望用 Python 快速接入，先验证效果，再决定是否封装成服务。
对部署体积、调用方式、推理依赖有一定要求，希望用 ONNX Runtime 这类通用推理后端。

它不太适合直接裸用在这些场景：

图片严重模糊、过曝、反光、压缩严重。
版面复杂，需要结构化还原表格、段落、字段层级。
需要极高准确率的财务、证件、合同等强校验场景。
需要直接理解语义，而不只是把图片转成文字。

这些场景不是不能做，而是要加预处理、后处理、规则校验，甚至引入专门模型或人工复核流程。

最小项目结构

当前项目可以保持很简单：

rapidOCR/
├── README.md
├── ocr.py
├── IMG_20260506_110642.jpg
├── IMG_20260506_110656.jpg
└── venv/

核心脚本 ocr.py 的职责很清楚：接收一张图片路径，调用 RapidOCR，然后把识别出的每行文字打印出来。

import argparse
from rapidocr_onnxruntime import RapidOCR


def main():
 parser = argparse.ArgumentParser(description="OCR text recognition using RapidOCR")
 parser.add_argument("--input", required=True, help="Path to input image file")
 args = parser.parse_args()

 engine = RapidOCR()
 result, _ = engine(args.input)

 if not result:
 print("No text detected.")
 return

 for line in result:
 print(line[1])


if __name__ == "__main__":
 main()

这里的 result 通常包含文本框坐标、识别文本、置信度等信息。示例脚本只打印 line[1]，也就是文字内容。如果后续要做测评或业务校验，建议保留完整结果，不要过早只取纯文本。

Docker 日常维护、运行调试与排错教程：从 Compose 到 Swarm

Wed, 29 Apr 2026 16:25:00 +0800

Docker 用久以后，问题通常不在“会不会启动一个容器”，而在日常维护和排错：容器为什么退出、日志在哪里看、端口为什么不通、磁盘为什么爆了、Compose 更新为什么没生效、Swarm 服务为什么一直 Pending。

这篇文章按实际运维顺序整理：先看单机 Docker 的容器、镜像、日志、网络、存储和资源排查，再看 Compose 的项目级管理，最后看 Swarm 的集群级服务维护。

总览：Docker 排错先分清三种运行层级

Docker 相关问题先不要急着敲命令，先判断当前应用跑在哪一层：

层级	常见命令	管理对象	适合场景
单机 Docker	`docker run`、`docker ps`、`docker logs`	container、image、volume、network	单机服务、临时调试、本地开发
Docker Compose	`docker compose up`、`docker compose logs`	一个项目里的多服务	开发环境、小型部署、依赖编排
Docker Swarm	`docker service`、`docker stack`、`docker node`	service、task、stack、node	多节点集群、滚动更新、副本调度

排错时也按这个顺序看：

服务不可用
 -> 容器是否存在、是否在运行
 -> 日志里有没有启动失败或业务异常
 -> 端口映射和网络是否正确
 -> volume、配置、环境变量是否正确
 -> CPU、内存、磁盘是否打满
 -> 如果是 Compose，看 project/service 维度
 -> 如果是 Swarm，看 node/service/task 维度

一、日常巡检：先看 Docker 基本状态

先确认 Docker daemon 是否正常：

大模型周边概念速通：MCP、Skill、Agent、Tool 到底是什么

Wed, 29 Apr 2026 16:05:00 +0800

大模型应用发展到现在，很多词会一起出现：MCP、Skill、Agent、Tool、Prompt、Resource、Memory、Guardrail、Handoff、Plugin、Connector。它们看起来都像“给 AI 增强能力”的东西，但实际所在的层级完全不同。

如果把大模型应用想成一个软件系统：大模型负责理解和生成，Agent 负责决策和调度，Tool 负责执行动作，MCP 负责把外部能力标准化接进来，Skill 负责沉淀一套可复用的任务方法。理解这些边界之后，再看各种 AI IDE、智能客服、自动化助手、博客发布机器人，就不会被概念绕晕。

总览：先看一条完整链路

一次典型的大模型应用调用，可以拆成这条链路：

用户请求
 -> 应用 / Agent
 -> 组装 Prompt、历史记录、上下文 Resource、Memory
 -> 调用大模型
 -> 大模型决定是否调用 Tool
 -> Tool 可能来自本地代码、平台内置能力，或 MCP Server
 -> 工具返回结果
 -> Agent 继续推理、校验、生成最终回答

这里最容易混淆的是三层：

层级	解决的问题	典型概念
模型层	负责语言理解、推理、生成	LLM、大模型、多模态模型
编排层	决定怎么完成任务	Agent、Prompt、Memory、Guardrail、Handoff
能力接入层	连接外部数据和动作	Tool、MCP、Resource、Connector、Plugin、Skill

一句话概括：大模型是大脑，Agent 是工作流控制器，Tool 是手，MCP 是标准插口，Skill 是做事手册和工具包。

大模型：能力核心，但不是完整应用

大模型，也就是 LLM 或多模态模型，核心能力是根据上下文预测和生成内容。它可以读文字、写代码、解释日志、分析图片、生成计划，但它本身通常不直接拥有你的文件系统、数据库、浏览器、Git 仓库、公司内部系统权限。

所以，大模型应用真正要解决的是：

给模型什么上下文。
允许模型调用哪些能力。
模型何时该自己回答，何时该查数据或执行动作。
工具调用前后如何校验安全性和结果质量。
多步骤任务失败时如何恢复。

这就是 Agent、Tool、MCP、Skill 等概念出现的原因。

Spring Boot 核心功能介绍：从启动应用到生产部署

Wed, 29 Apr 2026 15:40:00 +0800

Spring Boot 的目标不是替代 Spring，而是让 Spring 应用更容易启动、配置、运行和交付。它把大量常见选择做成默认约定：依赖怎么选、Tomcat 怎么启动、JSON 怎么序列化、配置从哪里读取、健康检查怎么暴露、应用如何打成可执行 Jar。

本文不做百科式穷举。Spring Boot 覆盖 Web、数据访问、消息、缓存、安全、可观测性、测试、容器镜像、AOT、原生镜像等很多方向，全部展开会变成官方手册。这里聚焦日常 Java 后端项目最常用、最值得先掌握的核心功能。

总览：Spring Boot 解决什么问题

一个传统 Spring 项目通常要先处理很多基础工作：引入一堆依赖、配置 DispatcherServlet、配置 JSON、配置数据源、配置事务、配置日志、配置打包方式。Spring Boot 把这些重复工作收敛成三件事：

用 Starter 组织依赖，例如 spring-boot-starter-web、spring-boot-starter-data-jpa。
用自动配置根据 classpath 和配置文件创建合适的 Bean。
用生产级能力补齐健康检查、指标、日志、外部化配置和可执行包。

最小应用大概是这样：

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {
 public static void main(String[] args) {
 SpringApplication.run(DemoApplication.class, args);
 }
}

@SpringBootApplication 通常可以理解为三个能力的组合：组件扫描、配置类声明、自动配置入口。也就是说，项目启动后，Spring Boot 会扫描你的 Controller、Service、Repository，并按条件装配 Web、JSON、数据库、事务、日志等基础设施。

1. Starter：把常用依赖打包成入口

Starter 是 Spring Boot 的第一层体验优化。你不需要自己逐个判断 Spring MVC、Jackson、Tomcat、Validation 等依赖的兼容版本，只要引入对应 Starter。

一次 HTTP 请求的完整旅程：从浏览器到 Nginx 再到后端服务

Wed, 29 Apr 2026 15:05:00 +0800

我们在浏览器里输入一个网址，比如：

https://www.example.com/api/users

看起来只是按下回车，页面就返回了。但在这几百毫秒甚至几十毫秒里，浏览器、操作系统、DNS、TCP、TLS、Nginx、后端应用、数据库和缓存可能都参与了一次协作。

这篇文章按时间顺序，把一次典型的 HTTPS 请求完整拆开：从浏览器发起请求，到 TCP 三次握手、TLS 密钥协商，再到 Nginx 接收连接、反向代理给后端服务，最后响应返回浏览器。

总览：请求链路长什么样

可以先看一个简化版流程图：

用户输入 URL
 │
 ▼
浏览器解析 URL
 │
 ▼
DNS 解析域名 -> 得到服务器 IP
 │
 ▼
TCP 三次握手 -> 建立可靠连接
 │
 ▼
TLS 握手/密钥协商 -> 建立加密通道
 │
 ▼
浏览器发送 HTTP 请求
 │
 ▼
Nginx 接收请求
 │
 ├─ 匹配 server_name
 ├─ 匹配 location
 ├─ 处理静态资源 / gzip / header / 日志
 │
 ▼
proxy_pass 反向代理到后端应用
 │
 ▼
后端应用处理业务逻辑
 │
 ▼
后端返回 HTTP 响应
 │
 ▼
Nginx 返回响应给浏览器
 │
 ▼
浏览器解析 HTML/CSS/JS 并渲染页面

实际生产环境里，中间还可能有 CDN、负载均衡、WAF、Service Mesh、网关、缓存、队列、数据库等组件。但核心路径大体就是上面这些层次。

MySQL B+ Tree 机制与算法详解

Wed, 29 Apr 2026 00:00:00 +0800

为什么数据库普遍选择 B+ Tree

如果只从算法课本看，查找一个有序集合有很多选择：数组可以二分，哈希表可以做到平均 O(1)，红黑树、AVL 树可以做到 O(logN)。但数据库的核心问题不是“CPU 内存里怎么找”，而是“磁盘或 SSD 上的数据怎么少读几次”。

MySQL 的 InnoDB 存储引擎把表数据和索引组织成页。默认情况下，一个页通常是 16KB。一次查询如果每深入一层索引就需要读取一个页，那么树的高度越低，I/O 次数就越少。B+ Tree 的核心优势就在这里：

每个节点能存放很多 key，树的分叉数很大，高度很低。
所有真实记录都在叶子节点，非叶子节点只负责导航。
叶子节点之间按 key 顺序连接，非常适合范围查询和排序扫描。
节点大小天然适合数据库页，可以和磁盘读写单位对齐。

所以，B+ Tree 不是为了在理论复杂度上压倒所有结构，而是为了适配数据库最昂贵的资源：随机 I/O。

从二叉树到 B+ Tree

普通二叉搜索树每个节点最多两个孩子。即使它保持平衡，一千万条数据的高度也大约是二十多层。放在内存里问题不大，放在数据库里就意味着一次查找可能触发很多次随机页读取。

B Tree 和 B+ Tree 解决的是“分叉太少”的问题。一个节点可以保存多个 key 和多个孩子指针。例如节点中有这些分隔 key：

[10 | 20 | 30]

它可以把搜索空间分成四段：

(-∞, 10) [10, 20) [20, 30) [30, +∞)

这样，一个节点不是二选一，而是多路分发。只要一个页中能放下足够多的 key 和指针，树的高度就会非常低。

B+ Tree 相比 B Tree 又进一步做了一个重要取舍：非叶子节点不存放完整数据记录，只存放用于导航的 key 和子节点页号；所有完整记录都放在叶子节点。这样非叶子节点更小，能容纳更多 key，树也就更矮。

B+ Tree 的基本结构

一棵典型 B+ Tree 可以分成三类节点：

MySQL 各个模块与核心机制：从一条 SQL 理解数据库原理

Tue, 28 Apr 2026 18:05:26 +0800

MySQL 是最常见的关系型数据库之一。很多人一开始使用 MySQL，关注的是如何写 SELECT、INSERT、UPDATE、DELETE，但如果想进一步理解性能优化、事务一致性、主从复制、锁等待、索引失效等问题，就需要了解 MySQL 内部由哪些模块组成，以及这些模块之间如何协作。

本文会以科普的方式讲解 MySQL 的整体架构、核心模块和重要机制。你不需要先成为数据库内核开发者，也可以建立一套清晰的理解框架。

1. MySQL 的整体架构

可以把 MySQL 大致分成两层：

客户端
 |
连接层
 |
SQL 层：解析器、预处理器、优化器、执行器、权限检查、函数、视图、触发器等
 |
存储引擎层：InnoDB、MyISAM、Memory 等
 |
磁盘文件与操作系统

其中最重要的设计点是：MySQL 的 SQL 层和存储引擎层是分离的。

SQL 层负责理解 SQL、检查权限、生成执行计划、调用存储引擎接口。存储引擎层负责真正的数据读写、索引组织、事务、锁、崩溃恢复等底层工作。

这也是为什么 MySQL 可以支持不同存储引擎。最常用的是 InnoDB，它是现代 MySQL 默认存储引擎，支持事务、行级锁、MVCC、崩溃恢复等关键能力。

2. 连接层：客户端如何连上 MySQL

当应用程序连接 MySQL 时，首先经过连接层。

连接层主要负责：

建立连接
认证用户名和密码
检查客户端权限
维护连接状态
处理连接线程
管理连接超时

常见连接方式包括 TCP 连接和 Unix Socket 连接。

例如应用程序使用如下连接信息：

host=127.0.0.1
port=3306
user=app_user
password=******
database=app_db

MySQL 会先验证账号密码，再根据权限表判断用户是否有访问某个库、表、列或执行某类操作的权限。

Linux 各个目录的作用：从根目录理解系统结构

Tue, 28 Apr 2026 17:53:07 +0800

如果你刚开始接触 Linux，打开终端输入 ls /，会看到一组看起来很固定的目录：bin、etc、home、usr、var、proc、dev 等。它们不是随意命名的文件夹，而是 Linux 系统长期演化出来的一套目录分工。

理解这些目录的作用，有助于你知道配置文件在哪里、日志在哪里、用户数据在哪里、程序通常安装在哪里，也能避免误删系统关键文件。本文会以 Linux 根目录 / 为起点，逐一讲解常见目录的用途。

1. `/`：根目录，所有路径的起点

Linux 的文件系统是一个单一的树状结构，最顶层就是 /，也叫根目录。

无论是系统文件、用户文件、磁盘分区、U 盘、网络挂载目录，最终都会挂载到这棵目录树的某个位置。和 Windows 常见的 C:、D: 盘符不同，Linux 更强调“从 / 开始的一棵树”。

例如：

/etc/ssh/sshd_config
/home/alice/document.txt
/var/log/syslog

这些路径都从 / 开始。

日常使用时，不建议直接在 / 下随意创建文件或目录。根目录通常只放系统约定好的一级目录。

2. `/bin`：基础命令目录

/bin 用来存放系统启动和基本维护所需的常用命令。

常见命令包括：

ls
cp
mv
rm
cat
mkdir
sh

这些命令是系统最基础的工具，即使系统处在较小的维护环境中，也通常需要它们。

在一些现代 Linux 发行版中，/bin 可能只是一个指向 /usr/bin 的符号链接。这是因为许多发行版已经采用了 /usr 合并的目录布局，但从使用者角度看，/bin 仍然可以理解为“基础命令所在的位置”。

3. `/sbin`：系统管理命令目录

/sbin 中通常存放系统管理相关命令，很多命令主要供 root 用户或系统管理员使用。

常见命令包括：

ip
reboot
shutdown
fsck
mount

其中不少命令和系统启动、磁盘检查、网络配置、关机重启有关。

Fail2Ban 工作原理与常用运维操作

Tue, 28 Apr 2026 17:35:00 +0800

Fail2Ban 是 Linux 服务器上很常见的一类安全防护工具，主要用来应对 SSH、Web 登录、邮件服务等场景里的暴力破解和重复异常请求。它不会替代防火墙、密钥登录、最小权限这些基础安全措施，但非常适合做一层自动化封禁：发现某个 IP 在短时间内频繁失败，就把它临时加入黑名单，过一段时间后再自动释放。

这篇记录一下 Fail2Ban 的工作原理、安装和开机启动方式、常用规则配置，以及误封后如何把某个 IP 从黑名单里移出来。

Fail2Ban 的工作原理

Fail2Ban 的核心逻辑可以概括成四步：

监听日志文件或 systemd journal。
用 filter 里的正则表达式匹配失败行为。
在指定时间窗口内统计同一个 IP 的失败次数。
达到阈值后执行 action，把 IP 加入防火墙黑名单。

这里有几个关键概念。

jail

jail 是 Fail2Ban 的规则单元。一个 jail 通常对应一个服务，例如 SSH、Nginx、Postfix、Dovecot 等。每个 jail 会指定：

监控哪个服务。
读取哪个日志。
使用哪个 filter。
允许失败多少次。
统计时间窗口是多少。
封禁多久。
使用什么 action 封禁 IP。

例如 SSH 的 jail 就是监听 SSH 登录日志，匹配登录失败记录，当同一个 IP 在一段时间内失败太多，就通过防火墙封禁。

filter

filter 负责识别“什么日志算失败”。它通常放在：

/etc/fail2ban/filter.d/

例如 SSH 常见 filter 是：

用 MCP 管理 Hugo 博客：这个项目是怎么搭起来的

Tue, 28 Apr 2026 16:45:00 +0800

这个仓库表面上是一个很轻量的 Hugo 博客，实际目标更明确：把博客内容、构建部署、以及 AI 写作入口放在同一个工程里。最终形成的工作流是：文章仍然以 Markdown 存在仓库中，Hugo 负责生成静态站点，仓库流水线负责构建部署，而 mcp/ 目录里的 MCP 服务负责给 AI 提供一组可控的读写工具。

项目目标

这个项目解决的是一个很具体的问题：写博客时不想每次都手动打开仓库、创建 frontmatter、提交文章、再等待部署。更理想的方式是直接和 AI 对话，让 AI 能够读取已有文章、理解站点配置、创建新文章、修改元数据，必要时还能上传图片。

为了不把 AI 直接暴露给整个文件系统，项目没有设计成“随便执行命令”的形式，而是把能力收敛成 MCP 工具。每个工具只做一件事，例如列文章、读文章、创建文章、更新文章、上传图片。这样既方便使用，也比较容易控制边界。

顶层结构

当前仓库大致分成几块：

.
├── hugo.toml # Hugo 站点配置
├── content/ # 博客内容
│ ├── about.md
│ └── posts/ # Markdown 文章目录
├── layouts/partials/ # 本站覆盖的局部模板
├── themes/terminal/ # Hugo terminal 主题
├── .github/workflows/ # 构建与部署流水线
└── mcp/ # 自定义 blog MCP 服务

hugo.toml 定义站点基础信息，例如语言、标题、主题、分页和菜单。文章目录使用 Hugo 默认的 content/posts。内容层仍然保持 Hugo 最朴素的方式：每篇文章是一个 Markdown 文件，文件头部用 TOML frontmatter 描述标题、日期、标签、摘要等信息。这样即使以后不使用 MCP，也不会被锁死在某个特殊系统里。

第一条随手记

Tue, 28 Apr 2026 10:57:00 +0800

这是第一条随手写下的记录。

关于