第 6 卷

• 由㇐个父窗口打开的新窗口会共享同㇐个 sessionStorage。
• 手动通过 URL 打开各自的标签页，sessionStorage 不共享。
• 受同源策略限制。
• 无痕模式下，从父窗口打开同源新窗口也无法共享 sessionStorage。

localStorage

• 除非用户手动清除，localStorage 永远不会自动失效。
• 受同源策略限制。
• 浏览器无痕浏览模式下，localStorage 会在私密窗口下最后㇐个标签页关闭时清除。

CSS

如何理解浮动？和绝对定位的区别是什么？

什么是 BFC？触发 BFC 的条件是？常见应用是啥？

• Block Format Context，块级格式化上下文
• ㇐块独立的渲染区域，内部元素的渲染不会影响边界以外的元素

触发 BFC 的条件是：

• float 不是 none
• position 是 absolute 或 fixed
• overflow 不是 visible

● display 是 flex、inline-block 等常见应用：

• 清除浮动

什么是层叠上下文？

DOM

移动端 300ms 延迟是指什么？

早期的网站都是为 PC 端而设计，而在移动端访问就会显得大小不合适。iPhone 发布之前，就针对这个问题提出了双击缩放的概念。但是这就带来了㇐个问

题，如何判断㇐个用户到底是想点击㇐个元素，还是想双击缩放呢？早期移动端浏览器就只能在 touchend 事件之后再等待 300ms，判断用户是不是会再次点

击，如果用户在 300ms 内不会再次点击屏幕就触发 click 事件。但是这样就会造成 300ms 的延迟。

点击穿透问题？

框架

Vue

数据流问题响应式原理双向绑定原理依赖收集的过程

Patch 过程 nextTick 原理

watch 和 computed 原理

computed 是怎么收集依赖的？

watchEffect 是怎么收集依赖的？

React

HTTP

cookie

HTTP 协议本身是无状态的，而Cookie 是在 HTTP 中的㇐个请求头，用来保存㇐小块数据，Cookie 会传递到服务端，用来作为会话标识。服务端可以通过

Set-Cookie 来设置 cookie，而客户端网页也可以通过 document.cookie 来操作 cookie。

document 操作 cookie

document.cookie 是可以读取所有 cookie 的，最后的值是类似这样的㇐段字符串。

1 document.cookie;

2 "remember=1; token=O3gZSC2uNLeHOO%2B%2Frvcrj9Xl%2F2lze6px7CE5DDyOr%2FfJH

增和修改

1 document.cookie = "test=1; path=/; domain=localhost; max-age=100; expire

path 和 domain 限制了 cookie 的有效路径和域名。不过 path 限制是可以被绕过的，可以创建㇐个

iframe 打开特定 path，然后通过 iframe 的 document.cookie 读取到。保护 cookie 不被非法访问的唯

㇐方法是将它放在另㇐个域名或子域名之下, 利用同源策略保护其不被读取。

max-age 不支持低版本的 ie，所以和 expires 是结合起来用的，max-age 的优先级更高！expires 使

用的是 GMT（格林威治）时间。

注意，secure 控制的是，仅在 https 协议中传输该 cookie。

删除㇐个 cookie 只要给它的 max-age 设置为-1 即可。

cookie 的过期控制

cookie 可以通过 max-age 和 expires 控制过期时间，如果不设置过期时间，cookie 会在浏览器完全关闭时失效。

防止cookie 被 javascript 脚本操作

可以在 Set-Cookie 时使用HttpOnly控制。㇐定程度上缓解XSS 攻击

服务端 Set-Cookie

㇐个 Set-Cookie 也只能设置㇐个 cookie，如果需要设置多个，则返回多个 Set-Cookie 头。

Set-Cookie 和 document.cookie 操作类似，但是要注意两个选项，分别是 HttpOnly 和 SameSite，

HttpOnly在上㇐小节说过了。SameSite 则是预防 CSRF 攻击的㇐种手段，允许服务器要求某个 cookie 在跨站请求时不会被发送。

• SameSite=Strict：跨站请求时，不携带 cookie。
• SameSite=Lax：宽松的，跨站请求时，也不会携带 cookie。但是从外部站点导航到本站点时会携带 cookie。Lax 是高版本 Chrome（80 版本以上）的

默认设置。

Lax 保证了这种场景可用：比如你在 github 已经登录过了，现在希望通过另外㇐个网站的链接跳转到 github，并且能保持 gitlab 的登录态，就需要用到

Lax。而Strict 会阻止这㇐行为，这可能会要求你重新登录 github。

• SameSite=None：不做限制，跨站请求时，会携带 cookie。使用SameSite=None 时，需要配合 Secure 使用，也就是要求 Https 协议下才能使用

None。

跨站 cookie

恶意的跨站传递 cookie

在被恶意注入的情况下（比如 XSS），就可能导致本站点的 cookie 泄露。比如㇐个论坛留言板块，被 XSS 注入了㇐段脚本，脚本会动态加载㇐张图片，图片的

地址可能是黑客服务。

这样㇐来，只要用户打开留言板块，自己的cookie 信息就泄露了，就有可能被黑客冒充身份，造成损失。

业务需要的共享 cookie

为了满足类似于单点登录这样的功能，我们在统㇐认证平台authgateway.myenterprise.com 登录后，希望公司内部另㇐个站点 other.myenterprise.com 也

能共享这种登录状态。那么服务器端在 authgateway.myenterprise.com 登录成功后，应该 Set-Cookie 时将 domain 部分设置为

myenterprise.com，这样 myenterprise.com 的各个子域名才能共享登录状态。

但是这样也有风险，㇐旦某个子站被XSS，就有可能全部被攻击（Cookie 作用域攻击）。最好启用全站 HTTPS+Secure，也必须适当缩小cookie 的作用域

（限制 domain 和 path）。

cookie 篡改

这个就很好理解了，document.cookie 是可以操作 cookie 的，这就留下了㇐些隐患，对于关键 cookie 信息，必须启用HttpOnly 防护。

cookie 劫持

如果没有 HTTPS 证书的保障，cookie 也是明文传输，相当于裸奔。除了 XSS 攻击劫持 cookie，攻击者还可以通过中间人攻击获取 HTTP 报文中的

cookie。对于这些劫持情况，应该对 cookie 加密/ 签名或者采用Https 防范！强缓存和协商缓存