package.json是需求清单，声明依赖及版本范围；package-lock.json是安装快照，确保多环境安装一致；dependencies为运行时必需，devDependencies仅开发使用；peerDependencies需宿主提供；npm install用于开发并可更新lock，npm ci用于CI/CD且严格按lock精确安装。
直接讲清楚原理和关键区别，比背答案更有效。面试官想看的是你是否真理解依赖怎么来、怎么装、怎么冲突、怎么锁定。
package.json 和 lock 文件的作用必须说透
package.json 是项目“需求清单”，声明了要哪些包、什么范围版本（比如 ^1.2.0 表示兼容 1.x 最新补丁和小版本）；而 package-lock.json 是“实际安装快照”，记录了每个包的确切版本、完整依赖树、下载地址和完整性校验值（integrity hash）。它保证多人、多环境执行 npm install 得到完全一致的 node_modules 结构。没有 lock 文件，仅靠 package.json 的语义化版本符号，很可能因安装时间不同导致装上不同子版本，引发线上 bug。
dependencies 和 devDependencies 的本质区别
不是“开发用”和“生产用”这么简单，关键是是否参与最终产物构建：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
-
dependencies：运行时必需，比如
lodash、express，打包后仍需存在；上线部署必须安装 -
devDependencies：仅开发阶段需要，比如
webpack、jest、eslint，不参与运行时逻辑；CI/CD 构建完产物后可被忽略 - 补充一点：peerDependencies 是“我期望宿主环境提供什么”，常见于插件类包（如
eslint-plugin-react要求宿主已装eslint@^8.0.0），不自动安装，由使用者自行满足
扁平化安装与幽灵依赖风险
npm 3+ 默认把依赖“提升”到根 node_modules，减少重复安装。但这也带来隐患：
- 某个包 A 用了
lodash，但没在自己的 dependencies 中声明，只因父级装了就“能跑”——这就是幽灵依赖（Phantom Dependency） - 一旦父级升级或重装，
lodash可能消失，A 就报错 - 解决方案：启用 strict-peer-dependencies 或使用 pnpm（硬链接隔离，天然杜绝幽灵依赖）
npm install vs npm ci 的核心差异
这不是“能不能用”的问题，而是场景目的完全不同：
- npm install：面向开发者，会读取 package.json + package-lock.json，但允许修改 lock 文件（如新增依赖后自动更新）；适合日常开发
- npm ci：面向 CI/CD 流水线，强制要求 lock 文件存在且不允许修改；跳过 package.json 版本范围解析，直接按 lock 精确安装；失败立即退出，不生成 node_modules 缓存；更快更稳定更可重现
真正懂的人，会把版本符号（^、~、1.2.3）、hoisting 机制、lock 文件不可提交又不可删、以及为什么 npm ci 在自动化中不可替代，串成一条逻辑线来讲。不复杂，但容易忽略细节。
