一个新网站从域名到上线，需要准备哪些东西？

这是我每个站上线的第一份配置文件：

代码

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

80 端口只干一件事：把所有请求转到 https 的规范域名上。后面还有几份配置，每一份都对应一个"上线当天忘了、事后要花几天补"的东西。

域名这一步，真正会出事的是续费和 TTL

注册只是开始，三件小事比选后缀重要。

开启自动续费，并且用一张不会过期的卡。忘了续费是独立开发最常见的事故，而且它不给你任何预警窗口——域名一到期，全站立刻不可达。

把 DNS 解析的 TTL 调到 600 秒。默认的一小时甚至更长，意味着你换新服务器后，有一批用户在几小时内还指向旧机器。上线前调小，稳定之后再调回去。

确认注册商开了域名锁和隐私保护。前者防止被转移，后者避免你的邮箱被爬去收一堆垃圾邮件。

DNS 记录一次写全，别等出问题再补

最少要有这几条：根域名的 A 记录（有 IPv6 就顺手加 AAAA）、www 的 CNAME 指向根域名、以及一条 CAA 记录限定只有你用的那家 CA 能签发证书。

就算你不打算用这个域名发信，也建议加一条 SPF 记录并声明"本域名不发送邮件"，同时配一条 DMARC 策略。理由很现实：别人可以冒用你的域名发钓鱼邮件，而收件方投诉时会找到你。这几条 TXT 记录五分钟就能加完，补起来却往往是在出事之后。

证书别手工拷文件，让它自己续

443 这一侧的配置通常是这样的：

代码

server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
    location / {
        try_files $uri $uri.html $uri/index.html =404;
    }
    location ~* \.[0-9a-f]{8,}\.(js|css|png|webp)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

要点有两个。一是证书走 Let’s Encrypt 加 certbot，用系统定时器自动续期——证书过期是"上线三个月后某天全站突然打不开"的经典原因，而且它总发生在你没看监控的时候。二是缓存策略要分两类：文件名带内容 hash 的静态资源可以设一年并标记 immutable，HTML 则必须 no-cache，否则你发新版用户还停留在旧页面。这部分在 Nginx 上的写法有很多细节，尤其是压缩和 HTTP/2 的开关顺序。

静态托管还是容器，取决于有没有需要长跑的进程

纯静态站——推文件到对象存储或静态托管，前面套一层 CDN 就够了，连应用服务器都不需要。10015.io 就是这种形态：50 多个工具几乎全在客户端运行，极少请求服务端，它的"服务器"本质上只是个文件分发点。

有后端就要容器化：一个容器跑应用，一个跑数据库，数据库文件挂到持久化的 volume 上。用 Docker 的 compose 把两者的启动顺序和健康检查写清楚，避免应用先起来、数据库还没就绪导致启动失败，然后陷入重启循环。

别把 TLS 终止做两遍：CDN 已经处理 HTTPS 的时候，源站要么也配证书，要么明确走回源协议，配错了会出现无限重定向。

统计和监控要加上，但别让它拖慢页面

上线后看不见数据是最难受的状态，所以统计脚本上线当天就要装。但它有重量：一个第三方统计库加上一个错误上报库，再加一个热力图，几十 KB 的阻塞脚本就进首屏了。

我的做法是只装两个——一个统计、一个前端错误上报——并且都异步加载；其余等真的需要时再加。上线初期你要的答案其实很少：今天有多少人来了、有没有人遇到 JS 报错。这两个问题用不着一套重型方案。

三个必须存在的文件

robots.txt、sitemap.xml、一个真正返回 404 状态码的 404 页面。

robots.txt 最常见的事故，是为了挡住预发布环境写了 Disallow: /，然后跟着构建产物一起推到了生产。上线当天务必亲手打开 https://你的域名/robots.txt 看一眼。

sitemap 里只列真实存在的规范 URL，不含跳转链、不含参数变体。写法和提交方式在 robots 与 sitemap 那一节里有明确规范。

404 页面必须真的返回 404。很多静态托管的默认行为是返回 200 加一个"未找到"的 HTML，搜索引擎会把这些 URL 当正常页面收录，攒出一批内容相同的垃圾页。

上线当天就得有的回滚路径

保留上一版构建产物，能一键切回；配一个简单的健康检查端点；把错误日志接到一个你会真的去看的地方（哪怕是每天一封摘要邮件）。

还有一类容易漏的是定时任务。TinyWow 承诺上传的文件 1 小时后自动删除——这种承诺需要一个确实在跑的清理任务，而且要能证明它跑过：写日志、计数，最好有一个告警告诉你"今天没有清理任务执行记录"。写了 cron 不等于它在跑。

TinyWow 首页底部滚动着一组自家数据：100 万活跃用户、1000 万次文件转换、200+ 在线工具。

桌面应用的清单完全是另一套

Cakedesk 是 Max Schmitt 一个人做的桌面端发票应用，Electron + React + Node.js，一次性 69 欧元。它没有 nginx，没有证书，但它有别的要准备的东西：代码签名证书（不然系统会弹"未知开发者"，转化直接腰斩）、自动更新通道（老用户能收到新版本）、安装包的分发与版本归档。

它 2025 年发了 12 个版本，意味着这套流程一年要走 12 次。所以第一次就得脚本化，而不是每次手工打包。

把清单固化成模板

上面这些内容，我现在都写成一份脚本或一个仓库模板：复制目录、填域名、改两处变量、跑一次。第二第三个站上线时不再重新想一遍。

清单本身不值钱，值钱的是它逼你在凌晨三点之前发现问题——尤其是证书、robots、404 这三样，它们不会在测试环境里暴露，只在真实流量进来之后才咬人。

TinyWow 文件删除策略引自其官网说明；Cakedesk 版本与销售数据来自作者 Max Schmitt 的年度复盘。