早早聊面试

npm2 优点： 结构清晰

缺点： 重复依赖

yarn/npm3： 部分扁平

优点： 不会出现重复的包，

缺点： 幽灵依赖： 你可以使用不在 package.JSON 的声明的包 依赖提升： 结构不稳定 依赖树： 打平算法很复杂，所以相对也会占用时间 依然是依赖于 copy-paste 方式，占用磁盘空间的方式

yarn：

1.优点： 1.支持并行下载安装，npm 只能串行 2.支持离线模式，优先从本地缓存中取包代码 3.```yarn set version`````切换版本，效果很向 nvm 4.yarn 2 之后支持 pnpm，效果有点像.pnpm.js 文件 也是能够节省安装时间，磁盘大小

2.缺点：

Pnpm---Performance npm，全局只有一份代码副本（content-adressable store）,其他地方都是通过硬链、软链方式，链接过去的。

优点：

1. 能够解决幽灵依赖和依赖提升

2. 结构清晰

3. 所有代码都是通过硬链接、软链方式链接到副本、不需要赋值、性能比较高、占用空间比较小

缺点： 1.软链兼容性并不是特别好，electron，实测部分包会出错 2.patch-package 不方便，全局只有一个副本

高阶： 自我思考

包管理： 在过去通过 script 标签来引入依赖，一直到 node+npm 才让这件事情变得相对优雅，导致应用的复杂度也相应的提升。 通过软链的方式链接到.Pnpm 里面的 node_module

大文件上传方案：

问题： 1.文件大，上传时间就会变得更长，中间会出现很多幺蛾子（服务端负载、网络、超时、浏览器压力） 2.普通 http，就很可能超时，重试成本非常高； 3.上传时间内，用户啥都做不了，最终体验非常差

基础： 1.化整为零：大人物拆解为多个小任务，一方面能够避免单个大任务超时，另一方面

具体方案； 1.切片： file.prototype.slice 2.计算每一个切片的顺序，hash[spark-md5],调用任务接口创建上传任务 a.服务端记录这些任务信息 3.逐个切片发送到服务器 a.服务端接收并转存这些切片，oss b.前端还需要计算上传进度（xhr 的 progress 事件监听进度） 4.所有切片上传完毕之后，再按照索引组合这些分片

优化：

1. 切片： 策略： 数量、大小 file.prototype.stream() => ReaderStream 分流： 分任务 worker stream 2.传输： 1.多个 http 请求（注意并发数量、容易超时）、websocket 提升并发度 2.内容 hash--所谓的秒传 3.使用 jszip 去做压缩（多媒体资源下，效果较弱） 3.断点续传 本地 indexed db（存储切片内容、索引、hash、任务 id 等信息） service worker 暂停功能： 借助 xhr.abort/fetch 的 AbortController 实现暂停