静默的性能杀手：理解与消除现代开发中的死代码

未使用代码的隐藏成本

每个代码库都会积累包袱。声明了但从未调用的函数。赋值了但从未引用的变量。引入了但闲置的导入。这些积累的死代码不仅让你的项目变得杂乱无章，还会主动降低性能并增加维护负担。

当功能演变时，较旧的实现就像考古层一样留在背后。后果逐渐堆积：你的打包文件变得臃肿，构建时间变慢，新团队成员在不必要的复杂性中摸索，安全漏洞隐藏在被遗忘的角落。死代码是默默积累的技术债，直到你不得不面对它。

什么算是死代码？

死代码在你的代码库中有多种表现形式：

类型1：变量墓地
声明并初始化但从未被后续逻辑使用的变量。

类型2：孤立的函数和方法
不再被任何地方调用的函数定义。

类型3：冗余的导入
引入了模块但在代码中从未实际使用。

类型4：导出但无法访问
作为导出发布的组件或函数，但系统的其他部分未导入它们。

类型5：孤立的文件
整个文件——组件、工具、模块——与应用流程断开连接。

类型6：幽灵依赖
package.json中的包条目，代码库实际上从未调用或依赖。

值得注意的灰色区域：

• 暂时禁用的功能，预留未来重新启用，应标记而非盲目删除
• 工具函数应定期审查，而非立即删除，因为它们常作为安全网

寻找死代码：工具选择

多种专业工具擅长检测死代码。你的选择取决于你的技术栈和具体需求：

ts-prune：专门针对TypeScript项目，精准定位未使用的导出符号、常量和类型定义。(目前处于维护模式，没有活跃更新)

depcheck：专注于npm依赖分析，揭示被遗弃或缺失的包。

knip：一款全面的解决方案，检测未使用的依赖、孤立的导出和断开的文件，支持JavaScript和TypeScript生态系统——这是现代清理流程的核心工具。

使用knip逐步消除死代码指南

设置阶段