关键在于将规则转化为可执行、可检查、不可绕过的动作：1.依赖严格四类分类并匹配安装命令；2.package-lock.json必须提交且ci统一用npm ci；3.升级分日常、主版本、安全三场景，禁用npm update；4.通过depcheck、npm-check和ci脚本自动守门。
用 npm 维护团队统一的依赖规范，关键不是堆砌工具，而是把规则变成可执行、可检查、不可绕过的动作。核心落在三件事上：依赖分类必须明确、lock 文件必须受控、升级行为必须分场景。
依赖必须严格分类，安装命令不能写错
所有成员安装包时，必须按用途选命令，禁止手动改 package.json：
- 运行时真正调用的库（如 react、axios、date-fns）→ 用 npm install axios
- 只在开发/构建/测试阶段用的工具（如 vite、eslint、jest）→ 必须加 -D，写成 npm install eslint -D
- peerDependencies（如自研组件库声明 "react": ">=18.0.0"）需由使用者自行安装，不参与自动安装流程
- 全局安装（npm install -g）仅限 CLI 工具（如 http-server），严禁用于项目依赖
package-lock.json 是铁律，不是可选项
这个文件是还原一致环境的唯一依据，团队必须建立硬性约定：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 必须提交到 Git，主干分支禁止忽略或删除它
- CI/CD 和本地部署一律使用 npm ci（不是 npm install），它跳过解析，直接按 lock 文件安装
- 发现 node_modules 与 lock 不一致时，删掉 node_modules 后重新运行 npm install，绝不手动编辑 lock
- 禁止使用 --no-package-lock 或 --ignore-scripts 等跳过校验的参数
升级依赖要分场景，禁用 npm update 无脑操作
日常维护和重大变更必须走不同路径，避免“一升全升”引发线上问题：
- 日常小修小补：先运行 npm outdated 查看可更新项，确认变更日志后再逐个执行 npm install lodash@4.18.2
- 主版本升级（如 react@17 → @18）：新建特性分支，显式指定版本，同步改代码，并通过完整回归测试
- 安全修复：定期跑 npm audit --audit-level=moderate，用 npm audit fix 自动修复；若需强制升级（--force），必须人工复核并记录原因
用脚本+CI 把规范变成自动守门员
靠人盯不如靠机制，把检查嵌入开发流程中：
- 用 npx depcheck 扫描未使用或漏装的依赖，加入 pre-commit 或 PR 检查
- 用 npx npm-check -p -d --skip-unused 校验依赖类型是否放错位置
- 在 GitHub Actions 等 CI 流程中强制验证：package-lock.json 是否被修改但未提交、npm ci 是否成功、depcheck 和 npm-check 是否通过
- 所有检查失败即中断流程，不通过 PR 就不允许合入主干
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
