apache 应仅原样提供构建工具生成的带哈希文件名的静态资源，核心是设对documentroot、禁用multiviews、确保读权限与selinux上下文正确，而非用mod_rewrite做映射。

不靠 Apache 做版本映射，而是让构建工具生成带内容哈希的文件名（如 main.7a2f9e.js），再由 HTML 直接引用——Apache 只需原样提供这些文件，不干预、不重写、不猜测。这才是真正自动化、零维护、兼容现代前端工程的方案。

为什么不该用 mod_rewrite 做哈希路由

试图用 Apache 的重写规则把 /js/app.js 映射到 /js/app.a1b2c3.js 看似省事，实际带来三类硬伤：

• 每次构建后必须手动更新 RewriteRule，极易遗漏或出错
• 无法覆盖多级路径（如 /assets/css/theme/dark.b8c4d1.css）和动态嵌套结构
• 与 Webpack/Vite 等工具生成的完整哈希文件名（含 chunk hash、content hash）不匹配，规则很快失效

Apache 正确角色：安静地服务真实文件

Apache 的唯一职责是：当浏览器请求 /static/js/main.e4f5d2.js 时，检查磁盘上是否存在该路径的文件，并返回它。要做到这点，只需确保：

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

• DocumentRoot 指向构建输出目录（如 /var/www/html/dist）
• 关闭 MultiViews（在虚拟主机或目录配置中加 Options -MultiViews），避免 Apache 尝试匹配 main.js.gz 等变体而失败
• 启用 mod_mime 和 mod_deflate，使 .gz/.br 压缩文件能被自动识别并正确响应
• 确认 Apache 进程用户（如 www-data）对静态文件有读取权限，否则会返回 403 而非 404

HTML 中的资源路径必须由构建工具注入

Apache 不生成、不替换、不猜测 HTML 里的 <script src="..."></script>。这一步必须交由前端构建流程完成：

• Webpack 用户：使用 HtmlWebpackPlugin，它会自动将打包后的哈希文件名写入 index.html
• Vite 用户：默认开启 build.rollupOptions.output.entryFileNames，生成的 HTML 已含正确哈希路径
• 若手写 HTML 或用服务端模板：读取构建产出的 manifest.json（如 webpack-manifest-plugin 输出），在渲染时动态插入 URL
• 避免任何形式的硬编码，例如 <script src="/js/app.js"></script> —— 这会让缓存失效问题重现

遇到 404 但文件明明存在？按顺序排查

浏览器请求 /static/css/base.f3c9a1.css 返回 404，而该文件已部署在磁盘上，常见原因有：

• Apache 配置的 DocumentRoot 指向了错误目录（比如指向源码目录而非 dist）
• 路径大小写不一致（Linux 文件系统区分大小写，/Static/ ≠ /static/）
• SELinux 启用且未放行 httpd 访问该路径（RHEL/CentOS 上执行 setsebool -P httpd_read_user_content=on）
• 文件权限不足（如属主为 root，但 Apache 运行用户是 www-data，且无 group/o 读权限）
• 启用了 mod_security 或其他安全模块拦截了含哈希字符串的请求（少见但需验证）