选对包管理工具，从源头开始规范
前端项目刚启动时，很多人随手就敲下 npm init，但其实第一步就得想清楚用哪个包管理器。NPM 虽然原生支持，但在大型团队中容易出现依赖版本不一致的问题。Yarn 和 pnpm 逐渐成为更优选择，尤其是 pnpm 的硬链接机制，节省磁盘空间的同时还能加快安装速度。
比如你和同事都在开发同一个项目，你用 npm 安装依赖，他用 pnpm，结果 node_modules 结构完全不同，运行时行为也可能出现偏差。统一使用 .yarnrc 或 .npmrc 配置文件，明确指定包管理器和 registry 地址，能避免这类“在我机器上是好的”问题。
锁定依赖版本，别让更新毁了上线前夜
曾经有个同事在发布前更新了某个 minor 版本的工具库，结果新版本悄悄改了 API，整个构建流程卡住，加班到凌晨才回滚解决。从那以后，团队强制要求所有项目必须提交 lock 文件——无论是 package-lock.json、yarn.lock 还是 pnpm-lock.yaml。
lock 文件的作用就像一份快照，确保每个人安装的依赖树完全一致。即便主版本号没变，一个 patch 更新也可能引入破坏性改动。CI/CD 流程中也应启用 ci 模式安装（如 npm ci），它会严格依据 lock 文件还原环境，比普通 install 更可靠。
合理组织依赖类型
开发阶段顺手装个工具类库，习惯性全塞进 dependencies，等打包时发现体积膨胀了一倍。生产环境根本用不到的测试框架、构建工具，应该归到 devDependencies 里。
区分清楚这两类依赖，不仅能减小部署包体积，还能避免安全扫描误报。举个例子：
npm install --save lodash <!-- 生产依赖 -->
npm install --save-dev jest <!-- 开发依赖 -->使用 pnpm 的话，还可以通过 workspace 协议在单体仓库中做本地依赖链接，避免反复发布测试内部包。
定期审计与清理过期依赖
项目跑了几个月，回头看 package.json 已经密密麻麻几十行，有些库早就不用了却一直留着。不仅增加维护成本，还可能带来安全风险。建议每月执行一次依赖检查：
npm audit
npm outdated
对于提示有安全漏洞的包，优先查看是否有官方修复版本。不要盲目升级大版本，先看 CHANGELOG 有没有 breaking change。如果某个库长期无人维护，考虑寻找替代方案或自行 fork 修复。
利用 Scripts 简化常用操作
把重复命令写进 scripts，不只是为了省几个字。统一命名规则后，新人接手项目也能快速上手。比如：
"scripts": {
"dev": "vite",
"build": "vite build",
"lint": "eslint src/**/*.{js,ts}",
"check-deps": "depcheck"
}这样团队成员只需要记住 npm run dev 就能启动服务，不需要翻文档查具体命令参数。配合 husky 和 lint-staged，在提交代码前自动运行检测，把问题拦截在早期。
私有包管理也不难
公司内部有通用组件库或工具函数，没必要每次都复制粘贴。搭建私有 NPM 仓库并不复杂，Verdaccio 这类轻量工具几分钟就能跑起来。配置好 .npmrc 指向内部 registry，就可以像使用公共包一样发布和引用私有模块。
记得设置访问权限，避免敏感代码泄露。同时保留常用公共包的代理功能，防止每次都要外网拉取。这种混合模式在内网环境中特别实用，既安全又高效。