npm依赖扁平化本质是v3起“尽力提升至根node_modules”的策略，目标减嵌套、避重复、提复用，但遇版本冲突时退为局部嵌套，导致幽灵依赖和跨项目空间浪费。
npm 依赖扁平化，本质是 npm v3 起采用的一种“尽量把依赖装到项目 node_modules 根目录”的安装策略，目标是减少嵌套层级、避免重复安装、提升模块复用率——但它不是绝对扁平，而是“尽力扁平 + 冲突嵌套”。
扁平化怎么运作：提升（Hoisting）是核心动作
npm 安装时会遍历整个依赖树，优先尝试把每个包（无论直接还是间接依赖）放到根 node_modules 下。只要版本兼容，就复用已有的包，不重复安装。
- 比如你的项目依赖
axios@1.6.0，它依赖follow-redirects@1.15.2；同时你又直接写了"follow-redirects": "^1.15.0"——npm 会只在根目录装一份follow-redirects@1.15.2，供两者共用 - Node.js 模块解析时，会从当前文件所在路径开始，逐级向上查找
node_modules，所以即使没在package.json中声明，只要该包被提升到了某层node_modules，就能require或import成功
为什么不是完全扁平：版本冲突触发嵌套
当不同依赖要求同一包的**不兼容版本**时，npm 无法在顶层同时满足，只能让其中一个“让位”，在子依赖自己的 node_modules 中单独安装。
- 例如：A 依赖
lodash@4.17.10，B 依赖lodash@4.18.0（且^4.17.10和^4.18.0不重叠），那么lodash@4.17.10会留在顶层，lodash@4.18.0则被装进B/node_modules/lodash - 这种局部嵌套就是扁平化的“退让机制”，保证各依赖按需运行，但也带来幽灵依赖和调试复杂性
扁平化带来的两个典型现象
幽灵依赖（Phantom Dependencies）：某个包未在 package.json 中声明，却因被其他依赖带入并提升，导致项目代码能直接引用它。一旦上游依赖变更或升级，这个包可能消失，引发运行时错误。
空间浪费与安装冗余：虽然扁平减少了部分重复，但不同项目之间仍各自安装完整副本；相同版本包在多个项目中无法共享磁盘空间——这点 pnpm 用硬链接+内容寻址解决了，而 npm 始终未改。
它和 package-lock.json 是什么关系？
package-lock.json 不改变扁平化逻辑，而是锁定“在当前扁平化规则下，最终生成的依赖树长什么样”。它记录每个包的确切版本、下载地址、完整性校验值，确保多人、多环境执行 npm install 得到一致的 node_modules 结构——哪怕这个结构本身仍是扁平+局部嵌套的混合体。
