Vue 编码基础
2.1.1. 组件规范
2.1.2. 模板中使用简单的表达式
2.1.3 指令都使用缩写形式
2.1.4 标签顺序保持一致
2.1.5 必须为 v-for 设置键值 key
2.1.6 v-show 与 v-if 选择
2.1.7 script 标签内部结构顺序
2.1.8 Vue Router 规范
Vue 项目目录规范
2.2.1 基础
2.2.2 使用 Vue-cli 脚手架
2.2.3 目录说明
2.2.4注释说明
2.2.5 其他
开源分享：docs.qq.com/doc/DSmRnRG…
1 高并发，以及刷接口等黑客请求对服务端的负载冲击
2 高并发时带来的超卖，即商品数量的控制
3 高负载下，下单的速度和成功率的保证
4 其他
以秒杀单品为例，如抢小米手机。
解决方案探讨：
第一步 限制前端发来的请求量
譬如定在了周二10点开启抢购，那么在之前的一周时间内，都会有预约通知，或者普通的用户浏览。通过预约量、浏览量等数据分析，大概能预估到在周二会参与“点击抢购按钮”的人数。譬如有500万。
此时，我们是知道实际商品数量的，譬如20万。
那么我是没有必要让这500万个请求都到后台的，我最多最多放200万个请求到后台。其他的300万直接就在前端网页看单机动画就好了。
这一步做起来很简单，20万个商品，我提前生成200万个token，在用户点击预约、或者浏览该商品时，就按规则发放出去。（规则可以是譬如公平模式，某个用户id已经预约多次了，还没抢到，那么给他token。也可以就是随机发放，5天的预热时间，每天发4万个就好）
前端接收到是否能参与秒杀的反馈后，就保存在浏览器本地就好，当秒杀开始时，没得到token的用户，就只好在本地看单机动画，过几秒告诉他商品不足就好了。
那些幸运的得到了token的用户，就有了给后台发请求参加秒杀的机会了，此时还需要前端（APP客户端）来对请求进行控制，因为用户喜欢反复点击、反复刷新页面等手段来参加抢购，这时就不能再放重复请求进后台了，哪怕是他重复点击了，也要保证请求不反复发送。
对于大部分吃瓜群众来说，只会操作页面的就通过这种方式控制，但对于程序员们就不行了，即便是你在抢购开始前，没有暴露抢购的接口，但在抢购开始的一瞬间，他们依旧能搞到你的下单接口地址，并开始用程序频繁提交下单请求。
第二步 由网关限制程序过量请求
用程序下单对程序员们都懂，拼接好请求的各个参数，开启并发提交到服务器。
到了这一步，已经不归前端管了，请求会直达负载均衡器，然后到后台网关。
在网关里要控制好这部分请求，要以最快的速度判断出来的每一个请求是否放行到后面的服务。
网关的实现方案有很多，kong（nginx+lua），Gateway，zuul等。在网关里可以简单的实现限流机制，我们主要限制的有如下几种：
1 黑名单（ip、用户id等），可以直接放内存里
2 过多的重复请求（可以采用redis集群计数，对同一个ip、id发起的重复请求给予拒绝），考虑到redis的带宽、性能瓶颈，可以考虑做分片，或者做二级缓存，直接在jvm内存里统计计数
3 没有token的请求，就是之前放出去那批token
限制了非常规请求后，我们假如还有100万个请求在2秒内打到了服务端，这依旧是非常恐怖的数字，即便你有10台服务器，还是有大概率被打满CPU，后面的请求就有面临5秒超时的风险。
此时，我们要做的就是尽快处理完前面的请求，把商品赶紧卖光。100万个请求，20万个商品，那肯定是不能让那80万请求去触碰下单的服务的，我们要在网关处就终结掉这80万个请求，给他们交代你来晚了。
此时你需要令牌桶，如guava的rateLimer就可以，简单好用。譬如我有20个zuul网关服务在运行，单个服务要承担5万个请求，单个tomcat在不做复杂计算、不做数据库操作，做到1-2千的QPS还是可以的。
我每一个zuul服务里譬如开辟1.5万个令牌桶，在1-3秒内放完，得不到令牌桶的就直接返回失败就行了。在这一步失败的耗时会很短，因为在网关层就失败了，不会进入到后面的下单流程。
请注意，这一步是没有用消息队列的，因为大部分请求是要被拒绝的，需要尽快的返回拒绝信息，进队列再慢慢消费就慢了。
令牌桶签发完毕，剩下的请求都是幸运儿，就可以进入到后面的下单流程了。
第三步 极速下单
下单是另外的服务，由zuul将请求转发到这里，那么以最快的速度生成订单将非常重要，不然又是大量超时。
此时数据库是指望不上了，数据库一秒2千的写入都已经比较艰难，即便是集群，想要达到万的量级也是比较困难，等你入库完毕，都半分钟过去了。
那么下单到哪呢，首选redis。你在订单请求到达后，迅速拼接好order、orderItem对象，将订单下到redis里。考虑到redis的压力，可以将redis分片，将不同的用户的订单，下到不同的redis实例中。
下到redis的目的一是速度快，二是为了做订单查询用，因为下单后用户还是要查询订单的，而此时还没有入库。在下单到redis的同时，写入到消费队列MQ中一份，这一步是用来让后端消费，并入库的。入库就可以从MQ里慢慢消费了，再去做那些耗时的入库操作，分布式事务等等。入库成功后，就可以把redis的订单删掉了。
第四步 防超卖
从上面的流程看，我们通过令牌桶放出去的令牌数是大于商品数量的，那么就面临超卖问题。
超卖在分布式环境下，方案就是分布式锁，譬如redisson的分布式锁，可以针对商品id加分布式锁。
问题又出来了，如果商品数量很少，几百几千个，通过分布式锁也能很快的处理完。实测，redis加锁、释放锁耗时约1ms，再加上客户端逻辑处理时间，按下一单要5-10ms（非常急速了），那么一秒在对同一个分布式锁的操作上，也就百单而已。
总结
- 对于框架原理只能说个大概，真的深入某一部分具体的代码和实现方式就只能写出一个框架，许多细节注意不到。
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
-
算法方面还是很薄弱，好在面试官都很和蔼可亲，擅长发现人的美哈哈哈...（最好多刷一刷，不然影响你的工资和成功率????）
-
在投递简历之前，最好通过各种渠道找到公司内部的人，先提前了解业务，也可以帮助后期优秀 offer 的决策。
-
要勇于说不，对于某些 offer 待遇不满意、业务不喜欢，应该相信自己，不要因为当下没有更好的 offer 而投降，一份工作短则一年长则 N 年，为了幸福生活要慎重选择！！！
第一次跳槽十分忐忑不安，和没毕业的时候开始找工作是一样的感受，真的要相信自己，有条不紊的进行。如果有我能帮忙的地方欢迎随时找我，比如简历修改、内推、最起码，可以把烦心事说一说，人嘛都会有苦恼的～
祝大家都有美好的未来，拿下满意的 offer。
