又又来八道让我萌币的前端面试题，你知道多少

最新推荐文章于 2024-09-06 22:20:29 发布

2401_84097696

最新推荐文章于 2024-09-06 22:20:29 发布

阅读量786

点赞数 7

分类专栏：程序员文章标签：前端 javascript html

本文链接：https://blog.csdn.net/2401_84097696/article/details/137408524

版权

程序员专栏收录该内容

255 篇文章 0 订阅

订阅专栏

// 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