杂七杂八的问题

Attacking-Coder

已于 2022-10-18 21:44:34 修改

阅读量266

点赞数

分类专栏：面试文章标签： javascript 前端 css html vue.js

于 2021-12-01 12:24:51 首次发布

本文链接：https://blog.csdn.net/xinbaiyu/article/details/121652713

版权

面试专栏收录该内容

71 篇文章 0 订阅

订阅专栏

url输入到渲染出页面的过程

浏览器怎么渲染前端界面

什么是reflow（重排，回流）和repaint（重绘）？

reflow：浏览器要花时间去渲染，当它发现了某个部分发生了变化并且影响了布局，就需要倒回去重新渲染

repaint：如果只是改变了某个元素的背景颜色或文字颜色等，不影响元素周围或内部布局，就只会引起浏览器的repaint，重画其中一部分。

reflow比repaint更花费时间，也就更影响性能，所以在写代码时应尽量避免过多的reflow。

什么时候会引起reflow

（1）页面初始化的时候

（2）操作DOM的时候（增加或删除DOM元素）

（3）某些元素的尺寸改了（边距，填充，边框，宽高）

（4）CSS的属性发生变化（隐藏display：none）

（5）内容改变（文本改变或图片改变而引起的的计算值的宽高改变）

（6）浏览器窗口尺寸改变（当resize事件发生时）

如何减少reflow

（1）不要逐个修改DOM样式，可以预先定义好css的class，然后修改DOM的className，将多个需要进行相同操作的元素一次修改

（2）不要把DOM结点的属性值放在一个循环里当成循环的变量

（3）当动画元素使用fixed或absolute的position时（脱离了文档流），那么在修改他们的CSS时不会发生reflow

（4）不要使用table布局，因为可能很小的一个改动都会造成整个table的重新布局

（5）在内存中多次操作结点，完成后再添加到文档中去

（6）如果要对一个元素进行复杂的操作，可以先隐藏它（display：none），操作完成后再显示

（7）对于需要经常取出的引起浏览器重排的属性值，要缓存到变量中

浏览器的同源策略

什么是同源

同源是指三个相同：

协议相同
域名相同
端口相同

为什么要用同源策略

防止恶意的网站窃取数据。不同源的客户端脚本在没有明确授权的情况下，不能读写对方的资源。

非同源会有三种行为受到限制

Cookie、LocalStorage和IndexDB无法读取
DOM无法获得
AJAX请求不能发送

不受同源限制的：

页面中的链接，重定向以及表单提交
跨域资源（图片什么的）的引入是可以的，但是js不能读写加载的内容。（如< script src=…>< /script >，< img >，< link>，< iframe >）

跨域

受同源策略的限制，不是同源的脚本不能操作其他源下面的对象。想要操作另一个源下的对象，就需要跨域。

解决跨域

降域 document.domain
设置窗口片段标识符，监听读取location.hash
window.name
HTML5的postMessage方法
LocalStorage
JSONP
WebSocket
CORS

JSONP

主要是通过script标签的src不存在跨域问题而产生的解决方法。例子如下所示

JSONP的缺点

它只支持GET请求而不支持POST等其它类型的HTTP请求
它只支持跨域HTTP请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript调用的问题。
jsonp在调用失败的时候不会返回各种HTTP状态码。
缺点是安全性。万一假如提供jsonp的服务存在页面注入漏洞，即它返回的javascript的内容被人控制的。那么结果是什么？所有调用这个 jsonp的网站都会存在漏洞。于是无法把危险控制在一个域名下…所以在使用jsonp的时候必须要保证使用的jsonp服务必须是安全可信的。

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <title>JSONP实现跨域2</title>
</head>

<body>
    <div id="mydiv">
        <button id="btn">点击开始JSONP请求</button>
    </div>
</body>
<script type="text/javascript">
    function handleResponse(response) {
        console.log(response);
    }
</script>
<script type="text/javascript">
    window.onload = function () {

        var oBtn = document.getElementById('btn');

        oBtn.onclick = function () {

            var script = document.createElement("script");

            // callback=handleResponse就是在请求成功后调用handleResponse函数
            script.src = "https://api.douban.com/v2/book/search?q=javascript&count=1&callback=handleResponse";
            document.body.insertBefore(script, document.body.firstChild);
        };
    };
</script>

</html>

CORS

