静态站点部署：为什么选择 Astro + Nginx

一个内容为主的个人站点，最重要的通常不是动态渲染能力，而是稳定、易维护和足够快的访问体验。对这类场景，静态站点生成（SSG）是一个很合适的默认选择。

这个站点使用 Astro 在本地生成纯静态 HTML、CSS 和少量资源文件，再由 Nginx 直接提供服务。浏览器请求不需要经过 Node.js 应用进程，也不需要等待服务端运行时渲染。

把复杂度放到构建阶段

传统服务端渲染的请求路径通常包含应用进程、路由、模板执行，可能还有数据库或接口调用。静态站点则在发布前完成这些工作：

Markdown / 页面组件 → 本地构建 → 静态产物 → Nginx

这样做带来几个直接收益：

• Web 服务只负责读取文件，运行时依赖更少
• 页面可以被浏览器和 CDN 直接缓存
• 低配置服务器也能承载较稳定的访问
• 发布过程更容易回滚：产物本身就是可部署单元

它的代价也很明确：内容更新需要重新构建；高度个性化或实时数据则需要另行接入 API 或服务端能力。

为什么是 Astro

Astro 的核心优势是默认输出静态 HTML。对于博客、文档、展示页这类场景，浏览器拿到的就是完整内容，而不是先下载一段应用代码再等待客户端渲染。

这不意味着任何项目都应选择 Astro。复杂后台、重交互的协同应用或实时控制台，仍然需要更完整的客户端应用架构。但对于以阅读为主的网站，少发 JavaScript 往往就是最直接的性能优化。

Nginx 负责什么

Nginx 适合承担静态资源服务、TLS 终止和缓存响应头等稳定工作。一个基础站点至少要确认以下事项：

• HTTP 自动跳转到 HTTPS
• 证书自动续期，并在续期后验证配置
• HTML、CSS、JS 和图片分别设置合理缓存策略
• 缺失页面返回真实的 404，而不是错误地回退到首页
• 开启压缩，减少文本资源传输量

缓存策略需要区分资源类型。带内容哈希的 CSS、JS 文件可以使用较长缓存；页面 HTML 更新更频繁，则应使用较短缓存或要求重新验证。

发布应以产物为中心

构建环境和生产环境不必完全相同。对静态站点来说，生产服务器只需要 Nginx 和构建产物，不需要安装 Node.js、npm 或完整源码。

一个简单发布流程可以是：

1. 在可信的本地或 CI 环境执行构建。
2. 检查生成目录中是否包含预期页面与静态资源。
3. 将产物压缩后传到服务器并解压到站点目录。
4. 用 HTTP 状态码验证首页、文章页、robots.txt 和 sitemap。
5. 保留上一版产物，确认无误后再清理。

把验证步骤写进脚本，比依赖「我已经上传过了」更可靠。

安全和可维护性同样重要

静态站点虽然攻击面较小，但服务器本身仍需要基本防护：密钥认证优先于密码登录、限制不必要的监听端口、保持系统更新，并对发布密钥实施最小权限管理。

内容层面也应避免将密钥、服务器地址、内部接口和访问令牌写入 Markdown 或提交到仓库。静态站点的所有文件都可能被直接下载，因此公开内容应默认可见。

结语

Astro + Nginx 不是最炫的组合，却很符合内容型站点的需求：构建时完成复杂工作，运行时保持简单；发布的是可验证的静态产物，访问路径也足够短。先选择适合问题复杂度的技术栈，往往比堆叠更多服务更重要。