团队协作中依赖混乱本质是“人管规则”失效，必须靠“工具+流程”自动兜底：统一用npm init -y初始化、严格隔离dependencies/devdependencies/peerdependencies/optionaldependencies四类依赖、用depcheck和npm-check自动扫描、在ci中固化npm ci与检查逻辑，任一失败即拦截pr。
团队协作中依赖混乱，本质是“人管规则”失效，必须靠“工具+流程”自动兜底。npm 本身不提供协作规范能力，但配合三类工具和一个固化动作，就能让依赖管理从“靠自觉”变成“不通过就合不了”。
统一初始化与 package.json 强约束
所有新项目必须执行 npm init -y，禁用手动编辑或复制旧文件。这能避免字段缺失（如 "type": "module"）、引号不一致、字段顺序错乱等隐性问题。
- name 字段强制小写、短横线分隔，且需提前校验是否与 npm 公共包重名
- version 必须为语义化版本（如
1.2.3），禁用latest、beta等模糊标识 - 团队可维护最小模板 JSON，通过脚本注入到新项目中，确保
scripts、repository、license等字段不遗漏
依赖分类必须物理隔离
四类依赖不能混用，类型错误会直接导致生产包体积膨胀、安全扫描误报、甚至运行时崩溃。
-
dependencies：仅放运行时真正调用的库，如
react、axios；安装命令为npm install axios -
devDependencies：只放构建、测试、开发工具，如
vite、eslint；安装命令为npm install eslint -D -
peerDependencies：插件类包声明宿主兼容范围，如 UI 库需写
"react": ">=18.0.0"，由使用者自行安装 -
optionalDependencies：非关键依赖，如
fsevents，安装失败不影响主流程
用 depcheck + npm-check 自动识别问题
人工 review 几乎无法发现漏装、乱装、错放类型等问题，必须靠工具扫描。
-
depcheck 检查代码与
package.json的一致性：找出已声明但未使用的包（如误装的moment），也发现已引用却未声明的包（常见于私有模块） - 执行命令：
npx depcheck --ignore-bin-package --ignores="babel-*,@types/*"，加--json可结构化输出用于断言 -
npm-check 校验依赖类型归属：
npm-check -p确保无开发工具混入生产依赖；npm-check -d防止express这类运行时依赖错进开发依赖 - 建议将
npx npm-check -p -d --skip-unused加入 pre-commit 或 CI 脚本，失败即中断
CI 中固化检查逻辑，让规范不可绕过
文档和会议管不住提交，只有 CI 失败才能真正落地。例如 GitHub Actions 中：
- 使用
npm ci替代npm install，确保完全按package-lock.json还原依赖树 - 添加步骤运行
npx depcheck，验证无冗余、无缺失 - 添加步骤运行
npx npm-check -p -d --skip-unused，验证依赖类型正确 - 任一检查失败，PR 直接被拦截，结果在 GitHub 界面清晰可见
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
