核心是理清“谁装了谁、为什么装、装哪个版本、有无冲突”：package.json声明意图，package-lock.json锁定实际版本，npm ls还原逻辑依赖树，配合npm outdated/audit等命令持续维护。
要看 JS 项目中 npm 依赖管理的全景，核心是把“谁装了谁、为什么装、装的是哪个版本、有没有冲突”这四件事理清楚。不靠猜，也不靠删 node_modules 重装，而是用一套连贯的命令和视角层层展开。
从 package.json 和 lock 文件看源头约束
所有依赖关系的起点是 package.json 和自动生成的 package-lock.json。前者声明你“想用什么”，后者锁定你“实际用了什么”。
- dependencies 和 devDependencies 字段必须分清：运行时必需的包（如 react、axios）进 dependencies；仅开发构建测试用的（如 vite、eslint）进 devDependencies
- package-lock.json 不该手动改，它是 npm 安装时生成的精确快照，确保团队成员和 CI 环境安装完全一致的版本
- 留意版本写法：
^1.2.0允许补丁和次版本升级，~1.2.0只允许补丁升级，1.2.0（无符号）表示严格锁定
用 npm ls 查逻辑依赖树
npm ls 是看清依赖全景最直接的命令，它还原的是 npm 内部维护的“逻辑树”，不是磁盘上扁平的 node_modules 目录结构。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
-
npm ls --depth=0：只看顶层直接依赖（你在 package.json 里写的那些） -
npm ls lodash：查 lodash 被哪些包引入、各自用了什么版本 -
npm ls --all：展开全部嵌套层级，适合排查幽灵依赖或重复安装 - 输出中带 EXTRANEOUS 表示该包没被任何依赖声明，却存在于 node_modules 中（可能是误装或残留）；UNMET DEPENDENCY 表示某个包声明了依赖但没装上
识别并处理典型依赖问题
依赖树不是摆设，是用来定位真实故障的诊断图。
-
版本冲突：报错 ERESOLVE 或 peer dep warning 时，用
npm ls 包名找出哪些父包在拉不同主版本，再结合npm explain 包名（npm v7+）看具体冲突路径 -
幽灵依赖：代码里
require('some-unlisted-package')能跑通，但这个包不在 package.json 里——它只是因为提升被放到了顶层。用npm ls some-unlisted-package --depth=0查是否为 extraneous，再确认上游是否仍携带它 -
重复安装：比如两个组件分别依赖
lodash@4.17.21和lodash@4.18.0，npm 会保留两份。用npm ls lodash --all可直观看到多个版本共存
配合其他命令做持续维护
依赖管理不是一锤子买卖，需要日常巡检和主动干预。
-
npm outdated：列出所有可更新但尚未更新的包，含当前版、期望版、最新版三列，一眼看出滞后风险 -
npm update 包名：按 package.json 的版本范围升级（不会越级到新主版本） -
npm install 包名@latest或npm install 包名@major.minor：手动指定升级目标，适合修复已知漏洞或兼容性问题 - 定期执行
npm audit：检查已安装包是否存在安全漏洞，配合npm audit fix自动修复低危问题
