ESM中document.currentScript始终为null是规范设计而非兼容性问题，因其执行不绑定HTML script标签；应改用import.meta.url获取模块路径，或根据环境选用构建注入、错误堆栈解析等替代方案。
ESM 模块中 document.currentScript 始终为 null，这不是兼容性问题，而是规范行为——模块脚本执行时没有“当前 script 元素”的概念，它不对应 HTML 中的 <script> 标签，而是由模块加载器动态解析执行。因此，任何依赖它获取路径、判断加载上下文或做运行时分支的逻辑，在 type="module" 环境下都会静默失败。
为什么 ESM 里 currentScript 失效是设计使然
ESM 的执行模型与传统 script 截然不同：
- 模块脚本默认
defer，且作用域隔离，不共享全局变量 - 浏览器不将模块代码挂载到某个
<script src="xxx.mjs">元素上，即使写了该标签，currentScript也指向 加载器注入的内部 script 或直接为null -
import.meta.url才是 ESM 的标准替代方案，它精确返回当前模块的完整 URL（如https://example.com/src/main.mjs） - 打包工具（如 Webpack/Vite）进一步模糊物理路径，
currentScript.src即便在非模块环境里也可能指向 bundle.js，而非源文件
替代 currentScript 的可靠路径获取方式
根据运行环境选择合适方案，避免 fallback 链过长：
-
纯 ESM 项目（现代浏览器）：直接用
import.meta.url，它是标准、轻量、无需 polyfill -
需兼容 IE9–11 的老项目：放弃
currentScript，改用错误堆栈解析——在脚本顶层立即try { throw new Error() } catch (e) { extractUrlFromStack(e.stack) }，IE10+ 和主流浏览器均支持 stack 中含 script 路径 -
Webpack/Vite 打包项目：构建时通过插件（如
webpack.DefinePlugin或vite.define）把模块路径写死为常量，例如__CURRENT_SCRIPT_PATH__ = '/src/utils/logger.js'，运行时直接读取 -
混合 script + module 场景：给传统 script 显式添加
data-path属性（<script data-path="/js/config.js"></script>），再通过document.currentScript?.dataset.path读取；模块脚本则统一走import.meta.url
常见误用与规避建议
这些做法看似可行，实则隐患明显：
- 用
document.scripts取最后一个 script：在异步加载、动态插入或多个 script 并发时不可靠 - 在 ESM 中尝试
import('./config.js').then(...)后再读currentScript：动态导入返回 Promise，此时执行上下文已切换，currentScript仍为空 - 依赖
document.write注入的 script：该方式本身已被现代标准弃用，且currentScript指向的是执行document.write的那个 script，不是被写入的内容 - 用
location.href或document.URL替代：它们返回的是页面 URL，不是当前脚本路径，多页应用中完全不匹配
本质上，currentScript 是面向传统 script 的遗留 API，而 ESM 需要转向更语义化、更稳定的元信息机制。坚持用 import.meta.url 作为主力，辅以构建时注入或 stack 解析兜底，就能覆盖从现代浏览器到 IE11 的全场景。
