纯HTML维护页需含五要素：标题含“维护”或“暂时不可用”、meta robots="noindex"防收录、字体≥16px、明确恢复时间（如2026-08-04 10:00 北京时间）、页脚last-updated时间戳，禁用跳转/刷新/重试，资源本地化，服务器全局路由至该页并禁用缓存。
直接用纯 HTML 写一个能立刻生效的维护页
不需要框架、不依赖后端，把 index.html 丢进 Web 服务器根目录就能用。关键不是“多好看”，而是“用户一眼看懂、不误判为故障、不触发爬虫收录”。
核心要素就五项：<title></title> 含“维护”或“暂时不可用”；<meta name="robots" content="noindex"> 防止被搜索引擎当首页抓取；字体至少 16px；明确写出预计恢复时间（如 2026-08-04 10:00 北京时间）；页脚加 last-updated: 2026-08-03T20:26:00+08:00。
别写 <h1>Error 503</h1>——这个词会让用户以为网站崩了，而不是在修。
- 所有资源必须本地化：CSS 写在
<style></style>里，图片用 base64 或绝对路径（如https://cdn.example.com/maintain.svg），避免./images/logo.png这种相对路径失效 - 禁用任何跳转逻辑：
window.location、meta http-equiv="refresh"、重试按钮统统删掉——静态页点不动，只会增加困惑 - 移动端优先：用
flex居中，不用position: absolute+ 负 margin；viewport必须声明：<meta name="viewport" content="width=device-width, initial-scale=1.0">
倒计时功能要不要加？怎么加才不翻车
要加就得用 JavaScript，HTML 自身无法计算时间差。但 JS 是可选的——没它，静态文案也完全合格；有它，反而容易因加载失败或 CSP 拦截变成空白或 NaN。
立即学习“前端免费学习笔记（深入）”；
如果决定加，必须满足三个条件：JS 文件独立（maintenance.js）、时间戳存 data-end-time 属性、时区显式标注（带 +08:00）。
错误示范：<span id="countdown">2026-08-04T10:00:00</span> —— 这串文字不会动，浏览器也不会自动解析成倒计时。
- 正确写法示例：
<div id="countdown" data-end-time="2026-08-04T10:00:00+08:00"></div>，然后在maintenance.js里用new Date(element.dataset.endTime)解析 - 千万别把 JS 写在
<script></script>标签里 inline——Nginx 静态服务 + CSP 策略下大概率被拦截，执行不了 - 跨天维护（比如 23:00 到次日 06:00）要单独处理逻辑，不能只用
>= start && ，否则凌晨 01:00 就不显示
Nginx / Apache 怎么让所有请求都指向这个维护页
不是改 DNS，也不是改应用代码，是靠 Web 服务器全局劫持流量。重点不在“怎么配”，而在“配错后用户看到什么”——90% 的失败源于缓存和路径没清干净。
Nginx 推荐用 try_files：在 location / 块里写 try_files /maintenance.html =404;，确保连 /api/login、/static/js/app.js 这类路径也返回维护页（否则前端可能报错白屏）。
Apache 不能靠 ErrorDocument，那是给 404/503 用的；得用 RewriteRule 强制重写：
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^(.*)$ /maintenance.html [R=302,L]
注意：R=302 是临时重定向，别写成 301——否则浏览器和 CDN 会永久缓存，维护结束都切不回来。
- 改完必须 reload：Nginx 执行
nginx -s reload，Apache 执行systemctl restart httpd - 验证是否生效：curl -I https://yoursite.com/random-path，看响应头是不是
HTTP/2 200且内容是维护页 HTML - 清除 CDN 缓存：Cloudflare、阿里云 CDN 等平台需手动 purge，否则用户看到的还是旧首页
为什么不能只返回 HTTP 503 状态码
语义上 503 是对的，但现实中它基本不可控——CDN、反向代理、监控工具全会干预你的响应体。
Cloudflare 默认把 503 替换成自己的黄页；Nginx 的 error_page 503 /503.html 必须配合 proxy_intercept_errors on 才透出你写的 HTML；UptimeRobot 这类监控会把 503 当宕机告警，而不是计划内停机。
真正可靠的做法：返回 200 OK + 维护页 HTML，并在页面里写明状态（比如 <p>系统正在维护（HTTP 200）</p>）。运维查日志时看访问路径，用户看到的是明确提示，监控工具也不误报。
- 标题和状态码要一致：
<title></title>写“网站维护中”，就别在响应头里塞503 Service Unavailable - 如果你坚持用 503，必须确认三层链路都透出原始响应：应用 → 反向代理 → CDN → 用户，任一环节拦截就前功尽弃
- 最稳妥的兜底：维护页本身返回 200，同时在
<meta name="description">里写“此页面为计划内系统维护公告，非故障”
最后提醒一句：维护页不是越 fancy 越好，而是越少依赖越稳。字体、颜色、倒计时这些，全都可以砍掉，只要那行“预计 2026-08-04 10:00 恢复”清晰可见，就已经达标了。
