HTML5页面延时跳转本质是用setTimeout控制location.href赋值，需确保DOM就绪、避免沙箱拦截、处理跨协议限制、清除冗余定时器，并注意移动端用户交互要求。
HTML5 页面跳转加延时，本质是用 JavaScript 的 setTimeout 控制 window.location 或 location.href 的触发时机，不是 HTML5 新增功能，但兼容所有现代浏览器。
用 setTimeout 调用 location.href 最稳妥
直接赋值 location.href 是最常用、最可靠的跳转方式，配合 setTimeout 可精确控制延迟。注意不能写成字符串形式的代码（如 "location.href='...'"），否则可能被沙箱拦截或执行异常。
常见错误：把 URL 拼错、漏写协议（https://）、或在非 HTTPS 页面跳转到 HTTPS 时被浏览器静默阻止（尤其涉及 document.referrer 时）。
setTimeout(() => { location.href = 'https://example.com'; }, 3000);- 若需保留当前页面历史（即用户点返回还能回来），用
location.replace()替代，它不会新增 history 记录 - 延时单位是毫秒，
3000表示 3 秒，别误写成3（3 毫秒基本无效）
避免在 DOMContentLoaded 前执行跳转
如果脚本放在 里且没加 defer，setTimeout 回调可能在 DOM 尚未解析完成时就触发跳转，导致页面白屏或部分资源加载中断。
立即学习“前端免费学习笔记（深入）”；
实际场景中，比如你希望「页面加载完 2 秒后跳转」，就不能只依赖 setTimeout，得等 DOM 就绪：
- 推荐写法：
document.addEventListener('DOMContentLoaded', () => { setTimeout(() => { location.href = '/next'; }, 2000); }); - 如果还要等图片等资源，改用
window.addEventListener('load', ...)，但会更慢 - 服务端渲染（SSR）页面中，DOM 就绪时间更早，
DOMContentLoaded更可靠
移动端要注意 beforeunload 和用户交互限制
某些 iOS Safari 和 Android WebView 在页面即将跳转前，若检测不到最近的用户手势（如点击、触摸），会静默取消跳转或弹出提示——尤其是自动跳转 + 页面内有音频/视频自动播放时。
这不是 bug，是浏览器对用户体验的保护机制。解决思路有限：
- 确保跳转逻辑由用户显式操作触发（例如按钮点击后才设
setTimeout），而非页面一打开就启动 - 避免在
iframe中执行跳转，跨域 iframe 会被严格限制 - 不要依赖
onbeforeunload拦截跳转后再重定向，该事件只允许同步提示，异步跳转会被忽略
真正容易被忽略的是：跳转前是否清除了定时器。比如用户在 3 秒倒计时中途点了其他链接，旧的 setTimeout 仍可能在后台执行，造成意外覆盖。需要保存 timer ID 并在必要时 clearTimeout —— 这在单页应用（SPA）或频繁交互页面里尤为关键。
