源码依赖管理实战技巧

做演示项目时，很多人只关注视觉效果和交互逻辑，却忽略了背后一个关键环节——源码依赖管理。比如你用 React 做一个动态图表展示，本地跑得好好的，换台电脑就报错 Module not found，多半是依赖没管明白。

什么是依赖？

写代码时，很少有人从零造轮子。你会用 axios 发请求，用 lodash 处理数据，这些外部代码就是“依赖”。它们通过包管理工具（如 npm、yarn）引入，记录在 package.json 里。

为什么依赖要“管理”？

不加管理的依赖就像借来的书，忘了还，别人要用时找不到。团队合作中，A 装了 v1.2.0 的图表库，B 装了 v2.0.0，接口变了，代码直接崩溃。这时候就得靠锁文件，比如 package-lock.json 或 yarn.lock，确保所有人用的版本一致。

常见问题现场还原

小李做完一个数据看板演示，发给同事预览。对方运行 npm install 后启动失败，提示找不到某个方法。查了一圈发现，小李本地用了第三方库的 alpha 版本，而这个版本没写进版本锁定文件，别人装的其实是稳定版，功能对不上。

如何正确管理依赖？

第一，明确区分 dependencies 和 devDependencies。运行时必需的库放前者，比如 react；仅用于构建、测试的工具如 webpack、jshint 放后者。这样打包部署时不会带上多余内容。

第二，提交 lock 文件到 Git。别嫌它冗长，它是保证环境一致的“配方单”。

第三，定期更新依赖，但别盲目升级。可以用 npm outdated 查看可更新项，结合 CHANGELOG 判断是否兼容。

实际配置示例

{
  "name": "demo-presentation",
  "version": "1.0.0",
  "dependencies": {
    "react": "^18.2.0",
    "chart.js": "3.9.1"
  },
  "devDependencies": {
    "vite": "^4.0.0",
    "eslint": "^8.30.0"
  }
}

像 vite 这类构建工具，只在开发阶段使用，绝不该出现在生产依赖里。否则部署体积变大，还可能引入安全风险。

自动化也能帮上忙

在 CI/CD 流程中加入依赖检查，比如用 npm ci 替代 npm install，它会严格按 lock 文件安装，避免意外版本漂移。配合 GitHub Actions，每次提交自动验证依赖完整性，提前发现问题。