为什么你自托管的应用总在凌晨三点崩溃（以及如何修复）

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

所以你启动了一台虚拟私有服务器（VPS），部署了你的应用程序，告诉所有人它已经上线了——结果凌晨三点醒来却发现整个系统宕机，还收到了一堆愤怒的 Slack 消息。欢迎加入这个俱乐部。

自行托管生产环境中的应用程序，听起来很简单，直到你真正去做的时候才会发现问题。我自己运行自托管服务已经有大约六年时间了，而“在我的服务器上能跑”和“在生产环境中稳定可靠地运行”之间的差距，正是大多数痛苦所在。实际上，网上流传着一份非常详尽的免费指南（超过750页），专门覆盖这一领域，这也让我意识到很多开发者一直在撞同一堵墙。

让我来梳理一下自托管应用在生产环境中最常见的失败原因，以及如何真正解决它们。

根本原因：你部署的是一个应用，而不是一个系统

问题的核心在于：当你执行 docker compose up -d 然后走开时，你只是部署了一个应用程序。但生产环境需要的是一个完整的系统——包括监控、自动重启、日志轮转、备份、资源限制，以及不会轻易崩溃的反向代理配置。

大多数凌晨三点发生的崩溃，归根结底是以下三种情况之一：

• 内存耗尽 —— 你的应用（或其数据库）慢慢吃光了所有可用内存
• 磁盘空间不足 —— 日志或临时文件占满了磁盘
• 缺乏自动恢复机制 —— 进程崩溃后没有任何东西将其重新启动

接下来我们逐一解决这三个问题。

第一步：设置资源限制（阻止内存溢出杀手）

如果你使用的是 Docker Compose，就必须设置内存限制。否则，一个行为异常的容器就可能拖垮整台主机上的所有服务。

# docker-compose.yml
services:
  app:
    image: your-app:latest
    deploy:
      resources:
        limits:
          memory: 512M    # 硬性上限 —— 超过此值容器将被终止
          cpus: '1.0'
        reservations:
          memory: 256M    # 保证的最低内存
    restart: unless-stopped  # 仅此一项就能避免大多数凌晨三点的事故

  postgres:
    image: postgres:16
    deploy:
      resources:
        limits:
          memory: 1G
    # 将 shared_buffers 调整为内存限制的大约 25%
    environment:
      POSTGRES_SHARED_BUFFERS: 256MB
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: unless-stopp