数字花园

网站版本核对记：十一页逐字节一致与一条被误解的部署链

2026-10-16 · 约 7 分钟 · qaqmin · 网站版本 · 部署链路 · Astro · 字节级对账

每天往网站上发表文章的人，未必清楚文章是怎样到达访客屏幕的。这一次，一次「帮我找出网站工作内容」的请求，演变成一场对自家江山的全面测绘，以及一条部署链路的正本清源。

一、寻根：my-portal-v19 就是 qaqmin

工作区里躺着一堆目录，qaqmin 网站的真身被一眼认出——my-portal-v19：Astro 网站项目，正式地址 https://qaqmin.com（Cloudflare Pages 自定义域），作者 QAQMin，副标题「构建值得留下的软件与工具」。功能清单随之铺开：WebGL 粒子场景（九千粒子、移动端四千五的斐波那契星球，滚动时在星球⇄聚成名字⇄星系⇄波浪网格之间形变，带鼠标视差）、建站年轮轨道环、footer 的 split-flap 翻页钟（秒级翻动加 Web Audio 机械音效）、实时在线人数与访客星云（WebSocket 连 portal-backend 的 Durable Object，每个在线访客化为一颗游星）、星球留星留言（三重过滤：关键词黑名单加 Workers AI 判毒加人工审核页，IP 冷却、只留最近三百条）、星星回应（点击金星加一、所有在线访客实时同步）、访客星图（按国家聚合的世界点阵地图，IP 只存 SHA-256 指纹）、里程碑彩蛋（第 100/365/520/1000/1314/10000 天、元旦、3.15 站长生日、跨年夜倒计时）。四语言（中英日韩，中文默认根路径），Pages Functions 按访客 IP 国家自动跳转、手动选择优先写 cookie。

二、对账：十一页逐字节一致

线上比对撞上了熟悉的老对手——本机 TUN 代理把 qaqmin.com 解析到 198.18.x.x 假 IP 导致 TLS 失败；绕代理直连后线上返回 200。十一页逐一比对的结果令人安心：首页（49,830 字节）、/about/、/en/、/rss.xml（856,667 字节）、/sitemap-0.xml（636,878 字节）、/garden/tag/qaqmin/、/works/tiebalite/、/sponsor/、/wrapped/、/search/、/404.html——全部逐字节一致。两个看似异常的点被解释为正常：/works/（不带子路径）线上 404 是因为本地 dist 里 works 目录本来就没有 index.html；标签页不带尾斜杠返回 308 是 Astro 的标准重定向。rss 和 sitemap 作为全站页面与文章的完整清单，两者一致基本可以确定整站页面集合没有遗漏。本地侧的新鲜度也确认：git 工作区干净、HEAD 是 10-16 凌晨的花园文章提交、最后提交的新文章已在 dist 的 rss 和 sitemap 里、没有任何源文件比 dist 构建产物更新、.wrangler/tmp 时间戳与 dist 构建时间吻合——构建后立即部署的流程痕迹清晰。唯一没能完全验证的是 portal-backend 的线上部署版本（WebSocket 地址不在静态页面里，要走服务绑定），静态站点本身则可以放心：线上就是本地这份代码。

三、正本清源：commit 不推上线

用户问出了一个要害问题：「我直接所做的提交改变都是直接推到线上是吗？」答案是否定的，而且值得每个写文章的人记住——git commit 纯本地存档，仓库没有配置任何 remote（git remote -v 是空的），提交既不触发构建也不触发部署。真正让线上发生变化的只有中间一步：npx wrangler pages deploy dist。完整的链条是：写稿/翻译 → 校验 → npm run build 生成 dist → wrangler 部署（只有这一步推到 Cloudflare）→ curl 线上抽查核对篇数 → git commit 收尾。这次比对全一致，是因为 10-16 凌晨把整套连起来跑完了（dist 建于 00:14、随后部署、commit 于 00:17），build 和 deploy 发生在提交之前——这是「按流程跑完」的状态，不是「提交自动上线」的机制。需要留意的风险也随之清晰：如果哪天改了源码或文章后只 commit、忘了 build 加 deploy，线上不会变而本地 HEAD 会领先——每日流程里「部署前核对线上版本、部署后核对篇数」正是防这个的。

真实坐标

qaqmin 网站版本 部署链路 Astro 字节级对账

评论

← 数字花园