不推荐使用 <meta http-equiv="refresh">，因其强制整页重载，会丢失表单、破坏历史、引发重复提交，且无法携带认证信息、不支持动态间隔；应改用 setInterval + fetch 轮询或 EventSource/WebSocket 推送。
页面自动刷新用 <meta http-equiv="refresh"> 最简单，但现代开发中几乎不该用它。
为什么 <meta http-equiv="refresh"> 不推荐在实际项目中使用
它会无差别强制重载整个页面，打断用户操作、丢失表单输入、破坏历史记录，还可能触发重复提交或接口重放。搜索引擎也普遍不鼓励这类跳转式刷新。真实场景里，你真正需要的往往不是“刷新页面”，而是“更新局部数据”或“轮询状态”。
常见错误现象：502 Bad Gateway 伴随频繁刷新、用户抱怨表单清空、移动端反复弹键盘又收起。
- 它无法控制刷新时机（比如只在用户离开前暂停）
- 不能带请求头或认证信息，不适合需登录态的接口轮询
- 刷新间隔写死在 HTML 里，改起来要重新部署，不灵活
替代方案：用 setInterval + fetch 实现可控轮询
适用于仪表盘、订单状态页、聊天未读数等需要“定期检查变化”的场景。关键在于加防抖和失败处理，而不是盲目每 5 秒刷一次。
示例逻辑：
let polling = true;
const poll = async () => {
if (!polling) return;
try {
const res = await fetch('/api/status', { credentials: 'include' });
const data = await res.json();
updateUI(data); // 自行实现 DOM 更新
} catch (e) {
console.warn('轮询失败，稍后重试', e);
}
};
setInterval(poll, 8000); // 8 秒一次，比 5 秒更友好
- 把
polling设为全局变量，用户切到其他标签页时可设为false暂停 - 服务端接口必须支持
CORS或同源，否则fetch会静默失败 - 避免在
catch里直接throw，否则会中断后续轮询
更优解：用 EventSource 或 WebSocket 接收服务端推送
当状态变更频率低但实时性要求高（如工单分配、审批通过通知），轮询是浪费。这时候应该让服务端“有变化才推”，前端只管监听。
最简 EventSource 写法：
const es = new EventSource('/api/events');
es.onmessage = (e) => {
const data = JSON.parse(e.data);
if (data.type === 'order_updated') {
showNotification(data.message);
}
};
-
EventSource自动重连，且只支持 GET，适合轻量事件流 - 若需双向通信（比如发消息+收回复），必须用
WebSocket，但得自己处理断线重连和心跳 - Nginx 默认 60 秒关闭空闲连接，要用
proxy_read_timeout 300;延长
真正难的不是怎么写那行 <meta> 标签，而是判断“这里到底该不该刷新”——很多所谓“自动刷新需求”，其实只是没想清楚数据流向和用户预期。
