TypeScript导出未使用的函数、接口等是否有不良实践或成本？

嘿，这个问题问得很实在——我在维护大型Vue+TypeScript项目的时候也碰到过不少这类“僵尸导出”，来给你唠唠细节：

我把代价分成几个层面来看，从实际影响到维护成本都有：

• 编译与构建层面：
  • 对于TypeScript接口这类纯类型定义，编译后会被完全移除，所以不会增加生产环境的bundle体积。但TS编译器在类型检查阶段还是会处理这些导出，项目越大，这类冗余导出越多，编译速度可能会有细微变慢的感知。
  • 要是导出的是带实际实现的函数、类或者常量，哪怕没被使用，万一你的构建工具（比如Webpack/Vite）的Tree Shaking没生效（比如代码有副作用、用了CommonJS写法），这些冗余代码就会被打包进生产bundle，白白增加体积。
• 代码维护层面：
  • 这其实是最头疼的问题。大量未使用的导出会让代码库显得臃肿，新接手的开发者看到export interface CustomStageEvent会困惑“这个接口是给哪个模块用的？是不是我漏看了？”，平白增加理解成本。
  • 时间久了，这些废弃导出可能会被误引用，或者和后续新增代码产生不必要的耦合，等到你想重构的时候，会纠结“这个导出到底有没有人用？不敢删啊”，反而拖慢迭代效率。
• 开发体验层面：
  • 如果你开启了ESLint的@typescript-eslint/no-unused-vars规则（这是TS项目的常规配置），未使用的导出会触发报错或警告，要么你得加// eslint-disable-next-line这类忽略注释，要么就得花时间处理，影响开发流畅度。

答案是建议关注，分情况处理：

• 纯类型（接口、类型别名）的未使用导出：性能影响几乎为0，但维护成本不可忽视。建议定期清理，或者用ESLint规则自动提醒开发者避免新增这类冗余导出。
• 带实现的函数、类、常量：必须重视！尤其是项目追求性能优化的时候，这类冗余代码可能会悄悄增加bundle体积，而且维护风险更高，建议尽快清理。
• 从团队规范角度：最好在团队里约定“导出即要有明确使用场景”，或者每隔几个迭代做一次代码清理，把这类冗余导出及时删掉，避免积累成“历史包袱”。

如果你想快速扫描项目中所有未使用的导出，可以试试ts-prune这个工具，它专门针对TypeScript项目，能精准找出哪些导出没被引用，清理起来效率很高。

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