先明确两个核心概念：相对导入和非相对导入。相对导入是以、开头的路径，比如；非相对导入则直接写模块名，比如。TypeScript对这两种情况的处理逻辑完全不同------相对导入是直接相对于当前文件进行解析，而非相对导入会遍历模块解析策略配置的查找路径。
模块解析策略有两种经典模式：Classic和Node。Classic策略现在基本已被淘汰，主要保留用于向后兼容。目前项目普遍使用的是Node策略，它模拟了Node.js的模块解析行为。在tsconfig.json里配置即可启用（注：如果module设置为commonjs则默认为node策略，es2015等则默认为bundler策略，但行为与node相似）。
具体说说Node策略的解析流程。对于相对导入，比如，TypeScript会按以下顺序查找：1. 直接查找；2. 查找；3. 查找；4. 查找中的types字段；5. 查找。如果这些都不存在，才会抛出错误。
非相对导入就复杂多了。假设你在代码里写，解析器会从当前文件所在目录开始，逐级向上查找node_modules文件夹。比如当前文件路径是，解析顺序将是： -> -> 。这种逐级向上查找的机制使得我们可以在不同层级安装依赖包。
实际开发中还有个常用技巧------路径映射。在tsconfig.json的compilerOptions里配置paths字段，可以创建快捷导入路径。比如设置，就能在代码里直接写而不需要一长串相对路径。不过要注意，paths只是给TypeScript类型检查用的，如果运行时环境不支持路径映射（比如Node.js），还需要配合Webpack的alias或tsc-alias等工具进行转换。
另一个实用配置是baseUrl。设置后，所有非相对导入都会以项目根目录为基准进行解析。这样写就能直接找到对应文件，避免了这种容易出错的相对路径。baseUrl和paths经常搭配使用，让模块导入变得更简洁可靠。
当使用ES模块的import语法时，情况会有些不同。如果设置了，TypeScript会优先查找带有扩展名的文件。比如会直接查找，而不会自动添加扩展名。这点需要特别注意，建议在ES模块环境下始终写明文件扩展名。
遇到模块解析问题时，可以开启编译器的traceResolution功能。在tsconfig.json里设置，编译时就会输出详细的模块查找日志。通过分析这些日志，你能清楚地看到TypeScript在哪个步骤找到了模块，或者在哪个步骤失败了，这是调试模块问题的终极利器。
最后提醒一个常见陷阱：类型声明文件(.d.ts)的模块解析。当导入一个没有类型定义的JavaScript库时，TypeScript会尝试在目录下查找对应的声明文件。比如导入时，如果项目安装了，就会自动获取类型支持。这个机制极大地简化了对传统JS库的类型管理。
理解TypeScript模块解析的原理，不仅能快速解决日常开发中的模块报错，还能更合理地规划项目结构。下次再遇到"找不到模块"的错误时，希望你能胸有成竹地搞定它。