应优先使用 settimeout 配合 location.reload() 或 location.href 实现可控刷新，因 meta refresh 无法暂停取消、破坏 bfcache、干扰 seo、导致数据丢失且已被 chrome 标记为弃用。
meta 标签实现自动刷新，简单但有明显缺陷，不推荐在现代页面中使用；真正可控、可中断、不破坏用户体验的刷新逻辑，应该用 setTimeout 配合 location.reload() 或 location.href。
为什么 <meta http-equiv="refresh"> 不该首选
它在页面加载完成前就启动计时，无法暂停、无法取消、无法判断用户是否正在输入或滚动；SEO 友好性差，部分浏览器会忽略或降权处理；还会干扰后退缓存（bfcache），导致返回时页面白屏或重复刷新。
常见错误现象：meta 刷新后表单数据丢失、AJAX 请求被强行中断、移动端 WebView 崩溃、刷新间隔不准（尤其页面加载慢时）。
- 刷新时间从 HTML 解析开始计时，不是从 DOM 加载完成算起
- 无法监听用户交互（比如鼠标移动、键盘输入）来临时暂停
- Chrome 95+ 对含
refresh的页面限制了 bfcache，影响导航性能
用 setTimeout + location.reload() 实现可控刷新
把刷新逻辑交给 JS，就能在合适的时机启动、检查状态、甚至动态调整间隔。比如用户离开标签页时暂停，切回来再恢复。
基础写法：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
setTimeout(() => {
location.reload();
}, 30000); // 30 秒后刷新
更稳妥的做法（带暂停逻辑）：
- 监听
visibilitychange事件，在document.hidden === true时clearTimeout - 刷新前检查是否有
input、textarea获得焦点，避免打断输入 - 用
sessionStorage记录上次刷新时间，防止页面意外重载后立即再次触发
需要跳转而非刷新？优先用 location.href 而非 meta
如果目标是跳转到另一个 URL（比如登录过期跳登录页），meta refresh 会暴露跳转地址且无法加请求头；而 JS 方式可以先发校验请求，再决定是否跳转。
-
meta的content="5;url=/login"是硬编码，服务端无法干预 - JS 可以先
fetch('/api/session')，根据响应状态码决定跳转或提示 - 跳转时用
location.replace('/login')避免在历史栈留下当前页，防止用户点返回又回到过期页
真要用 meta refresh？至少避开这几个坑
仅限静态页面、无交互、无状态场景（如纯展示大屏、Kiosk 模式终端）。必须用时，请遵守：
- 不要设
content="0"—— 会导致无限循环或白屏，最低建议"1" - 不要和
<noscript></noscript>冲突：若 JS 禁用，meta仍生效，可能造成不可控跳转 - 避免在 SPA 的 index.html 中写死
meta refresh，它会覆盖路由懒加载和状态保持 - Chrome 控制台里能看到
Refresh被标记为 deprecated（已弃用），未来可能移除支持
最常被忽略的一点：自动刷新逻辑一旦嵌入生产环境，就很难被前端监控捕获 —— 它不走任何 API 请求，也不抛错，只有用户反馈“页面突然没了”，才意识到是定时器没清理干净或者 visibility 判断失效了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
