通过 content 属性实现页面定时刷新，格式为“秒数; url=地址”，秒数为正整数，url 省略时默认刷新当前页，不依赖 JS，但会丢失状态且不推荐用于生产环境。
用
HTML 本身不支持“监听文件变化后自动刷新”，所谓“打开自动刷新”实际是靠浏览器定时重载当前页面。最轻量、无需服务器的方法就是用 标签触发页面级刷新。
它本质是让浏览器在指定秒数后，重新发起一次 GET 请求（即重新加载整个页面），适用于静态文档预览、简易状态页或开发时快速查看改动。
- 只对当前 HTML 文件生效，不依赖 JS 或服务端
- 刷新时 URL 不变，但所有 JS 状态、表单输入会丢失
- 不推荐用于生产环境，尤其含表单或交互逻辑的页面
- 部分现代浏览器（如 Chrome）在页面后台运行时会节流或暂停该刷新，实际间隔可能延长
content 参数必须带秒数和 URL，缺一不可
的行为完全由 content 属性控制，格式为 "[秒数]; url=[地址]"。常见错误是漏写 url= 或误用引号嵌套。
正确写法：
立即学习“前端免费学习笔记（深入）”；
等价于：
这两者都会在 3 秒后刷新当前页面。如果想跳转到其他页面，必须显式写出 URL：
- 秒数必须是正整数，
0表示立即跳转（慎用，易造成循环） -
url值为空或省略时，默认为当前页面（不是首页） - 不能写成
content="3; url='index.html'"—— 单引号会被当作 URL 的一部分，导致 404
和 JavaScript location.reload() 的关键区别
有人会改用 JS 实现刷新，比如：
这看起来更灵活，但有实质性差异：-
刷新会清空整个页面生命周期（包括 JS 执行上下文、Web Workers、未持久化的 IndexedDB 事务）；location.reload()同样会，但可加参数控制缓存：location.reload(true)强制从服务器获取 -
在页面解析早期就生效，即使 JS 报错或被拦截也能刷；JS 方案依赖脚本执行成功 - 若页面含
，刷新会丢失 POST 数据并弹出“确认重新提交表单”提示；JS 刷新同理，无法绕过 - 移动端 Safari 对
支持稳定；部分 WebView（如旧版 Android 内置浏览器）可能忽略或延迟执行
开发时更推荐用 Live Server 而非 meta 刷新
真正需要“保存即刷新”的场景（比如写 Markdown 预览、调试 CSS/HTML）， 是权宜之计。它无法感知文件是否真的被修改，只是机械倒计时——改了代码没保存，它照样刷；保存了但没改内容，它也刷。
更可靠的做法是用本地开发服务器：
- VS Code 安装 Live Server 插件，右键 HTML 文件 → “Open with Live Server”，它会起一个带 WebSocket 的本地服务，文件保存后自动注入刷新脚本
- 命令行用
npx live-server（需 Node.js），默认监听localhost:8080 - Python 用户可用：
python3 -m http.server 8000 --bind 127.0.0.1
，再配合浏览器插件（如 Auto Refresh Plus）监听文件变更
这些方案能精准响应保存事件，且支持热替换（CSS/图片可不刷新页面直接更新）， 做不到。
