package-lock.json是npm自动生成的依赖树快照，精确锁定每个包的实际版本、下载地址和完整性校验值，确保跨环境安装一致性；它与package.json中语义化版本范围形成互补，前者记录“实际装到了什么”，后者声明“想要什么”。
锁定和升级关键依赖版本，核心是控制 package.json 中的版本写法 + 依靠 package-lock.json 固化实际安装结果 + 按场景执行升级动作。不是靠“记住命令”，而是靠规则和流程。
用精确版本号锁定关键依赖
对 React、Vue、Axios、Lodash 等直接影响行为或兼容性的包，应禁用 ^ 和 ~，写死版本：
- 安装时加
--save-exact或直接指定版本：npm install react@18.2.0 --save-exact生成"react": "18.2.0"（无前缀） - 已有依赖想转为精确版：手动删掉
package.json中对应字段的^或~，再运行npm install，package-lock.json会自动重算并锁定子依赖 - 注意：只改
package.json不运行npm install，node_modules和lock文件不会同步更新
区分升级类型，不混用命令
日常维护、安全修复、主版本迁移，操作逻辑完全不同：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
小修小补（patch）或功能新增（minor）：用
npm outdated查哪些可升，再逐个装，例如npm install axios@1.6.8—— 显式指定，不依赖update -
主版本升级（如 @17 → @18）：必须新建分支，显式安装 + 全面测试
npm install react@18.3.1，然后检查 breaking changes，改代码，跑 E2E -
安全漏洞修复：优先跑
npm audit --audit-level=moderate，按提示执行npm audit fix；若需跨主版本才修复，用npm audit fix --force，但必须人工复核变更
靠 lock 文件守住一致性
package-lock.json 不是辅助文件，是部署可信的唯一依据：
- 必须提交到 Git，且禁止在 CI/CD 或本地执行
npm install --no-package-lock - 发现依赖不一致（比如
npm list和package.json对不上），标准做法是： 删除node_modules→ 运行npm ci（不是npm install）→ 严格按 lock 安装 -
npm ci是 CI 流程里的黄金指令：它跳过package.json解析，只读 lock 文件，失败即停，杜绝“本地能跑线上炸”的情况
自动化兜底，防人为失误
光靠人盯容易漏，加几道检查：
- CI 脚本中加入：
git diff --exit-code package-lock.json，确保 lock 变更被检出并提交 - PR 检查环节拒绝含
node_modules的提交，并确认.gitignore已声明该目录 - 可选：用
ncu（npm-check-updates）定期扫描大版本机会，但仅输出报告，不自动修改package.json—— 升级决策必须人工介入
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
