这里介绍如何组织面试的语言，如何写一份专业的简历，提供一种通用的思维模式，而不是做简历 cv，直接拷贝别人好的简历的内容
学会一种思路，应该自己能组织专业语言，书写一份合格的简历
简历部分
项目描述
项目描述的目标是什么
首先确立目标，要突出简历亮点，简历亮点一定是工作中碰到的解决周期很长，查阅很久的资料的问题，最好是项目的实际问题
如何描述，描述的流程一般是什么
分为下面几点
- 场景，在做什么项目的时候遇到了这个问题
- 调研，要写清楚市面上有没有解决方案，最后查了一圈没有好的解决方案，才去自己实现
- 设计，这里写怎么设计的，针对不同的亮点项目考察的方向都不同，如果是高级开发，一般都是要尽可能的设计要通用，能针对各种各样的前后端项目的通用
- 结果，一个方案肯定得有结果，否则方案没有意义
项目描述结构
一般都是下面的结构，前后端项目都一样
项目名
岗位（也可以理解为 参与的角色）
技术栈
项目介绍
项目亮点（也可以理解为项目详细描述）
|
也有一种很出名的结构规则 STAR原则
介绍什么情景（Situation），你接到什么任务任务（Task），有了什么行动（Action），拿到了什么结果（Result），也就是STAR原则
面试部分
仪容仪表，形象气质
这点很多人不注意，穿衣得体，头发是不是油腻的，和人对话是否带有微笑，表述的语速是不是过快，语气是不是温和等
这些软实力，很多人觉得没必要注意，但我碰到过 BOSS 确实很在意第一印象的，团队中的沟通交流是必要的，所以请注意
你懂了，你就自信了
很简单的道理，你的脑海中有你有关项目的知识，并且是你实际参与调研和开发的，在准备面试的时候去回忆一下当时的调研开发流程就可以了
但如果你是为了介绍项目亮点而介绍，那肯定会露怯，你思考一下，一个你准备了几天的大项目能和实际开发调研了几个月的项目比吗？
专业一点
介绍项目的最优表述：普通的白话 + 专业词汇
表述的结构（教你按照什么结构、思路去说）
一般是简历项目表述里面的前两部分
下面给一个例子，有点长，是关于大文件上传的
大文件上传的普遍性方案是文件分片，文件分片其实就是把整个文件上传的大事务打散为一个一个分片上传的小事务，从而降低上传失败的风险。
整个大文件上传的实现涉及到诸多的技术细节。
比如底层协议标准如何制定，协议标准决定了前后端如何交互，也就决定了前后端代码如何开发。
除了协议之外，还涉及到前端如何进行并发控制，如何高效的分片，以及涉及到后端如何存储分片，如何高效合并分片，如何保证分片的唯一性等等等等
诸多的问题吧，市面上没有形成统一的解决方案；虽然公有云上的OSS有各自的实现方案，但考虑到我们的产品可能会部署到客户的私有云上，所以最稳妥的办法还是自行实现整个大文件上传。
我首先设计的是整个上传流程。
传统的大文件上传都是在客户端先完成所有的分片，然后计算每个分片和完整的文件hash，再使用hash和服务器换取当前文件的信息。
由于hash的计算是CPU密集型的操作，这样一来就会导致长时间的客户端阻塞，虽然可以使用Web Worker来加速hash的计算，但经过我的测试，即便是使用了多线程，某些超大文件比如上了10个G的文件，在配置不太好的客户机上计算时长可以超过30秒，这是无法接受的。
因此，我对上传流程进行了优化，我假定大部分文件上传都是一个新文件上传，于是在流程上，我允许用户在获得文件完整hash之前直接上传分片，这样一来，几乎可以做到零延时的上传，等到文件整体hashi算出来之后？再问服务器补充hash数据。
基于这样的流程，于是我设计了一套标准化的文件上传协议协议主要包含四个通信标准：
1. 创建文件协议：前端使用HEAD请求向服务器提交文件基本信息，换取上传唯一token，后续的请求必须携带此token
2. hash校验协议：前端把某个分片hash或者是整个文件hash发送给服务器，得到分片和文件的状态信息
3. 分片上传协议：前端将分片的二进制数据发送到服务器存储
4. 分片合并协议：前端提示服务器可以完成分片合并了
设计好协议后，接下来就需要落实到代码的实现上在前端部分主要问题集中在两块：如何分片 和 如何控制请求流程
首先是如何分片，考虑到不同的场景可能选择不同的分片模式，比如多线程分片，比如基于时间切片（类似于React Fiber）的分片，甚至是由上层应用自行定义的分片模式。
于是在实现分片逻辑时，我使用了模版模式，剩用TS的抽象类定义好分片的整体流程，具体的子类仅需实现分片hash计算即可，这样一来就可以保持极高的灵活度。
在请求流程控制层面，由于有诸多请求需要发送，因此我开发了一套并发请求控制类以充分的利用网络带宽。
另外，由于请求过程中需要向上层抛出各种钩子，比如进度的变化，请求状态的变化等等，对这一块，我使用了发布订阅模式编写了通用的EventEmitter类，这样可以在请求过程中抛出各种事件，上层应用通过监听事件完成处理。
当然整个系统复杂度最高的还是在后端
由于我们这个项目有BFF层，需要在BFF层完成文件处理，因此我还需要针对服务器编写相应代码。
服务器最大的挑战就是如何保证每个分片的唯一性，这种唯一性即包含存储的唯一性，也包含传输的唯一性。
存储的唯一性保证了分片不会重复保存，避免了数据的冗余。
传输的唯一性保证了分片不会重复上传，避免了通信的冗余。
要保证分片不会重复保存，就必须让分片和文件解耦，分片是分片，文件是文件，分片独立保存，不从属于任何文件，文件独立记录，按照顺序依次指向不同分片，这样一来，哪怕出现两个不同文件拥有相同分片的场景，也不会在服务器出现重复存储的问题，因为分片是独立于文件的。
而要保证分片不会重复上传，就必须保证分片永不删除，如果在合并文件后删除了分片，就会导致下一次有相同分片上传时服务器找不到对应的分片文件，就必须重复上传，因此分片永不删除
最后就是合并分片的逻辑，我考虑到如果真正的把分片文件合并成一个大文件，大文件的所有数据实际上都是冗余的，而且整个合并过程极其耗时，因此我做了这样的处理。
当收到合并请求时，服务器其实仅仅做一些简单的校验即可，比如文件大小、分片数量等校验，而不进行真正的合并，仅在数据库mongodb中更新该文件的状态并生成文件访问的url地址即可。
等到用户真正访问文件时，我根据数据库中对应文件的分片记录，使用文件流依次读取分片数据，用流管道直接响应给客户端即可。
这样一来整个合并效率和文件访问效率都极高，同时服务器的存储不会有任何冗余
以上就是关于大文件上传 sdk 的技术实现
|
稍微长了一点，毕竟是说话，得有个十几二十几分钟的交流时间，这里是举例子让我们明白如何去说，而不是背，也不是了解什么大文件上传
头脑思路要清晰
其实，只要是你参与思考且花功夫做了项目的，都很清晰，前提还是得懂
项目的深度
这里很多人都有误解，说自己只有 CRUD，或者复杂一点的就是听起来比较普通的，比如大文件上传，统一组件库这种
确实，你工作中接触的就是这些，久而久之就是信息茧房，所以想要有新思路，还是得自己去想办法找思路
找到思路还要实际运用
⚠️ 这里，还要说明一点，一定记住，不是为了面试而去准备项目，面试只是表述你实际遇到的难题和解决方案的