es modules缓存由http响应头控制，url是唯一标识；带哈希的文件名确保版本更新时强制加载新资源；构建工具自动注入哈希并重写路径；引擎模块缓存与http缓存相互独立。
ES Modules（ESM）本身不控制缓存，但它的加载机制天然适配浏览器 HTTP 缓存策略——关键在于模块 URL 是否变化、服务端如何响应，以及构建工具是否注入哈希。
模块 URL 是缓存的唯一标识
浏览器对 import 语句中的每个模块路径（如 ./utils.js 或 https://cdn.example.com/app-abc123.js）单独进行缓存决策。只要 URL 完全一致，浏览器就可能复用磁盘或内存缓存中的响应，无论它是 ESM 还是普通脚本。
- 相对路径（
./index.js）易受部署目录变更影响，缓存复用不稳定 - 带内容哈希的文件名（
main.a8f3b2d4.js）能确保版本更新时 URL 变化，强制加载新资源 - 动态
import()的 URL 若拼接变量（如import(`./pages/${page}.js`)），需注意服务端对通配路径的缓存头是否合理
服务端必须为 JS 模块设置合适的 Cache-Control
ESM 文件本质仍是静态资源，其缓存行为完全由 HTTP 响应头决定。推荐生产环境配置：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
Cache-Control: public, max-age=31536000, immutable—— 适用于带哈希的构建产物，一年内不重验，提升重复访问速度 - HTML 入口页建议用
no-cache或短max-age（如max-age=60），确保能及时加载新模块 URL - 避免对所有 JS 统一设
no-store，会彻底失去缓存收益，拖慢首屏和返回体验
构建工具要生成可缓存友好的模块结构
Vite、Webpack 等现代工具默认支持 ESM 输出，并在打包时自动做两件事：
- 为每个输出 JS 文件生成唯一内容哈希（如
chunk.7d9a2f1e.js），URL 变则缓存失效 - 将
import语句中的模块引用自动重写为带哈希的新路径，保证 HTML 与 JS 间的依赖一致性 - 对
node_modules中的第三方包，Vite 通常以预构建形式生成单独的deps/xxx.js，并同样打哈希，便于长期缓存
注意 ESM 的“模块缓存”与 HTTP 缓存不是一回事
JavaScript 引擎内部会对已解析的模块对象做内存级缓存（即多次 import 同一路径只执行一次顶层代码），但这发生在 HTTP 缓存之后——它不替代网络层缓存，也不影响资源是否从服务器拉取。
- HTTP 缓存决定「要不要发请求」；模块缓存决定「请求回来后要不要重新执行」
- 即使服务端返回 304（协商缓存），模块缓存仍生效；但如果服务端返回全新内容（200），模块缓存会清空并重新执行
- 无法通过 JS 删除或刷新这个模块缓存，只能靠 URL 变更或页面刷新
