// example 3
var a={}, b={key:‘123’}, c={key:‘456’};
// b 不是字符串也不是 Symbol 类型,需要转换成字符串。
// 对象类型会调用 toString 方法转换成字符串 [object Object]。
a[b]=‘b’;
// c 不是字符串也不是 Symbol 类型,需要转换成字符串。
// 对象类型会调用 toString 方法转换成字符串 [object Object]。这里会把 b 覆盖掉。
a[c]=‘c’;
// 输出 c
console.log(a[b]);
第四题.Vue 的父组件和子组件生命周期钩子执行顺序是什么
- 加载渲染过程
父beforeCreate->父created->父beforeMount->子beforeCreate->子created->子beforeMount->子mounted->父mounted
- 子组件更新过程
父beforeUpdate->子beforeUpdate->子updated->父updated
- 父组件更新过程
父beforeUpdate->父updated
- 销毁过程
父beforeDestroy->子beforeDestroy->子destroyed->父destroyed
。
第五题.input 搜索如何防抖,如何处理中文输入
当用中文输入法的时候,这时即使我们还在拼写的时候,仍然会触发input事件。
如果你不想还没真正的输入完一个中文就触发input的时候,你可以用这几个原生的api辅助你判断是否真正输入完一个中文:
1.compositionstart,键盘按下的时候触发,此时可能你刚刚按下一个n,但是这个并不是英文输入法的n。
2.compositionupdate,每次输入中文输入法的拼音就会触发,并且这个事件触发会紧接着触发一个input事件。
3.compositionend,输入框的拼音变成中文的时候触发,或者结束中文输入也会触发(在中文输入的时候,按esc或者失去焦点)
因此,你可以在上监听这三个事件,当compositionstart和compositionupdate这两个个事件触发的时候,设置一个boolean值,然后续的input事件不要这么快去做一个逻辑,再compositionend触发时再改变这个boolean值,去操作一些事情了。
var test = document.getElementById(‘test’)
test.addEventListener(‘compositionstart’, function (e) {
console.log(‘compositionstart’)
}, false)
test.addEventListener(‘compositionupdate’, function (e) {
console.log(‘compositionupdate’)
}, false)
test.addEventListener(‘compositionend’, function (e) {
console.log(‘compositionend’)
// 去搜索
}, f
。
第六题.周一算法题之「移动零」
示例:
输入: [0,1,0,3,12]
输出: [1,3,12,0,0]
说明:
-
必须在原数组上操作,不能拷贝额外的数组。
-
尽量减少操作次数。
function zeroMove(array) {
let len = array.length;
let j = 0;
for(let i=0;i<len-j;i++){
if(array[i]===0){
array.push(0);
array.splice(i,1);
i --;
j ++;
}
}
return array;
}
第七题.(京东)写出如下代码的打印结果
function changeObjProperty(o) {
o.siteUrl = “http://www.baidu.com”
o = new Object()
o.siteUrl = “http://www.google.com”
}
let webSite = new Object();
changeObjProperty(webSite);
console.log(webSite.siteUrl);
对象传值传的是引用,但是引用是copy给函数形参。
// 这里把o改成a
// webSite引用地址的值copy给a了
function changeObjProperty(a) {
// 改变对应地址内的对象属性值
a.siteUrl = “http://www.baidu.com”
// 变量a指向新的地址 以后的变动和旧地址无关
a = new Object()
a.siteUrl = “http://www.google.com”
a.name = 456
}
var webSite = new Object();
webSite.name = ‘123’
changeObjProperty(webSite);
console.log(webSite); // {name: 123, siteUrl: ‘http://www.baidu.com’}
第八题.HTTPS 握手过程中,客户端如何验证证书的合法性
还不了解https握手的请先阅读一次安全可靠的通信——HTTPS原理
大家在网络冲浪时, 在访问一些涉及金融/支付/登录/后台等敏感业务时, 会发现这些网站都会重定向到 https:// 的 URL , 例如:
-
地址为绿色, 表示安全且可信任;
-
地址为红色, 则表示虽然开启了加密, 但网站身份未验证, 无法保证不被中间人嗅探.
从我们在地址栏敲下 https:// 网站那一刹那, 到内容显示到我们面前, 中间经过了哪些过程了? 浏览器根据什么来判断, 当前网站网址是安全的还是未验证的? 这篇文章可帮助你了解到这些. 考虑到个人知识所限, 难免有遗漏或错误之处, 如你有发现, 请在下面留言指出.
图示:
讲解:
1. Client-hello 阶段
浏览器中完成地址输入后, 解析域名获得 IP Host 地址, 浏览器会与此 Host 的443(默认, 如果指定其他端口则会连接此端口) 尝试连接, 也就是 TLS 握手协议的 Client-hello, 上图的第一步.
浏览器会将"支持的加密组件"/"尝试连接到Host头"等信息发送给服务器, 并会附上一份随机生成的 session ticket1.
2. Server-hello 阶段
服务器收到浏览器发送来的 TLS 握手请求后, 存储浏览器发送的session ticket2, 然后根据发送来的 host 寻找对于的服务器证书, 然后会将服务器证书, 服务器与浏览器妥协(均支持)的加密套件方法, 和一份随机生成的 session ticket 返回给浏览器.
3. Cipher-spec 阶段
浏览器收到服务器返回的证书后, 会验证证书有效性. 验证步骤大概如下:
-
验证证书有效期(起止时间)
-
验证证书域名(与浏览器地址栏中域名是否匹配)
-
验证证书吊销状态(CRL+OCSP), [见本文后"吊销检查"章节].
-
验证证书颁发机构, 如果颁发机构是中间证书, 在验证中间证书的有效期/颁发机构/吊销状态. 一直验证到最后一层证书, 如果最后一层证书是在操作系统或浏览器内置, 那么就是可信的, 否则就是自签名. [见本文后"签发者"章节]
以上验证步骤, 需要全部通过. 否则就会显示警告.
若检查通过, 随机生成一份 session ticket 3 (这是浏览器生成的第二份 ticket), 通过返回证书中的公钥, 用协商的"秘钥交换算法"加密, 返回给服务器.
同时浏览器用 session ticket 1(浏) & session ticket 2(服) & session ticket 3(浏) 组合成 session key.
服务器收到 Ciper-spec 后, 用配置的私钥, 解密出 session ticket3, 用 session ticket 1(浏) & session ticket 2(服) & session ticket 3(浏) 组合成 session key.
此处不难得知, 服务器与浏览器交换的最终秘钥, session key全等且未泄露(session ticket 1 和 session ticket 2可以抓包, 但session ticket 3是无法窃听的).
为什么session ticket 3无法窃听?
有个 webtrust 组织, 专门负责备案世界上各国商业与政府官方 CA 机构的公钥证书. 如果审计通过, 其他浏览器及操作系统/客户端才允许加入信任列表. 否则是不允许加入的. 如果中间人拦截了 session ticket 3 的响应密文, 没有私钥, 中间攻击人是解密不了的. 而要想拿到私钥, 攻击人可以做到, 就是在客户端和服务器中间搭建代理, 替换掉 SSL 证书, 以实现服务器返回证书时候中间替换自己的, 从而在中间拦截服务器和客户端两头的通信.
但是如果这样做, 浏览器和客户端会显示非信任的颁发者, 如下图 chrome 和 curl 命令行下分别警告:
4. 内容传输阶段
至此, TLS 连接建立完成, 在连接销毁前, 浏览器与服务器彼此数据均通过 session key 来进行对称加密.
通过
上述过程, 其实是别有用心的, 因为非对称加密非常消耗 CPU. 所以只有在协商秘钥时候使用非对称加密, 而应用层数据交换就用协商成功的秘钥作为私钥对称加密传输(服务器响应的加密返回, 客户端提交的也加密提交).
吊销检查:
目前写进国际标准的吊销状态检查协议有两种: 1.CRL, 2. OCSP
CRL 是一份全量的文件, 记录了被此 CRL 限制的证书中所有被吊销证书的序列号. 通过匹配当前证书序列号, 与 CRL 中序列号, 来判断.
-
有点绕, 反正就说, 所有打上了这个 URL 的 CRL 的证书, 只要其中一个被吊销, 那么下次 CRL 更新时, 均会查询匹配到.
-
那么可不可以认为一个中间颁发机构颁发的证书的 CRL 列表只有一个? 不可以! 因为数量可能太多, 厂商完全可以将同一个中间证书颁发的最终证书, 分不同批打不同的 CRL.
而 OCSP 是 TCP 服务, 通过请求证书序列号, 服务器告知当前序列号是否在被吊销名单.
有的证书内置了 CRL+OCSP, 有点只内置了 OCSP, 还有的早起证书只内置了 CRL, 但只内置 CRL 的证书是不被新型浏览器信任了.
请思考:
问: 吊销状态检查, 是同步的还是异步的?
答案: 同步的.
如果异步检查, 有可能会导致浏览器发送数据给了未验证的主机后, 过了一段时间才检查出来证书已吊销. 所以, 必须同步
签发者:
证书的签发者, 通过以下步骤获得
1. 服务器证书, 如果包含了证书链, 浏览器会尝试匹配(根据当前证书的"签发者公钥"匹配链中的后续证书的"公钥"), 如果匹配失败, 走2.
2. 中如果有声明 签发者 URL, 浏览器尝试下载. 并通过公钥匹配(同1), 如果匹配失败, 走3
3. 操作系统或客户端浏览器内置证书公钥匹配, 如果匹配失败, 则返回ERR_CERT_AUTORITY_INVALID.
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数前端工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Web前端开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:前端)
![](https://i-blog.csdnimg.cn/blog_migrate/c8de6c3047d23e5a54df49da3d06795a.jpeg)
前端面试题是我面试过程中遇到的面试题,每一次面试后我都会复盘总结。我做了一个整理,并且在技术博客找到了专业的解答,大家可以参考下:
由于篇幅有限,只能分享部分面试题,完整版面试题及答案可以【点击我】阅读下载哦~无偿分享给大家
感悟
汇总
前端面试题是我面试过程中遇到的面试题,每一次面试后我都会复盘总结。我做了一个整理,并且在技术博客找到了专业的解答,大家可以参考下:
由于篇幅有限,只能分享部分面试题,完整版面试题及答案可以【点击我】阅读下载哦~无偿分享给大家
感悟
春招面试的后期,运气和实力都很重要,自己也是运气比较好,为了回馈粉丝朋友们(毕竟自己也玩了这么久哈哈哈),整理个人感悟和总结以上。最后祝愿大家能够收获理想offer!!