背景：为什么单独写一篇”前后对比”

前几篇分别记录了迁移过程中的一些问题。这篇把迁移前后的差异汇总成一张对照表：哪些环节的流程彻底变了，既方便自己回顾，也给同样想把站点从境外托管迁回国内的读者一个整体视角。

迁移不是”换台服务器”这么简单——它同时改变了图片存哪、评论跑在哪、文章怎么发、代码怎么上线、谁在把关质量，每一项都是独立的决策。

图片管理：从 R2 直链到 COS 私有桶

迁移前

图片存 Cloudflare R2，走公共直链（pub-xxx.r2.dev/...）。优点是不用签名、谁拿到 URL 都能看；缺点是源站境外面向国内慢，且 R2 的免费额度虽然够用，但缓存和加速依赖 Cloudflare 的节点质量。

迁移后

腾讯云 COS，私有桶 + 服务端签名 URL：

  • 上传后桶内文件默认不可公开访问
  • 页面渲染时由 SSR 服务端调用存储层生成限时签名 URL
  • 首页等动态页面加 no-store 防缓存，避免签名过期后浏览器还拿旧 URL 请求 403

评论管理：从 Waline 托管到 Docker 自建

迁移前

Waline 官方托管（Vercel 函数 + LeanCloud 存储），评论子域挂在境外。问题：国内访问慢、偶尔超时，且审核配置在远端，出问题不好排查。

迁移后

自建 Waline，Docker Compose 跑在服务器上（MariaDB 10 + lizheming/waline:latest），评论子域 comments.lblog.com.cn 由 Nginx 反代。

文章管理：从 Decap CMS 可视化到纯 Git

迁移前：有可视化编辑后台

除了手写 MDX，文章和笔记还挂着一个 Decap CMS（原 Netlify CMS）可视化后台，路径 /admin，用 GitHub 账号登录。它本质是”Git 驱动”的编辑器：在网页里填字段、写正文，保存就把 .mdx 提交到 GitHub 的 dev 分支，不碰命令行。

但这个后台的 GitHub 登录走的是 Netlify 的 OAuth 代理（api.netlify.com/auth/done），认证链路挂在 Netlify 平台上。

迁移后：可视化后台不可用，回到纯 Git

迁回自建服务器后，/admin 页面虽然还是静态文件能打开，但 GitHub 登录链路依赖 Netlify 的 OAuth 代理，自建服务器上没有这条认证，等于登录不了。

所以现在没有可视化的文章/笔记管理页面，回到纯 Git 流程：

  • 新增/修改文章：直接编辑 src/content/blog/、src/content/notes/ 下的 MDX 文件
  • 版本管理：git 提交（dev → master）
  • 发布：本地 npm run build → 打包 dist 上传 → pm2 restart

发布链路从”网页点保存自动提交”退回到”本地改文件 + git + 构建”，对不习惯命令行的场景是个退化，但换来的是发布链路完全可控、不再依赖第三方平台的认证服务。

部署：从 Netlify 自动到服务器手动（现在已脚本化）

迁移前

git push master → Netlify 自动构建部署。发布就是推代码，几乎零操作。

迁移后（手动阶段）

本地 npm run build
tar 打包 dist
scp 上传服务器
服务器解压覆盖
pm2 restart lblog

手动阶段容易漏步骤，尤其是忘备份旧版本、忘了重启服务。

现在（脚本化）

写了个 scripts/deploy.sh：本地构建 → 打包 → scp 上传 → 服务器自动备份旧 dist → 解压覆盖 → pm2 restart。换机器部署改一下开头的服务器地址和密钥路径就能用。

CI：从门禁到缺失

迁移前

GitHub Actions 在 push 时跑 astro check / eslint / prettier / build，不过门禁不让合并。虽然也拦不住所有问题，但至少是个”没人把关也能兜底”的闸。

迁移后

CI 的 yml 文件还在仓库里，但 GitHub 上的 CI 结果不再影响线上——上线不再走 GitHub，而是本地构建 + 手动上传。CI 从”发布闸门”降级成了”仓库里的质量检查”，本地没跑 CI，直接 build 完就传。

风险与对策

风险很清楚：本地验证依赖自觉，漏跑 typecheck / lint 就上线，问题直接暴露给访客。

对策（目前的做法）：

  1. 上线前本地先跑 npm run build（这个必须过，不过产物都出不来）
  2. 有条件就补 npx astro check，抓类型和 schema 错误
  3. 小改动尽量攒一批再上线，减少上线频率，也减少出错的暴露面

更彻底的做法是给服务器配一个 CI runner（自托管 GitHub Actions），但那属于后续优化，现阶段手动流程够用。

差异对照表

维度迁移前（Netlify）迁移后（自建服务器）
托管Netlify 平台腾讯云轻量 + 宝塔面板 + PM2
图片R2 公共直链COS 私有桶 + 服务端签名 URL
评论Waline 托管（Vercel + LeanCloud）Waline 自建（Docker + MariaDB）
文章后台Decap CMS（/admin，GitHub OAuth）无（直接编辑 MDX + Git 提交）
文章发布git push 自动构建本地 build + 上传 dist + pm2 重启
部署平台自动scripts/deploy.sh 一键
CIGitHub Actions 门禁（push 触发）仓库保留，但不参与上线
域名备案公共域名、无备案自有域名 + ICP + 公安联网备案（审核中）
成本均免费额度 + 自动化域名 + 服务器 + 存储桶 + 自己维护（可写脚本）

经验与教训

  1. 别把”换服务器”当小事：存储、评论、部署、CI 全部跟着变，一次迁移等于重构整条发布链路。每一步单独看都不难，合在一起就是一堆新的维护项。
  2. CI 缺失期，本地命令当门禁：build 必跑，astro check 尽量跑，别让”没人把关”变成”没人检查”。

相关文章