你有没有遇到过这样的情况：一个前端项目越做越大，组件之间开始互相调用，数据传递变得混乱，改一处功能，别的地方莫名其妙出问题？这时候，依赖注入（Dependency Injection，简称 DI）可能就是你需要的那个“理线器”。
什么是依赖注入？
简单说，依赖注入就是不让你的代码直接去“找”它需要的东西，而是由外部“送”过来。比如，一个组件要获取用户信息，传统做法是自己写逻辑去调 API，而用了依赖注入，这个 API 服务会被提前准备好，直接“塞”给组件。
这就像你在咖啡店点单，不用自己去磨豆、烧水，服务员把做好的咖啡端给你——你只管喝，流程交给别人处理。
前端里怎么用？
虽然依赖注入常出现在后端框架中，但在现代前端框架里，它的思想也被广泛应用。比如 Vue 的 provide/inject，React 的 Context，甚至 Angular 本身就内置了完整的 DI 系统。
拿 React 来说，你可以把一些通用服务，比如日志、身份验证、API 客户端，通过 Context 传下去，子组件按需使用，不需要一层层手动传递 props。
const ServiceContext = React.createContext();
function App() {
const apiService = new ApiService();
const logger = new Logger();
return (
<ServiceContext.Provider value={{ apiService, logger }}>
<MainComponent />
</ServiceContext.Provider>
);
}
function useServices() {
return React.useContext(ServiceContext);
}这样，任何深层组件只要调用 useServices()，就能拿到这些服务实例，不再关心它们是怎么创建的。
实际好处在哪？
最直观的是解耦。比如测试时，你可以把真实 API 服务换成一个模拟对象，轻松跑单元测试。开发阶段，也能快速切换不同实现，比如本地 mock 数据或连接测试环境。
另一个好处是配置集中化。很多项目都有“全局设置”，比如接口地址、主题、语言包。把这些做成可注入的依赖，修改起来只需要动一处，全项目生效。
别滥用，也别忽视
不是所有组件都需要依赖注入。小项目或者独立功能，直接引入模块更简单。但当你发现多个组件都在重复初始化相同服务，或者传参链条越来越长，那就该考虑用 DI 来整理结构了。
它不解决所有问题，但能让你的代码更清晰，像整理好的抽屉，东西放在哪，心里有数。