维护页必须是纯静态HTML文件，不依赖JS、外部资源或API，所有路径均需路由至该页，并禁用缓存与搜索引擎索引，确保用户清晰获知维护状态及恢复时间。
维护页必须用静态 HTML，别碰 JavaScript
浏览器加载维护页时，JS 可能根本来不及执行——尤其是 CDN 或反向代理已拦截响应体的情况下。Cloudflare 会直接替换你的 503 响应为自家黄页；Nginx 若没配 proxy_intercept_errors on，error_page 503 也压根不生效。所以第一原则：维护页是纯 HTML 文件，不依赖任何外部资源、不写 <script></script>、不调用 API。
-
index.html或maintenance.html放在 Web 根目录下，确保路径可被服务器全局路由捕获 - 标题文字必须含“维护”或“暂时不可用”，避免出现
Error 503这类触发监控误报的词 - 加
<meta name="robots" content="noindex">，防搜索引擎把维护页当首页收录 - 字体至少
16px，小屏设备上文字太小会被用户当成白屏/加载失败
Nginx 配置要绕过所有路径，包括 /api 和 /static
只拦截 / 是最常见的失效原因。用户访问 /api/user 或 /static/js/app.js 时，若配置没覆盖，请求仍会穿透到后端，要么 404，要么返回旧版页面，维护状态就乱了。
- 用
try_files /maintenance.html =404（Nginx）或FallbackResource /maintenance.html（Apache），确保所有路径都落到同一份 HTML - 图片、CSS 等静态资源若放在同目录，需单独
location块放行，否则<img src="./logo.png">会 404 - 务必在
<head>加<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">，禁用客户端缓存
时间判断逻辑不能靠前端 JS 实时跑
如果想“自动开关”维护页（比如只在 02:00–05:30 显示），千万别把时间判断逻辑全塞进 HTML 的 <script> 里。用户本地时区不同，new Date().getHours() 结果就不一致；更别说移动端省电模式可能冻结 JS 定时器。
- 真要动态控制，时间判定必须由后端完成，HTML 按需渲染或跳转
- 若坚持前端判断，必须统一按 UTC+8 解析：用
new Date().toLocaleString('zh-CN', {timeZone: 'Asia/Shanghai'})获取本地化时间字符串再拆解 - 跨天时段（如 23:00 至次日 06:00）不能用
current >= start && current ，得拆成 <code>current >= start || current - 分钟数换算比对更稳：
const m = h * 60 + min，避免字符串比较"02:00" > "23:59"这种坑
别加“重试”按钮，也别自动刷新
维护页本质是“告知状态”，不是“交互界面”。加 <button onclick="location.reload()"> 或 <meta http-equiv="refresh" content="30"> 只会让用户困惑——页面本身就是静态文件，刷新毫无意义，还可能干扰运维排查。
立即学习“前端免费学习笔记（深入）”；
- 用户最关心三件事：是不是我的问题？什么时候好？我能做什么？答案必须一眼可见
- 明确写清预计恢复时间，格式用
2026-05-02 06:00（北京时间），不写“稍后”“尽快” - 页脚加
last-updated: 2026-05-01T21:01:00+08:00，方便运维手动更新时留痕 - 如需邮件提醒，只放极简表单：
<input type="email">+<button>，前端不绑 JS，后端另接
实际部署时，90% 的维护页失效都卡在路径没兜住、缓存没禁掉这两步。写完 HTML 后，务必用 curl 测试非根路径（如 curl -I <a href="https://www.php.cn/link/167b07d756acd5b288f3b8ad0e06673f">https://www.php.cn/link/167b07d756acd5b288f3b8ad0e06673f</a>）是否返回 200 + 维护页内容，而不是 404 或旧接口响应。
