前端资源哈希命名是基于内容摘要生成稳定文件后缀，确保内容不变则缓存复用、内容变更则强制更新；Webpack 中应使用 [contenthash]（非 [hash]）实现按文件粒度独立哈希，Vite 则需显式配置三类输出模板并注意 [hash] 实为内容哈希截取。
前端资源哈希命名不是“给文件名加个随机数”，而是用内容摘要生成稳定、可复现的文件后缀，让浏览器只在内容变更时才拉新版本——否则缓存就形同虚设。
Webpack 中用 [contenthash] 替代 [hash]
很多人在 output.filename 里写 [hash].js，结果每次构建整个包哈希全变，哪怕只改了一行 CSS。这是因为 [hash] 是整个 compilation 的哈希，而 [contenthash] 是单个文件内容的 MD5（实际是 Webpack 内部用的 xxHash，但语义等价）。
-
[contenthash]按 chunk 粒度计算：JS、CSS、字体各自独立哈希，互不影响 - 必须配合
HtmlWebpackPlugin使用，它会自动把index.html中引用的main.js替换为main.a1b2c3.js - 若 JS 中动态
import()了某模块，该模块 chunk 也得有[contenthash]，否则热更新或懒加载会失效 - 注意：CSS 提取插件（如
MiniCssExtractPlugin）也要显式配置filename: '[name].[contenthash].css'，否则默认不带 hash
Vite 构建时启用 build.rollupOptions.output 分片哈希
Vite 默认对 assets（图片、字体）用 [name]-[hash].[ext]，但 JS/CSS 的哈希策略藏在 Rollup 配置里。不显式覆盖的话，chunkFileNames 可能还是 [name].js，导致缓存穿透。
- 必须写全三类输出模板：
entryFileNames（入口）、chunkFileNames（异步 chunk）、assetFileNames（静态资源） - 推荐写法：
entryFileNames: 'assets/[name].[hash:8].js'——[hash:8]是简写，实际是内容哈希截取前 8 位，比完整 32 位更简洁 - 如果用了
public/目录下的静态资源（如public/favicon.ico），它不会被哈希，需手动改名或走 CDN 版本号策略 - Vite 3.0+ 开始，
[contenthash]在 Vite 原生配置中不可用，只能用[hash]（但底层仍是内容哈希），文档没明说这点，容易误以为和 Webpack 一样
HTML 中引用哈希文件时，别手写路径
手写 <script src="main.ea7f2d.js"></script> 是反模式：构建后哈希变了，HTML 就引用错；本地开发又得切回无 hash 路径，徒增条件判断。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- Webpack 下必须用
HtmlWebpackPlugin，它读取 compilation.assets 生成真实文件名，并注入 HTML - Vite 下靠
import.meta.env.BASE_URL+ 构建时自动重写，但仅限import或new URL()方式引入的资源；传统
src/assets/下 - 服务端渲染（SSR）场景下，若 HTML 是后端吐的，前端构建产物哈希无法透传，必须通过构建后生成 manifest.json，再由后端读取并注入
- 注意
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
