动态404页面的核心是可用性而非炫技：必须在无网络、低带宽或禁用JS时仍传达关键信息，禁用fetch/API请求，服务端预置推荐链接，慎用DOM操作与CSS动画，遵守可访问性规范，并确保HTTP状态码正确返回404。
动态404页面不是加个动画就完事——核心矛盾在于：用户已经“断连”，你却还在拼命加载 JS、请求 API、播放音频、渲染星空。真正可用的动态，必须在无网络、低带宽、甚至禁用 JS 的场景下仍能传达关键信息。
为什么 fetch() 和 XMLHttpRequest 在 404 页面里基本没用
当用户看到 404，通常意味着目标 URL 对应的资源根本不存在，后端服务可能已不可达。此时前端再发 fetch('/api/suggestions') 或 fetch('/search?q=...')，99% 会失败，还拖慢首屏渲染、触发 CORS 报错、干扰错误日志归因。
- 不要在 404 页面里调用任何外部接口，包括站内搜索 API、推荐接口、埋点上报
- 若真需“智能提示”，应由服务端在返回 404 响应体时，直接注入预计算好的链接（如最近更新的 3 篇文章），避免前端二次请求
-
localStorage或sessionStorage可读，但别依赖它存关键导航；用户可能刚清空缓存或首次访问
document.write() 和 innerHTML 动态写入的风险
很多模板用 JS 拼 HTML 字符串再 document.body.innerHTML = '...' ，看似灵活，实则破坏语义结构、清空已有 DOM（比如已挂载的无障碍属性）、且无法保证 <main></main> 或 role="main" 容器被正确保留。
- 优先用原生 DOM 方法：创建
document.createElement('h1')，设置textContent，再appendChild() - 若必须批量插入，用
document.createDocumentFragment()批量构建，最后一次性挂载 - 绝对避免
document.write()—— 它在页面加载完成后调用会清空整个文档
CSS 动画和星空背景的性能临界点
星空动画本身不重，但“动态生成流星”“点击炸开星星”这类交互式 CSS+JS 混合效果，在低端 Android 或 Safari 上容易掉帧，且与“错误提示”的严肃性冲突。
立即学习“前端免费学习笔记（深入）”；
- 纯 CSS 星空（
@keyframes+position: absolute百来个div）可接受，控制在 50KB 内联样式以内 - JS 控制的流星轨迹，建议只响应
click，且限制每秒最多 1 条；用requestAnimationFrame替代setTimeout循环 - 移动端务必加
@media (prefers-reduced-motion: reduce)关闭所有动画，这是 WCAG 2.1 强制要求
音频元素 <audio> 的实际兼容性陷阱
想加个轻柔音效缓解挫败感？先确认：<audio> 在 iOS Safari 中默认静音，且必须由用户手势触发（如点击按钮），自动 play() 会被静音或拒绝。
- 不要在页面加载时自动播放；只在用户点击“播放提示音”按钮后调用
.play() - 音频文件必须是 MP3 或 AAC 格式，WebM/OGG 在部分旧浏览器中不支持
- 禁用
preload="auto"；改用preload="metadata"，避免加载完整音频阻塞首屏 - 若音频非必需，建议直接放弃——404 是异常路径，不该增加资源负担
最常被忽略的一点：动态效果再炫，也压不住一个没设 http_response_code(404) 或 Nginx 缺少 error_page 404 /404.html; 配置的致命错误。状态码错了，一切动态都是障眼法。
