最简自动刷新用，是唯一不依赖JavaScript的原生方案，需置于中，content格式为“秒数; url=目标”，分号后须空格，仅写数字则刷新当前页，但存在SEO差、bfcache失效、无交互控制等缺陷。
用 <meta http-equiv="refresh"> 实现最简自动刷新
这是唯一不依赖 JavaScript 的原生方案，适合纯静态页或降级兜底。写在 里，浏览器一解析就计时，不等 DOM 加载完成。
常见错误现象：页面白屏几秒才跳、跳转后 404、移动端 Safari 失效。
-
content必须是"秒数; url=目标"格式，分号后要空格（旧 IE 敏感），不能写成"3,url=..."或"3 url=..." - 只写数字如
content="5"是刷新当前页，不是跳转 - 相对路径以 HTML 文件所在目录为基准，
url="./admin.html"和url="/admin.html"完全不同 - Chrome 95+ 会禁用后退缓存（bfcache），用户点「返回」可能看到白屏或重复刷新
用 setTimeout() + location.reload() 控制刷新时机
JS 方案能避开 <meta> 的硬伤：可监听用户是否正在输入、是否切走标签页、是否滚动，还能动态调整间隔。
典型误用：脚本放在 里直接执行，DOM 还没加载完就调用 location.reload()，导致部分资源未初始化。
立即学习“前端免费学习笔记（深入）”；
- 推荐放在
底部，或包装在DOMContentLoaded事件里 - 需要强制从服务器拉新内容？用
location.reload(true)，但注意现代浏览器已弱化该参数效果 - 若页面有未提交表单，
reload()不触发beforeunload提示，数据会静默丢失 - 周期性刷新必须配
clearInterval()，否则定时器持续累积，内存泄漏风险高
用 setTimeout() + location.href 或 location.replace() 跳转
目标是换页面而非刷新当前页时，JS 跳转比 <meta> 更可控——能加校验逻辑、能避免历史栈污染、能处理跨域限制。
容易踩的坑：跳转后用户点「返回」回到一个已过期或失效的页面；或者在 iframe 里执行跳转被浏览器拦截，报 Unsafe attempt to initiate navigation。
- 想让用户无法返回当前页（比如登录过期页），用
location.replace('login.html')，它不留下历史记录 - 需服务端鉴权再跳转？先
fetch('/api/valid')，状态码 200 再执行跳转，<meta>做不到这点 - 按钮触发跳转时，确保
<button></button>的type是"button"，否则包在<form></form>里会默认提交，干扰跳转 - 单页应用（Vue/React）中，直接改
location.href会整页刷新，应优先用路由实例的router.push()
检测“真实无操作”再跳转，不能只靠 <meta refresh>
<meta http-equiv="refresh"> 的计时从页面开始加载起算，和用户行为完全无关。所谓“30 秒无操作跳转”，必须用 JS 监听交互事件重置倒计时。
常见失效场景：用户切走标签页、最小化窗口、弹出系统对话框（如文件选择），此时页面已失焦，但倒计时仍在跑，导致误跳。
- 必须监听
mousemove、keydown、scroll、focusin—— 尤其focusin，否则用户切回来点输入框，倒计时不会重置 - 用
document.hasFocus()判断页面是否激活，失焦时暂停倒计时，避免误跳 - 监听
visibilitychange事件更可靠，document.hidden === true时clearTimeout - 移动端 WebView 对
hasFocus()支持不稳定，建议叠加pagehide/pageshow事件兜底
<meta> 和 JS 跳转常组合使用：前者保底兼容老旧设备，后者提供交互反馈与条件控制。但两者不能共存于同一页面逻辑——JS 执行失败时才 fallback 到 meta，而不是同时启用。 
