JavaScript模块通配符导入与显式导入的最佳实践及适用场景

不同导入规范不存在绝对的对错，核心原则是与项目技术栈、打包规则、团队约定保持统一即可，以下是各类导入方式的适用场景说明：

各类导入方式的适用场景 #

• import * as debounce from 'lodash/debounce.js' // 通配符导入
  适用场景：

  • 导入的模块同时存在默认导出和多个命名导出，需要一次性获取所有导出内容
  • 导入的第三方模块后续可能调整导出方式，用该写法可避免后续调用代码修改，兼容性更强
  • 需要做命名空间隔离，避免全局命名冲突
    不适用场景：仅需要用到模块内1-2个导出内容时，该写法会引入额外的兼容处理逻辑，同时也会降低代码可读性，其他开发者无法直观判断你实际用到的模块内容。Airbnb规范禁止该写法的核心目的就是强制开发者明确声明依赖，避免冗余代码引入，更适合对代码体积要求高的前端项目。

• import debounce from 'lodash/debounce.js' // 子模块导入
  这是绝大多数业务项目的首选写法，适合单文件模块只有一个核心导出的场景，打包体积小、可读性强。

• import {debounce} from 'lodash' // 解构导入
  仅适合项目已配置完善的Tree Shaking、且使用ES Module版本依赖（如lodash-es）的场景，否则会将整个lodash全量打包到产物中，大幅提升代码体积。如果项目本身需要用到大量同库的方法，该写法比多次子模块导入更简洁。

• import _ , { debounce, throttle } from 'lodash'; // 全量+按需混合导入
  仅适合项目大量使用该库的各类方法、甚至需要用到全局挂载的工具对象的场景，否则会引入大量冗余代码，不推荐普通业务项目使用。

• import debounce from 'lodash.debounce' // 独立方法包导入
  适合仅需用到单个方法、不需要与同库其他方法共享公共代码的场景，比如小型工具库开发、Demo项目开发，依赖更轻量化。但多个独立方法包共同使用时会出现公共代码重复的问题，内存占用更高，大型业务项目不推荐。

子模块导入与独立方法包导入的选择 #

• 大型业务项目优先选择子模块导入（lodash/xxx写法），公共代码可共享，打包体积更小，后续新增同库方法也更方便
• 小型工具项目、单方法依赖场景可选择独立方法包，依赖更轻量化

普通开发者通用建议 #

优先遵循团队已有的风格指南，没有统一约定时默认使用子模块默认导入，确实有命名空间、兼容性需求时再使用通配符导入即可，无需无理由滥用通配符导入。

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