npm依赖管理的“高级”体现为精准配置、分层命令、主动探查与契约维护：明确dependencies/devdependencies/peerdependencies语义，用npm ls和depcheck诊断依赖状态，按patch/minor/major粒度升级，严格以package-lock.json为安装法律依据，ci中强制使用npm ci。
JS 中 npm 依赖管理本身没有“高级编程模式”——它不写业务逻辑，也不涉及算法或数据结构，而是围绕 配置理解、命令组合、边界判断和协作契约 形成的一套工程实践能力。所谓“高级”，其实是把基础规则用得更准、更稳、更自觉。
吃透 package.json 的语义分层
很多人把 dependencies 和 devDependencies 当成“装在哪都行”的两个文件夹，但它们是项目运行时与构建时的责任切面声明：
-
dependencies：代码里
import或require了，且上线后必须存在——比如zod做请求校验、react-router-dom处理跳转 -
devDependencies：只在本地执行
npm run build、npm test时需要——比如vite、typescript、vitest -
peerDependencies：不是让你装，而是告诉使用者“你得自己配好这个环境”——比如
@tanstack/react-query声明"react": ">=18"，你项目里没装 React 就会报 warning -
optionalDependencies：装不上也不中断流程，常用于平台适配（如
fsevents仅 macOS 生效）
掌握依赖状态的主动探查能力
别等 CI 报错才去查，日常就该养成用命令“看懂当前依赖树”的习惯：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
npm ls --depth=0：一眼看清顶层装了哪些包，快速识别误装（比如eslint出现在列表里就说明进错了区） -
npm ls lodash：查某个包被谁引入、装了几份、版本是否打架 -
npm ls --all | grep UNMET：揪出未满足的 peer 依赖，React 生态里高频出问题的地方 -
npx depcheck：扫描代码中import了但 package.json 没声明的包，或已声明却从未被引用的“僵尸依赖”
升级不是“全量更新”，而是按意图分层操作
盲目 npm update 或 npx npm-check-updates -u 容易翻车。高级做法是区分变更粒度：
- PATCH 级修复（安全补丁）：
npm update axios—— 尊重^4.17.21范围，只升小版本 - MINOR 功能增强：
npx npm-check-updates -t minor改 package.json 版本号，再npm install—— 不动 lock 文件结构，但允许次版本跃迁 - MAJOR 破坏性升级：
npm install react@18—— 必须人工确认迁移文档、检查 JSX/Context/API 变更，并同步调整代码 - 锁定关键包：
npm install date-fns@2.30.0写死版本，避免因^引入不兼容行为
把 package-lock.json 当作“法律文件”来维护
它不是生成物，而是你对依赖一致性的书面承诺：
- 每次修改 package.json 后，必须运行
npm install更新 lock 文件，不能跳过 - 多人协作时，
package-lock.json必须提交 Git；遇到合并冲突，删掉它，再跑一次npm install重建 - CI/CD 中禁用
npm install，改用npm ci—— 它跳过解析，直接按 lock 文件安装，杜绝“本地能跑线上挂”的诡异问题 - 不要手动编辑 lock 文件，哪怕只是改个哈希值——npm 会校验失败并拒绝启动