这个是后端操作的，前端不用管
主要是后端通过设置"Access-Control-Allow-Origin", "*"响应头告知浏览器这个请求回来的结果可以给前端界面

注意重点来了
并不是所有的跨域请求结果都是被浏览器拦截从而使得前端得不到。而是有一些跨域请求是压根浏览器就不会给你发出去。这就需要将请求分为简单请求和复杂请求。简单请求浏览器会发送跨域请求给服务端并且会接收到请求数据。复杂请求时浏览器会提前发送一个option请求来试一下当前域名是否符合人家服务端允许的跨域请求范围，如果不符合浏览器是不会给你发这个跨域请求的。

区分`简单请求`和`复杂请求`

浏览器判定请求是否为简单请求要同时满足以下四个条件：

使用下列方法之一：

GET
HEAD
POST

只使用了如下的安全 Header，不得人为设置其他 Header

text/plain
multipart/form-data
application/x-www-form-urlencoded
Accept
Accept-Language
Content-Language
Content-Type

请求中的任意 XMLHttpRequest 对象均没有注册任何事件监听器；XMLHttpRequest 对象可以使用 XMLHttpRequest.upload 属性访问。
请求中没有使用 ReadableStream 对象。

session和cookie的区别

cookie(存在本地浏览器)

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie
客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，
以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
实际就是颁发一个通行证，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理
cookie 可以让服务端程序跟踪每个客户端的访问，但是每次客户端的访问都必须传回这些Cookie，如果 Cookie 很多，这无形地增加了客户端与服务端的数据传输量，
而 Session 的出现正是为了解决这个问题。同一个客户端每次和服务端交互时，不需要每次都传回所有的 Cookie 值，而是只要传回一个 ID，这个 ID 是客户端第一次访问服务器的时候生成的，而且每个客户端是唯一的。这样每个客户端就有了一个唯一的 ID，客户端只要传回这个 ID 就行了，这个 ID 通常是 NANE 为JSESIONID 的一个 Cookie。

缺点：

cookie可以被用户禁止
cookie不安全(对于敏感数据，需要加密)
cookie只能保存少量的数据(大约是4k)，cookie的数量也有限制(大约是几百个)，不同浏览器设置不一样，反正都不多
cookie只能保存字符串

优点：

对服务器压力小

session(存在服务器上)

Session机制是一种服务端的机制，服务器使用一种类似散列表的结构来保存信息。
当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端里的请求里是否已包含了一个session标识–sessionID，
如果已经包含一个sessionID，则说明以前已经为此客户端创建过session，服务器就按照sessionID把这个session检索出来使用
如果客户端请求不包含sessionID，则为此客户端创建一个session并且声称一个与此session相关联的sessionID，
sessionID的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串(服务器会自动创建),这个sessionID将被在本次响应中返回给客户端保存。

缺点：

当用户访问量很大时，对服务器压力大
一般是寄生在Cookie下的，当Cookie被禁止，Session也被禁止

区别

具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的

cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session

session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie

单个cookie保存的数据不能超过4k,很多浏览器都限制一个站点最多保存20个cookie。

可以将登陆信息等重要信息存放为session。

HTML元素属性href和src的区别

href是元素或文档与指定资源联通，是引用；
src是下载后嵌入构成文档直接内容。

src会阻塞其他资源的下载和处理，直到资源下载，渲染完毕才会进行下一步操作

localstorage、sessionstorage、cookie的区别

存储大小
cookie：一般不超过4k
sessionStorage：5M甚至更多
localStorage：5M甚至更多
数据有效期
cookie:一般由服务器生成，可以设置失效时间；若没有设置时间，关闭浏览器cookie失效，如果设置了时间，cookie就会存储在硬盘中，过期失效
sessionStorage：仅在当前浏览器窗口关闭之前有效，关闭页面或者浏览器会被清除
localStorage：永久有效，窗口或者浏览器关闭也会一直保存，除非手动永久删除
通信
cookie：cookie在浏览器和服务器之间来回传递，如果使用cookie保存过多数据会造成性能问题
sessionStorage：仅在客户端（浏览器）中保存，不参与服务器的通信
localStorage：仅在客户端（浏览器）中保存，不参与服务器的通信
应用场景
cookie：判断用户是否登录过网站，以便实现下次自动登录或记住密码；保存事件信息
sessionStorage：敏感账号一次性登录，单页面用的较多
localStorage：用于长期登录，适于长期保存在本地的数据