在index.ts文件中使用‘export * from’存在哪些弊端与风险？

export * from <filename>确实能省去手动维护index.ts的工作量，但也存在不少需要注意的弊端和风险：

• 导出冗余符号
  如果源文件中存在仅内部使用、却意外暴露的符号（比如未标记私有临时导出的工具函数），export *会将这类符号一并对外导出，导致模块公开API冗余，不仅可能让用户误用内部逻辑，后续清理这些内部符号时还可能引发依赖方代码报错。

• 命名冲突隐患
  当多个源文件导出同名符号时，export *会直接覆盖先导入的符号。在TypeScript中开启严格检查可能会在编译阶段提示，但在纯JS环境下可能直接引发运行时bug，且这类问题排查难度较高。比如A文件导出const util = () => {}，B文件也导出同名的util，最后对外暴露的只会是后导入文件的util。

• 公开API不清晰
  手动枚举导出的方式相当于明确对外声明了模块的公开接口，其他开发者查看index.ts就能快速知晓可用的符号。而export *会让模块接口变得模糊，无法直观区分哪些是刻意暴露的API，哪些是附带导出的内部符号，提升了使用和维护的认知成本。

• 树摇效率下降
  尽管现代打包工具（如Webpack、Rollup）支持树摇，但export *会增加工具判断符号是否被使用的难度。当源文件存在大量未被使用的符号时，export *可能导致打包产物包含冗余代码，影响最终包体积。

• TypeScript类型导出异常
  若源文件中存在类型与值同名的情况（比如type Foo = string和const Foo = 'bar'共存），export *可能引发类型引用混淆的问题，需要额外处理才能正常使用。

总结 #

如果团队能严格规范源文件的导出逻辑（仅对外暴露必要API，内部符号通过私有修饰或模块级隐藏），且可以接受API接口的模糊性，export * from能大幅降低维护成本；但如果对API严谨性、包体积或冲突规避有较高要求，手动枚举导出虽然繁琐，但能规避上述大部分问题。

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