把博客和项目放在一台机器上之后，我为什么先选路径式部署

很多人一提到“博客主站 + 在线项目”这类结构，第一反应都是子域名拆分。这个方向没有错，只是它默认了两件事：

1. 你对 DNS 有稳定控制。
2. 你现在的生产环境已经足够整洁。

如果这两件事都不完全成立，路径式部署往往是更务实的第一步。

这次的问题不是理论上的“优雅”，而是线上真的已经在跑

根域名原本直接挂着项目。要把主站换回来，不能只看最终结构漂不漂亮，还要看切换时会不会把现有入口打断。

我当时更在意的是三个现实问题：

• 主站能不能立刻接管根路径。
• 原来的项目能不能继续在线访问。
• 以后再上新项目时，入口规则是不是足够统一。

如果先把入口收成：

• /
• /blog
• /projects
• /projects/ai-postman/

那么最难的一步其实已经完成了，根域名的职责被重新定义，后面的项目增量也有了固定落点。

路径式部署真正解决的，是“改首页时不再牵连项目”

以前项目直接挂在根路径上，首页每改一次，都是在改项目本身。主站、博客、项目界面和反向代理规则全缠在一起。

路径拆开之后，职责就明确了：

• Astro 负责博客和主站静态内容。
• Nginx 负责静态文件与路径转发。
• ai-postman 前端改成基于 /projects/ai-postman/ 的构建产物。
• 后端接口统一挂在 /api/ai-postman/。

这样的结构不一定最漂亮，但它足够清楚。最重要的是，博客改版时不会再碰到项目 API，项目前端重建时也不会改掉主站内容。

为什么现在不急着全改成子域名

子域名当然更适合长期扩展，但它不是这次的第一优先级。

当前最重要的事情是：

1. 把根域名从单项目入口收回到主站。
2. 把已有项目迁到稳定的新入口。
3. 把构建产物和 Nginx 规则固定下来。

如果这些基础动作没做完，就算先把 ai-postman.scw5370.cloud 配出来，后面一样会遇到同样的问题：配置散落、回滚困难、线上状态说不清。

一个更实际的判断标准

我现在对“部署方案好不好”的判断，不再是它看起来像不像标准答案，而是它能不能回答下面三个问题：

改博客时，会不会影响在线项目

如果答案还是“有点可能”，结构就还没收干净。

项目路径迁移后，旧服务还能不能继续跑

不能因为入口重组，就把原来的业务直接撞掉。

下一个项目上线时，规则是不是还能复用

如果新项目还能自然落到 /projects/<slug>/，那这套结构就有继续扩展的价值。

结论

路径式部署不是终局，但它是这次重建里最稳的中间态。

它先把问题从“根域名上到底跑着什么”变成“每个路径各自负责什么”。一旦这层边界稳定下来，后面无论是切子域名、拆机器，还是补 CI，都有了可以继续往前走的基础。