uni-app如何解决H5端在移动端下由于缓存导致无法更新问题-uni-app-PHP中文网

h5端页面不更新主因是浏览器对index.html强缓存，uni-app默认构建未破坏该链路；需通过服务端禁用缓存、构建注入版本标识或history模式url重定向解决，且须排查localstorage、service worker及微信网页缓存。

uni-app如何解决h5端在移动端下由于缓存导致无法更新问题

直接结论：H5端页面不更新，90%不是CDN或Nginx问题，而是浏览器对HTML文档本身做了强缓存，且uni-app默认构建未破坏该缓存链路。

现象是：发布新版本后，用户刷新页面，Network面板里index.html状态码为304 Not Modified，甚至直接显示from memory cache——说明浏览器根本没发请求。这不是JS或CSS缓存的问题，而是HTML入口文件被协议层缓存了。

根本原因在于：index.html通常由服务端返回Cache-Control: public, max-age=3600（或类似），而uni-app的vue.config.js默认配置只处理JS/CSS/IMG的hash命名，对index.html不做版本扰动。

必须从HTML文档加载源头入手，不能只靠JS跳转或清storage。

uni-app

uni-app 是基于 Vue 的跨端开发框架，适合开发 H5、App、小程序、鸿蒙和多端业务应用。

下载

服务端响应头优先级最高：给index.html返回Cache-Control: no-cache, no-store, must-revalidate + Expires: 0。注意：仅no-cache不够，某些安卓WebView会无视；must-revalidate才是关键
构建时注入唯一标识到HTML中：在vue.config.js里用html-webpack-plugin的templateParameters传入时间戳，再在public/index.html里写<meta name="version" content="<%= htmlWebpackPlugin.options.version %>">——这本身不防缓存，但可配合后续JS逻辑做校验和重载
前端主动“欺骗”浏览器URL（仅限非Hash模式）：如果项目用的是History模式，在main.js入口加一段逻辑：
```
if (location.pathname === '/' && !location.search.includes('v=')) {
  location.replace(location.origin + location.pathname + '?v=' + Date.now());
}
```
注意：replace比assign更干净，避免多一条history记录；但Hash模式下此法失效，因#后内容不参与HTTP请求

这是最容易踩的坑。很多开发者在Hash模式下写location.href = '#/order?t=' + Date.now()，以为能触发刷新——实际完全无效，因为#及之后的内容不会发给服务器，浏览器也不会视为新URL。

正确做法是把时间戳加在#前面，例如：location.href = '/?t=' + Date.now() + '#/order'
若用uni.navigateTo跳转，它生成的URL也是Hash模式，无法携带查询参数影响HTML加载；此时必须在onLoad里检测并手动location.replace
微信内置浏览器对URL参数极其敏感，带多余?或&可能触发安全拦截，建议只用单个t参数，值用Date.now().toString(36)缩短长度

即使HTML更新了，用户仍可能看到旧界面，往往是因为以下三处被忽略：

localStorage里存的AB测试分组、埋点ID、主题偏好等——uni.clearStorage()不清理这些，得手动localStorage.removeItem('ab_group')或localStorage.clear()
Service Worker已注册并缓存了/路由——需在main.js开头加navigator.serviceWorker.getRegistrations().then(r => r.forEach(reg => reg.unregister()))（仅上线首版需要）
微信浏览器DNS预解析或HTTP/2连接复用导致旧IP响应——无法前端解决，需后端配合在index.html响应头加Clear-Site-Data: "cache"（Chrome支持，微信暂不支持，但可作为未来兼容准备）