ES Modules 本身不支持动态路径别名解析，因其 import 语句必须在编译时静态确定路径，不能含变量或运行时计算；但可通过构建工具（如 Vite、Webpack 配置 alias）、Node.js 的 import.meta.resolve() 或动态 import() 等方式间接实现。
ES Modules 本身不支持动态路径别名解析，这是由其静态分析特性决定的——import 语句必须在编译时确定模块路径，不能包含变量或运行时计算值。但你可以通过构建工具、运行时代理或 Node.js 特性间接实现类似效果。
构建工具层面配置别名（推荐）
这是最常用、最可靠的方式，利用打包器在构建阶段将别名静态替换为真实路径：
-
Vite：在
vite.config.ts中配置resolve.alias，例如：{ "@utils": path.resolve(__dirname, "src/utils") }，之后可直接写import { foo } from "@utils/helper" -
Webpack：使用
resolve.alias，支持对象或函数形式；若需“动态”逻辑（如按环境切换别名），可用函数返回不同路径 -
TS + esbuild：配合
tsconfig.json的baseUrl和paths，再让构建工具读取并生效（如 esbuild 需插件或手动传 alias）
Node.js 原生 ESM 中的替代方案
Node.js v14.13+ 支持原生 ESM，但不支持 require.resolve.paths 或 module.paths 等 CommonJS 机制。可行方式有：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
使用
import.meta.resolve()（实验性，Node.js v20.6+ 稳定）：可在顶层 await 中解析路径，但仅限于已知基础路径，无法替代 import 语句本身 -
借助
createRequire(import.meta.url)：只能用于兼容 CommonJS 模块，且不能在 ES Module 的静态 import 中使用 -
运行时动态 import()：支持字符串拼接，例如
const mod = await import(`./features/${featureName}/index.js`)，但这是动态加载，不是静态别名，也无法享受 tree-shaking
避免常见误区
以下做法在标准 ESM 中无效或不合规：
立即学习“Java免费学习笔记（深入）”；
- 写
import x from `@api/${service}`—— 语法错误，import 路径必须是字符串字面量 - 试图用
define或process.env在 import 中插值 —— 构建工具可能报错或忽略 - 依赖运行时重写
import语句（如 Babel 插件劫持 import）—— 违反 ESM 规范，破坏可移植性和工具链兼容性
轻量级运行时代理（仅限特定场景）
如果必须在无构建流程的纯 ESM 环境中模拟别名（如 Deno 或某些 Node CLI 工具），可考虑：
- 提前生成一个
aliases.mjs文件，导出映射表，再用import()动态加载对应模块 - 封装一个
loadModule(alias)函数，内部查表后调用import()，但注意它返回 Promise，无法替代同步 import 语义 - Node.js 中启用
--loader自定义加载器（高级用法），可拦截 resolve 阶段做别名替换，但复杂且影响启动性能
