不能也不该去除哈希，因其是防止浏览器缓存旧代码的核心机制；哈希为文件内容指纹，内容变则URL变，确保用户加载新版资源，而index.html缓存问题才是更新失败的主因。
不能也不该去除。uni-app H5 打包后静态资源（app.js、chunk-vendors.js、index.css 等）默认带哈希值（如 app.8a3b1c2d.js），这是防止浏览器缓存旧版本代码的核心机制——强行去掉哈希，等于主动放弃缓存更新控制权。
为什么 webpack 默认加哈希？
哈希值本质是文件内容的指纹：[contenthash:8] 只在 JS/CSS 内容变化时才改变。用户首次加载后，浏览器缓存该文件；你发新版时，只要内容变了，哈希就变，URL 就不同，浏览器会当作全新资源拉取，旧缓存自动失效。
若去掉哈希（比如硬写成 app.js），哪怕只改一行代码，文件名不变，浏览器大概率继续用本地缓存的旧 app.js，用户永远看不到更新——尤其在微信内置浏览器、钉钉 WebView 这类强缓存环境里，连 Cache-Control 响应头都可能被无视。
vue.config.js 里禁用哈希的后果
有人尝试在 vue.config.js 中把 output.filename 改成 "js/app.js"，表面看去掉了哈希，但实际带来三个硬伤：
- 每次构建覆盖同名文件，CDN 或 Nginx 缓存层可能仍返回旧内容（因 ETag/Last-Modified 未及时刷新）
- 无法并行部署多版本（灰度、AB 测试失效）
- 必须依赖强制刷新或清缓存才能生效，对用户零友好
真正要动的是 index.html 的缓存策略
问题常被误读为“JS 没更新”，其实根因是 index.html 被长期缓存了——它不带哈希，默认被浏览器缓存数天甚至数月，导致页面始终加载旧 HTML，进而引用旧 JS。
解决重点不在删 JS 哈希，而在确保 index.html 每次都拉新：
- 用
html-webpack-plugin配置filename: "index.[contenthash:6].html"（需配合 Nginx 重定向或服务端路由兜底） - 更稳妥的做法：Nginx 对
index.html强制返回Cache-Control: no-cache, must-revalidate - 若用 PWA，必须配
clientsClaim: true和skipWaiting: true，否则 Service Worker 不接管新 HTML
哈希不是装饰，是缓存治理的基础设施。与其费力“去掉”，不如确认它是否真按内容生成（检查 dist 目录下两次构建的 JS 文件名是否随代码变更）、以及 HTML 是否被正确刷新——这才是线上用户能否看到新版的分水岭。
