ts-node使用TypeScript绝对导入时报MODULE_NOT_FOUND错误

数据老陈

2026-8-30

问题根因

报错本质是三个配置认知误区叠加导致的：

TS路径映射不等于运行时模块解析：tsconfig.json中的baseUrl、paths配置仅作用于TypeScript编译阶段的类型检查、编辑器路径提示，不会被Node.js、原生ts-node默认识别。VSCode和ESLint不报错，只是因为二者读取了tsconfig配置做静态校验，和运行时能不能找到模块没有直接关系。你之前直接抄Meteor、Remix的tsconfig配置不生效，是因为这些框架在自身的构建、运行时链路里内置了tsconfig路径映射的解析逻辑，裸ts-node运行的原生Node项目默认没有这层处理，光改tsconfig当然没用。
/开头的路径在Node.js里有固定解析规则：Node原生解析/开头的模块路径时，会直接映射到当前文件系统的根目录，而非项目根目录，这也是报错信息里直接查找/src/constants（系统根目录下的src文件夹，必然不存在）的核心原因。
你观察到的/types/t.constants导入能正常运行是错觉：这类以类型为目标的导入（不管是显式写import type还是导入内容仅含类型），会在ts-node转译阶段被完全擦除，根本不会触发运行时的文件系统寻址逻辑，自然不会抛错——哪怕你写import type { A } from '/not-exist-path'，只要类型系统能找到对应定义，运行时都不会报错，完全不能用来验证路径配置是否正确。

可行解决方案

根据你想要的绝对导入效果，选对应配置即可：

方案1：适配src目录前缀的绝对导入（最小改动）

安装ts-node官方提供的路径解析依赖，用来在运行时读取tsconfig的paths配置：
```
npm i -D tsconfig-paths
```
修改package.json中的启动脚本，在ts-node启动时注册路径解析钩子，比如原命令ts-node src/index.ts修改为：
```
ts-node -r tsconfig-paths/register src/index.ts
```
对应的npm run dev脚本也做同样修改即可。
修正tsconfig.json中的paths配置，你当前的"/*": ["*"]匹配逻辑存在歧义，直接调整为：
```
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "src/*": ["src/*"]
    }
  }
}
```
配置完成后直接写import { C } from 'src/constants'，TS静态校验和运行时加载都能正常识别。

不建议用/开头做导入前缀，非常容易和Node原生的系统根路径规则冲突，更通用的行业实践是用~代表项目源码根目录：

修改tsconfig配置：

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "~/*": ["src/*"]
    }
  }
}

后续导入统一使用import { C } from '~/constants'格式，这种写法在Node服务、Remix、React等各类TS项目中都通用，不会出现路径解析歧义。

如果你后续用tsc把TS编译为JS产物部署，tsconfig-paths仅适用于开发阶段，编译阶段需要额外用工具把别名路径替换为原生可识别的相对路径：

排查避坑点

不要写/src/xxx这类开头带斜杠的导入路径，Node原生永远会优先将其解析为系统根目录，哪怕配置了paths规则也容易出现优先级冲突。
只要出现「编辑器/ESLint不提示路径错误，但运行时报MODULE_NOT_FOUND」的现象，100%是静态校验配置和运行时解析逻辑不一致导致的，不用反复排查tsconfig写法，优先检查运行时工具（ts-node、打包器、Node本身）是否适配了路径别名规则。
不要用import type的类型导入测试路径配置是否生效，这类导入不会触发运行时模块加载，测试结果完全没有参考价值，必须用值导入做验证。

内容的提问来源于stack exchange，提问作者codingforworlddomination