I belong to : Collection
主要讲了实现是基于Object.defineProperty
另外也大概阐述了发布-订阅者模式，主要是Observer，Dep，Watcher等
不支持 因为script标签只支持get请求...
标准盒模型和怪异模式
标准模式：box-sizing:content-box;
怪异模式：box-sizing:border-box;
关键代码
<input id="uploadFile" type="file" name="myPhoto" />
var fd = new FormData();//新建FormData
fd.append("myPhoto", $("uploadFile").files[0]);//塞数据
var xhr = new XMLHttpRequest(); //创建XMLHttpRequest 对象
xhr.open("post","/uploadPhoto.action", true);//打开链接
xhr.onreadystatechange = function() {//监听
if (xhr.readyState == 4) {
var flag = xhr.responseText;
if (flag == "success") {
alert("图片上传成功！");
} else {
alert("图片上传成功！");
};
};
};
xhr.send(fd);//发送flexbox
绝对定位+margin负值(子容器宽高固定)
childElement{
position:absolute;
height:200px;
width:400px;
top:50%;
left:50%;
margin-top:-100px;/*高度的一半*/
margin-left:-200px;/*宽度的一半*/
}
3. 绝对定位top left right bottom 0 + margin auto (子容器宽高固定)
```css
chilElement{
height: 150px;
width: 150px;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
margin: auto;
}（1） 不知道自己高度和父容器高度的情况下, 利用绝对定位只需要以下三行：
parentElement{
position:relative;
}
childElement{
position: absolute;
top: 50%;
transform: translateY(-50%);
}
（2）若父容器下只有一个元素，且父元素设置了高度，则只需要使用相对定位即可
parentElement{
height:xxx;
}
childElement {
position: relative;
top: 50%;
transform: translateY(-50%);
}cookie虽然在持久保存客户端数据提供了方便，分担了服务器存储的负担，但还是有很多局限性的。 第一：每个特定的域名下最多生成20个cookie
cookie的最大大约为4096字节，为了兼容性，一般不能超过4095字节。
IE 提供了一种存储可以持久化用户数据，叫做uerData，从IE5.0就开始支持。每个数据最多128K，每个域名下最多1M。这个持久化数据放在缓存中，如果缓存没有清理，那么会一直存在。
优点：极高的扩展性和可用性
缺点：
Cookie数量和长度的限制。每个domain最多只能有20条cookie，每个cookie长度不能超过4KB，否则会被截掉。
安全性问题。如果cookie被人拦截了，那人就可以取得所有的session信息。即使加密也与事无补，因为拦截者并不需要知道cookie的意义，他只要原样转发cookie就可以达到目的了。
有些状态不可能保存在客户端。例如，为了防止重复提交表单，我们需要在服务器端保存一个计数器。如果我们把这个计数器保存在客户端，那么它起不到任何作用。
Web Storage的概念和cookie相似，区别是它是为了更大容量存储设计的。Cookie的大小是受限的，并且每次你请求一个新的页面的时候Cookie都会被发送过去，这样无形中浪费了带宽，另外cookie还需要指定作用域，不可以跨域调用。
除此之外，Web Storage拥有setItem,getItem,removeItem,clear等方法，不像cookie需要前端开发者自己封装setCookie，getCookie。
但是Cookie也是不可以或缺的：Cookie的作用是与服务器进行交互，作为HTTP规范的一部分而存在 ，而Web Storage仅仅是为了在本地“存储”数据而生
浏览器的支持除了IE７及以下不支持外，其他标准浏览器都完全支持(ie及FF需在web服务器里运行)，值得一提的是IE总是办好事，例如IE7、IE6中的UserData其实就是javascript本地存储的解决方案。通过简单的代码封装可以统一到所有的浏览器都支持web storage。
localStorage和sessionStorage都具有相同的操作方法，例如setItem、getItem和removeItem等
(1) link属于HTML标签，而@import是CSS提供的;
(2) 页面被加载的时，link会同时被加载，而@import引用的CSS会等到页面被加载完再加载;
(3) import只在IE5以上才能识别，而link是HTML标签，无兼容问题;
(4) link方式的样式的权重 高于@import的权重.
BFC，块级格式化上下文，一个创建了新的BFC的盒子是独立布局的，盒子里面的子元素的样式不会影响到外面的元素。在同一个 BFC 中的两个毗邻的块级盒在垂直方向（和布局方向有关系）的 margin 会发生折叠。
W3C CSS 2.1 规范中的一个概念，它决定了元素如何对其内容进行布局，以及与其他元素的关系和相互作用。
这种方法是在所有浮动标签后面添加一个空标签 定义css clear:both. 弊端就是增加了无意义标签。
给包含浮动元素的父标签添加css属性 overflow:auto; zoom:1; zoom:1用于兼容IE6。
该方法只适用于非IE浏览器。具体写法可参照以下示例。使用中需注意以下几点。一、该方法中必须为需要清除浮动元素的伪对象中设置 height:0，否则该元素会比实际高出若干像素；
参考答案
var obj = {};
obj.__proto__ = Base.prototype;
Base.call(obj); 内存泄漏指任何对象在您不再拥有或需要它之后仍然存在。
垃圾回收器定期扫描对象，并计算引用了每个对象的其他对象的数量。如果一个对象的引用数量为 0（没有其他对象引用过该对象），或对该对象的惟一引用是循环的，那么该对象的内存即可回收。
js 的阻塞特性：所有浏览器在下载 JS 的时候，会阻止一切其他活动，直到 JS 下载、解析、执行完毕后才开始继续并行下载其他资源并呈现内容。为了提高用户体验，新一代浏览器都支持并行下载 JS，但是 JS 下载仍然会阻塞其它资源的下载（例如.图片，css文件等）。 由于浏览器为了防止出现 JS 修改 DOM 树，需要重新构建 DOM 树的情况，所以就会阻塞其他的下载和呈现。
嵌入 JS 会阻塞所有内容的呈现，而外部 JS 只会阻塞其后内容的显示，
2 种方式都会阻塞其后资源的下载。也就是说外部样式不会阻塞外部脚本的加载，但会阻塞外部脚本的执行。
CSS 怎么会阻塞加载了？CSS 本来是可以并行下载的，在什么情况下会出现阻塞加载了(在测试观察中，IE6 下 CSS 都是阻塞加载）
当 CSS 后面跟着嵌入的 JS 的时候，该 CSS 就会出现阻塞后面资源下载的情况。而当把嵌入 JS 放到 CSS 前面，就不会出现阻塞的情况了。
根本原因：因为浏览器会维持 html 中 css 和 js 的顺序，样式表必须在嵌入的 JS 执行前先加载、解析完。而嵌入的 JS 会阻塞后面的资源加载，所以就会出现上面 CSS 阻塞下载的情况。
<link>还是放在head中，用以保证在js加载前，能加载出正常显示的页面。<script>标签放在</body>前。<script>标签下载时阻塞页面解析过程，所以限制页面的<script>总数也可以改善性能。适用于内联脚本和外部脚本。<script>标签的长时间连接(可跨域)在不改变外部行为的前提下，简化结构、添加可读性，而在网站前端保持一致的行为。也就是说是在不改变 UI 的情况下，对网站进行优化，在扩展的同时保持一致的 UI。
对于传统的网站来说重构通常是：
Cache-Control 、 Last-Modified、 Expires、Etag、 max-age
是由HTTP消息头中的“Cache-control”来控制的，常见的取值有private、no-cache、max-age、must-revalidate等，默认为private。
Expires 头部字段提供一个日期和时间，响应在该日期和时间后被认为失效。允许客户端在这个时间之前不去检查（发请求），等同max-age的效果。但是如果同时存在，则被Cache-Control的max-age覆盖。
Expires = "Expires" ":" HTTP-date
例如：
Expires: Thu, 01 Dec 1994 16:00:00 GMT （必须是GMT格式）
如果把它设置为-1，则表示立即过期
Expires 和 max-age 都可以用来指定文档的过期时间，但是二者有一些细微差别
兼容，仅使用max-age不够相对值(比如:3600s)，相对的是文档第一次被请求时服务器记录的Request_time(请求时间)https://www.cnblogs.com/shixiaomiao1122/p/7591556.html https://www.cnblogs.com/slly/p/6732749.html
判断缓存是否过期步骤是：
不发生请求 强缓存： s-maxage优先于max-age优先于expires
1） 查看是否有cache-control 的max-age / s-maxage , 如果有，则用服务器时间date值 + max-age/s-maxage 的秒数计算出新的过期时间，将当前时间与过期时间进行比较，判断是否过期
2）查看是否有cache-control 的max-age / s-maxage，如果没有，则用expires 作为过期时间比较
发送请求
3）Last-Modified与ETag，ETag优先于Last-Modified
Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag（实体标识）呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：
1. Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的新鲜度
2. 如果某些文件会被定期生成，当有时内容并没有任何变化，但Last-Modified却改变了，导致文件没法使用缓存
3. 有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形
浏览器的缓存来源是怎么设置的？
看到知乎有人讨论 https://www.zhihu.com/question/64201378
一个AJAX请求从开始创建到最后的响应阶段，在其整个生命周期中，使用了哪些Javascript对象与方法?
ajaxStart()
ajaxSend()
ajaxSuccess()
ajaxStop()
load()在一个Ajax请求的生命周期中，从创建请求到提交请求到成功响应的五种状态：
UNINITIALIZED—请求尚未初始化。LOADING—请求已经初始化完成。LOADED—请求已经发送，正在等待确认。INTERACTIVE—正在从服务器下载响应数据。COMPLETE—请求/响应周期结束。application/x-www-form-urlencoded 浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据multipart/form-data这种方式一般用来上传文件。我们使用表单上传文件时，必须让form 的 enctyped 等于这个值application/json告诉服务端消息主体是序列化后的 JSON 字符串text/xmlREST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
静态资源缓存优化的最佳状态是：直接从本地缓存中读取 > 304 状态 > 200 状态。关于 HTTP 状态码，与网站性能优化有关的主要是以下几个。
尽量减少 200 状态码的请求。200 表示是一个正常的请求返回，此条优化规则要求尽可能多的减少页面的 HTTP Request 数量。常见的方法有：合并打包静态资源、使用 CSS Sprite 雪碧图合并、缓存 AJAX、使用 LocalStorage/UserData/Manifest 等本地缓存技术。
清理返回 301/302 状态码的入口链接。301 表示永久重定向，302 表示临时重定向。服务器端使用重定向返回通常是为了兼容一个旧的入口链接。我们能做的优化是，将调用旧入口的场景进行清理，直接调用重定向之后的新 URL 地址。
304 表示静态资源未更新，浏览器可直接使用本地缓存文件。通常 304 的产生与浏览器的处理机制以及服务器缓存头配置有一定的关系。304 虽然未传输文件主体内容，但 HTTP 请求的建立依然是一个可以避免的性能损耗。腾讯 KM（内部知识分享平台）上有一篇文章通过在真实海量业务场景（没记错的话是 Qzone 业务）中，正交验证 HTTP 1.0 与 1.1 协议中与缓存相关的 HTTP Header 配置，结合日志分析得出了一个最佳实践：关闭 Etag 配置，只启用 Cache-Control 与 Last-Modified 响应头。为了兼容老浏览器，可保留 Expires。 因为 Etag 的缓存方案，在经过 CDN 及网关代理服务器后，会导致缓存命中率下降。从以上「浏览器缓存检查机制流程」图上可以看出，使用强缓存（Cache-Control max-age 设置为一年）后浏览器在资源过期前不会发起 HTTP 请求，那如何保证静态资源在服务器上更新后本地的缓存也能同步更新呢？可参考百度 FIS 的「文件指纹」方案。
清理返回 404 状态码的入口链接。静态资源文件的 404 调用需严格避免，而入口页面的 404 则在所难免。通过在全站 404 页面进行产品引导与体验优化，并结合数据上报记录来源页（HTTP Referer Header 或 document.referrer），可以找到并清理 404 来源入口。对于由搜索引擎进入的来源，可通过主动提交新索引至搜索引擎，或使用 301/302 重定向的方式，有效利用起这些「被浪费的流量」。
502 服务器出错。如果是 Nginx + FastCGI 的常见架构，通常是由于 Nginx 缓冲区溢出或服务器资源被耗尽引起，针对不同的业务场景进行 Nginx 的配置优化能显著提升服务器抗压性能。
在html中，帧元素（frameset）的优先级最高，表单元素比非表单元素的优先级要高。 所有的html元素又可以根据其显示分成两类：有窗口元素以及无窗口元素。有窗口元素总是显示在无窗口元素的前面。
有窗口元素包括：select元素，object元素，以及frames元素等等。
无窗口元素：大部分html元素都是无窗口元素。
<link href=''>
<img src=''>
<frame src=''>
<script src=''>
<video src=''>
Background:url('')在firefox、chrome、opera、safari浏览器是文本节点,IE不是.所以IE是3，其它浏览器是7
<ul>
<li>javascript</li>
<li>jQuery</li>
<li>PHP</li>
</ul> 如果把代码改成这样:
<ul><li>javascript</li><li>jQuery</li><li>PHP</li></ul>
运行结果:3（IE和其它浏览器结果是一样的）
X=node.removeChild(child)把删除的子节点赋值给 x，这个子节点不在DOM树中，但是还存在内存中， 如果要完全删除对象，给 x 赋 null 值
这也是fetch很奇怪的地方：
当接收到一个代表错误的 HTTP 状态码时，从 fetch()返回的 Promise 不会被标记为 reject，而是标记为 resolve（但是会将 resolve 的返回值的 ok 属性设置为 false ）即使该 HTTP 响应的状态码是 404 或 500。
仅当网络故障时或请求被阻止时，才会标记为 reject。
默认情况下, fetch 不会从服务端发送或接收任何 cookies, 如果站点依赖于用户 session，则会导致未经认证的请求（要发送 cookies，必须设置 credentials 选项）.
fetch是比较底层的API，很多情况下都需要我们再次封装。 比如：
// jquery ajax
$.post(url, {name: 'test'})
// fetch
fetch(url, {
method: 'POST',
body: Object.keys({name: 'test'}).map((key) => {
return encodeURIComponent(key) + '=' + encodeURIComponent(params[key]);
}).join('&')
})由于fetch是比较底层的API，所以需要我们手动将参数拼接成'name=test'的格式，而jquery ajax已经封装好了。所以fetch并不是开箱即用的。
另外，fetch还不支持超时控制。
axios体积比较小，也没有上面fetch的各种问题，我认为是当前最好的请求方式