jianfei-blog / v3.1.0 release

jianfei-blog
v3.1.0 升级说明

本地图片自动处理 · base64 提取 · 统一图片逻辑 · HTML 页面部署

← 回到原文

剑飞思考啊 · sikaoa.com

agenda

今天讲 5 件事

01背景：图片处理的三个老坑~2min

02修复：本地图片自动解析 & 替换~2min

03修复：base64 图片提取成独立文件~2min

04重构：统一提取逻辑 + 守护进程升级~2min

05新功能：直接部署 HTML 原始网页~2min

// part 01 · 老坑

图片处理的三个痛点

❌ 本地图片上传后看不见

Markdown 里写了 ![](./imgs/xxx.png)，上传后路径失效，线上 404。

手动复制 + 改路径 + 再部署

❌ base64 塞爆 JSON

含 base64 图片的文章直接塞进 posts.json，JSON 体积暴涨，构建慢到怀疑人生。

单篇文章可达数 MB

❌ 提取逻辑各写各的

extract-images、publish-go、watcher 三个地方各有一套图片处理代码，维护成本高。

重复逻辑 · 容易遗漏

先讲背景——图片处理一直是 jianfei-blog 里最让我头疼的部分。不是功能复杂，是场景太多，每个场景都藏着坑。

第一个坑，本地图片上传后看不见。你在本地写 Markdown，插了几张截图，路径是相对路径。用 upload-md 上传之后，线上根本读不到这些路径，因为服务器上没有对应的 imgs 目录。以前得手动复制图片、改路径、再部署——三步走，很麻烦。

第二个坑，base64 图片塞爆 JSON。publish-go 发布文章时，如果内容里嵌了 base64 图片，整段 base64 文本会直接写进 posts.json。一篇文章可能就几 MB，几千篇文章下来 JSON 文件膨胀到几十 MB，构建时间直接拉满。

第三个坑，提取逻辑各写各的。extract-images、publish-go、watcher 三个模块都需要处理图片，但每套的实现方式不一样，有的只认 HTML 格式，有的只认 Markdown 格式。维护起来很头疼。

v3.1.0 就是对着这三个坑逐个解决的。

// part 02 · 本地图片

upload-md 现在会自动处理本地图片

以前三步走，现在一步搞定。upload-md 会自动扫描 Markdown 中的本地图片引用，按相对路径找到原文件，复制到 public/images/，并把链接替换为线上可用路径。

![](imgs/chapter_01.png) → ![](/images/{postId}-{hash}.png)

# 以前
jianfei-blog upload-md article.md
# 然后手动复制图片、改路径、deploy...

# 现在
jianfei-blog upload-md article.md
jianfei-blog deploy
# 图片自动处理，直接完成
    

进入第一个修复——本地图片自动处理。

以前用 upload-md 上传 Markdown 文件时，如果文章里有 ![](./imgs/xxx.png) 这种本地图片引用，上传之后线上是看不到的。因为服务器上根本没有 imgs 目录。

v3.1.0 的处理逻辑是这样的：upload-md 会自动扫描 Markdown 内容里的所有本地图片引用，按照 .md 文件所在的目录解析相对路径，找到原始图片文件，把它复制到 public/images/{postId}-{hash}.{ext}，然后把 Markdown 里的链接也替换成线上可用的绝对路径。

这样一来，你只需要执行 upload-md，然后直接 deploy 就行。图片处理完全自动化。

这个改动看起来小，但省了很多功夫。特别是当你一次上传十几篇文章，每篇都有五六张截图的时候，手动处理图片简直是噩梦。

// part 03 · base64 + 统一逻辑

base64 提取 + 统一模块

base64 图片自动提取

publish-go 部署前自动扫描所有文章，不管是 HTML 的 <img> 还是 Markdown 的 ![alt](data:...)，统统提取成独立文件。

# 部署前自动处理
jianfei-blog publish-go article.html
# base64 → 独立文件，JSON 不再膨胀
      

extract-images-core.js

新增核心模块，同时支持 HTML <img src="data:..."> 和 Markdown ![alt](data:...) 两种格式。

# 三处共用同一套逻辑
extract-images       # 手动提取
publish-go           # 发布前提取
auto-deploy-watcher  # 自动部署时提取
      

接下来是第二个和第三个修复——base64 图片提取和统一提取逻辑。这两件事是绑在一起做的。

先说 base64。以前 publish-go 发布含 base64 图片的文章时，会把整段 base64 文本直接塞进 posts.json。结果就是 JSON 文件体积暴涨，构建变慢。v3.1.0 改好了——publish-go 在部署前会先检查所有文章，不管是 HTML 的 img 标签还是 Markdown 的 data URL 格式，统统提取出来变成独立文件，然后再跑 vercel --prod。

再说统一逻辑。以前 extract-images 只认 HTML 的 img 标签，对 Markdown 的 base64 图片完全没反应。三个模块各写各的，维护起来很痛苦。

v3.1.0 新增了一个核心模块 scripts/lib/extract-images-core.js，同时支持 HTML 和 Markdown 两种格式的 base64 图片。extract-images、publish-go、auto-deploy-watcher 三个地方都用它——再也不用重复写逻辑了。

这两个改动加起来，图片处理这块终于变得干净了。

// part 04-05 · 守护进程 + 新功能

守护进程升级 + HTML 页面部署

①

watcher 部署前先提取图片

自动部署守护进程每 5 分钟扫描新文章，现在发现新文章后，部署前自动调用图片提取逻辑，确保内容完整。

②

新增启动脚本

./scripts/start-watcher.sh 支持前台/后台运行，自动加载 .env 环境变量。

🌐 新增：deploy-html

现在可以直接部署纯 HTML 页面，甚至一个完整的小站点。

# 单个 HTML 文件
jianfei-blog deploy-html ~/page.html --title "我的网页"

# 整个目录（多页站点）
jianfei-blog deploy-html ~/my-site/ --title "我的站点"
      

自动创建 Sanity 文章记录，博客列表显示 🌐 标识，可独立访问。

最后两个点——守护进程升级和HTML 页面部署新功能。

先说 watcher。以前自动部署守护进程每 5 分钟扫一遍新文章，但图片还是没提取，导致有些页面加载失败。v3.1.0 修复了——每次发现新文章，部署前主动调用图片提取逻辑，确保内容完整。

另外还加了个启动脚本 ./scripts/start-watcher.sh，支持前台或后台运行，还能自动加载 .env 环境变量，方便多了。

最爽的是最后一个新功能——现在可以直接部署纯 HTML 页面，甚至是一个小站点。用法很简单：deploy-html 命令，接单个 HTML 文件或者一个目录。单个文件会放到 public/html-pages/slug/index.html，目录会整个拷贝过去保持路径结构不变。同时在 Sanity 里创建文章记录，博客列表里会显示一个 🌐 标识。

这个功能解决了一个很实际的需求：有些内容不适合写成 Markdown，比如一个数据可视化页面、一个交互式图表、或者一个独立的 landing page。以前得单独部署，现在一条命令就搞定了。

// summary · takeaways

v3.1.0 的核心改进

✓ upload-md 自动处理本地图片引用，一步上传修复

✓ publish-go 自动提取 base64 图片，JSON 不再膨胀修复

✓ extract-images-core.js 统一 HTML + Markdown 两种格式重构

✓ watcher 部署前自动提取图片 + start-watcher.sh 启动脚本重构

✓ deploy-html 支持单文件 / 目录部署，可部署完整站点新功能

更新方式：npm update -g jianfei-blog 或拉取最新代码