文章 | s1oopX

从 WordPress 到 Astro：选型迁移的思考

这次重做个人站，我没有追求最多的功能，而是围绕写作、作品展示和 VPS 运维重新确定了一套足够简单、可以长期维护的技术栈。

从商户日结任务重复执行出发，分析故障转移、分布式锁、批次记录、租约状态机、唯一约束与跨系统幂等的职责边界。

结合 Zed、Cursor 和 ZCode 的实际体验，区分编辑器优先与 Agent 优先两种工作方式，并讨论长任务、上下文连续性和 GUI 性能各自解决的问题。

用一次 39 篇博客改造实验，拆解 /goal、Stop hook、验收条件、停滞检测与预算刹车，说明 Loop Engineering 何时有效、何时只会放大失控。

从缓存命中率骤降、数据库连接池耗尽到订单失败，拆解大促故障的证据链、止损顺序、缓存重建、限流熔断、核心链路降级与验证方法。

首页在线时钟走到 241 天，站内也正好有 39 篇文章。回头看这段经历，真正的变化不是换了多少技术栈，而是开始把失败、判断和验证过程留下来。

把文章、项目和工具判断放在自己的域名与仓库里，不是为了逃离平台，而是为了保留结构、上下文和迁移选择。

公开一个链接后，别人看到的不只是页面。域名、历史 DNS、源站端口、前端代码和管理入口会连成一条暴露链，发布前应逐层检查。

Cloudflare Tunnel 把内网服务接到公网，但它不负责识别访问者。公开主页、管理后台、OAuth 回调和部署接口需要按路径建立不同边界。

有网、受限网和完全离线环境需要的不是同一条命令。把镜像获取当成交付链路，才能在代理缓存、私有仓库和 save/load 之间选对方案。

VLESS + REALITY 不绑定 443 端口。真正需要弄清的是端口可达性、监听冲突、反代复用和 Cloudflare 代理边界，而不是把 443 当成协议要求。

VMess、VLESS、Trojan、TLS、REALITY、XTLS 和 Xray 经常被放在一张对比表里，但它们不在同一层。先把实现、协议、传输和握手拆开，选型才不会混乱。