JavaScript项目依赖须通过npm/pnpm和package.json自动管理，手动操作会导致版本混乱；初始化需运行npm init -y生成标准package.json，注意name命名规范及type设为"module"；依赖分production、dev、peer三类，安装命令和写入字段不同；package-lock.json不可删改，保障依赖一致性，多人协作必须提交；升级依赖需查CHANGELOG、验间接依赖，CI应使用npm ci而非npm install。
JavaScript 项目依赖不是靠手动下载或复制粘贴来管理的，而是通过包管理器（主要是 npm 或 pnpm）配合 package.json 文件自动解析、安装、锁定和复用的。手动管依赖几乎必然导致版本混乱、构建失败、安全漏洞漏检。
怎么初始化一个可管理依赖的项目
核心是生成标准的 package.json。不写这个文件，npm install 就不知道该装什么、装到哪、是否为生产依赖。
- 运行
npm init -y快速生成默认package.json；若需定制，去掉-y会交互提问 - 确保
name字段不为空且符合 npm 命名规范（小写字母、短横线、数字，不能有空格或大写） -
type字段建议显式设为"module"（如果用 ES 模块语法），避免require()和import混用报错 - 不要手动编辑
node_modules目录或直接往里丢文件——它应完全由包管理器控制
安装依赖时如何区分 dev、prod 和 peer
不同依赖类型影响安装行为、打包结果和运行时行为。装错会导致本地能跑、CI 失败，或上线后 Cannot find module。
- 生产依赖：
npm install lodash→ 写入dependencies，会被部署并 require/import - 开发依赖：
npm install eslint --save-dev或npm install eslint -D→ 写入devDependencies，仅本地 lint/test 用，不进生产包 - 对等依赖：
peerDependencies不自动安装，由宿主项目自行提供（常见于 React 组件库声明"react": "^18.0.0"）；漏配会触发 npm 警告，但不会阻止安装 - 注意：
optionalDependencies安装失败不中断流程，适合兼容性兜底（如fsevents仅 macOS 有效）
为什么 package-lock.json 不能删也不能手改
它是依赖树的精确快照，保证所有人、所有环境安装出**完全一致**的 node_modules 结构。删掉它等于放弃可重现性。
立即学习“Java免费学习笔记（深入）”；
- 每次
npm install都会根据package.json+ 当前package-lock.json计算差异，只更新变动部分 - 若想强制重装全部依赖：先删
node_modules和package-lock.json，再npm install（不是npm update） - 多人协作时，
package-lock.json必须提交到 Git —— 否则 A 机器装的是axios@1.6.0，B 机器可能装成axios@1.6.2，而后者存在未公开的 Promise race bug -
pnpm用户注意：它用硬链接+全局 store，pnpm-lock.yaml规则不同，但作用等价，同样不可删
升级依赖时最常踩的三个坑
升级不是执行一条命令就完事。大版本跃迁（如 lodash@4 → @5）或间接依赖变更，极易引发静默故障。
- 别直接
npm update：它只升满足^或~范围的补丁/次版本，且不更新package-lock.json的顶层依赖记录 - 查清变更内容：升级前先看对应包的
CHANGELOG.md或 GitHub Releases，重点关注Breaking Changes条目 - 验证间接依赖：用
npm ls查它被谁引用、装了几个版本；多个版本共存可能引发 this is not a constructor 等诡异错误 - CI 中加
npm ci而非npm install：前者严格按package-lock.json安装，跳过解析逻辑，更快更稳
依赖管理真正的复杂点不在命令本身，而在于理解每个字段在生命周期中的语义：什么时候该写 devDependencies，什么时候必须加 resolutions 锁子依赖，以及为什么 CI 里一个锁文件差异就能让测试通过率从 100% 掉到 0%。这些细节不体现在 npm help 里，而在每天 merge conflict 的 package-lock.json 差异中。
