前端面试资源整理（一）

Js相关

执行环节和作用域

执行环节定义了函数或者变量可以访问的其它数据，决定了他们各自的行为。
每个执行环境都有一个与之关联的变量对象，在环境中定义的所有变量和函数都保存在这个变量中，并且是我们无法访问。
每个函数都有自己的执行环境，当执行流进入一个函数的时候，就把函数的执行环境压入执行环境栈，执行完毕后，再将环境推出，把控制权交给之前的执行环境。

当代码在一个环境中执行的时候，会创建变量对象的作用域链，作用域链的用途是保证对执行环境有权访问的所有变量和函数的有序访问。
作用域链的前端,始终都是当前执行代码所在环境的变量对象.如果这个环境是函数,则将其活动对象作为变量对象.作用域链中的下一个变量对象来自包含环境,最终到全局对象window.
延长作用域链 try catch 和 with语句.

垃圾回收机制

1. 标记清除 (比较常用)

垃圾收集器在运行的时候会给存储在内存中的所有变量都加上标记,然后,他会去掉环境中的变量以及被环境中变量引用的变量的标记.
而在此之后有标记的变量将被视为准备删除的变量.

1. 引用计数.

跟踪记录每个值被引用的次数 ,通过引用来适当增加他的引用次数,当引用计数为0时,表明该变量可以被清除.

typeof 操作符

undefiend/变量未定义 boolean/布尔值 string/字符串 number/数值 object对象或者null function/函数 symbol/Symbol

相等(==)规则

1. 如果有一个操作数为布尔值,则先转为数值(false 0 true 1);
2. 如果一个操作数为字符串,另一个为数值,将字符串转换为数值
3. 如果一个操作数为对象,另一个不是,调用对象的valurOf方法,用得到的原始值调用之前的规则比较;

[注意]:

1. null和 undefiend是相等的;
2. 比较之前,不能见null和undefined转换为其他任何值;
3. 如果有一个操作数为NaN,返回false,即便两个NaN比较也是false
4. 如果两个都是对象,比较是不是同一个对象,如果两个操作数指向同一个对象,返回true.

全等(===)规则

全等比较前不会转换操作数,其他情况一样.

浏览器缓存

可以分为 强缓存和协商缓存

1.强缓存：不会向服务器发送请求，直接从缓存中读取资源，在chrome控制台的network选项中可以看到该请求返回200的状态码，并且size显示from disk cache或from memory cache；

2.协商缓存：向服务器发送请求，服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存，如果命中，则返回304状态码并带上新的response header通知浏览器从缓存中读取资源；

3.两者的共同点是，都是从客户端缓存中读取资源；区别是强缓存不会发请求，协商缓存会发请求

强缓存

Expires：response header里的过期时间，浏览器再次加载资源时，如果在这个过期时间内，则命中强缓存。

Cache-Control：当值设为max-age=300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。

Expires和Cache-Control:max-age=* 的作用是差不多的，区别就在于 Expires 是http1.0的产物，Cache-Control是http1.1的产物，两者同时存在的话，Cache-Control优先级高于Expires；在某些不支持HTTP1.1的环境下，Expires就会发挥用处。所以Expires其实是过时的产物，现阶段它的存在只是一种兼容性的写法

协商缓存

ETag和If-None-Match：这两个要一起说。Etag是上一次加载资源时，服务器返回的response header，是对该资源的一种唯一标识，只要资源有变化，Etag就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到request header里的If-None-Match里，服务器接受到If-None-Match的值后，会拿来跟该资源文件的Etag值做比较，如果相同，则表示资源文件没有发生改变，命中协商缓存。

Last-Modified和If-Modified-Since：这两个也要一起说。Last-Modified是该资源文件最后一次更改时间，服务器会在response header里返回，同时浏览器会将这个值保存起来，在下一次发送请求时，放到request header里的If-Modified-Since里，服务器在接收到后也会做比对，如果相同则命中协商缓存。

区别

首先在精确度上，Etag要优于Last-Modified。Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度；如果是负载均衡的服务器，各个服务器生成的Last-Modified也有可能不一致。

第二在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。

第三在优先级上，服务器校验优先考虑Etag。

浏览器缓存过程

浏览器第一次加载资源，服务器返回200，浏览器将资源文件从服务器上请求下载下来，并把response header及该请求的返回时间一并缓存；

下一次加载资源时，先比较当前时间和上一次返回200时的时间差，如果没有超过cache-control设置的max-age，则没有过期，命中强缓存，不发请求直接从本地缓存读取该文件（如果浏览器不支持HTTP1.1，则用expires判断是否过期）；如果时间过期，则向服务器发送header带有If-None-Match和If-Modified-Since 的请求；

服务器收到请求后，优先根据Etag的值判断被请求的文件有没有做修改，Etag值一致则没有修改，命中协商缓存，返回304；如果不一致则有改动，直接返回新的资源文件带上新的Etag值并返回 200；

如果服务器收到的请求没有Etag值，则将If-Modified-Since和被请求文件的最后修改时间做比对，一致则命中协商缓存，返回304；不一致则返回新的last-modified和文件并返回 200；

用户行为对浏览器缓存的控制

地址栏访问，链接跳转是正常用户行为，将会触发浏览器缓存机制；

F5刷新，浏览器会设置max-age=0，跳过强缓存判断，会进行协商缓存判断；

ctrl+F5刷新，跳过强缓存和协商缓存，直接从服务器拉取资源。

跨域

什么是跨域

说到跨域,首先就要提到一个前端的安全概念,即浏览器的同源策略.
简单来说,就是浏览器为了保证用户信息的安全，防止恶意的网站窃取数据,只允许同源的js脚本操作本页面。
那如果我们需要在同一个页面中请求非同源的数据怎么办呢？这个就涉及到跨域问题了。

什么是同源

同源需要同时满足以下三个条件：

1. 协议相同
2. 域名相同
3. 端口相同

注意：父域名一样，子域名不一样也是非同源的。

同源限制

如果非同源,以下三种行为将受到限制:
（1） Cookie、LocalStorage 和 IndexDB 无法读取。
（2） DOM 无法获得。
（3） AJAX 请求不能发送。

跨域方法

1. JSONP

这是一种最常用也是支持度比较高的跨域方式，其原理动态插入script标签，通过script标签引入一个js文件，这个js文件载入成功后会执行我们在url参数中指定的函数，并且会把我们需要的json数据作为参数传入。

优点是兼容性好，简单易用，支持浏览器与服务器双向通信。缺点是只支持GET请求。

1. CORS

服务器端对于CORS的支持，主要就是通过设置Access-Control-Allow-Origin来进行的。如果浏览器检测到相应的设置，就可以允许Ajax进行跨域的访问。
以上两种方式主要用来跟后台数据交互.

1. 通过修改document.domain来跨子域

将子域和主域的document.domain设为同一个主域.前提条件：这两个域名必须属于同一个基础域名!而且所用的协议，端口都要一致，否则无法利用document.domain进行跨域
主域相同的使用document.domain
此方法可以用来解决跨域cookie本地存储的跨域访问,LocalStorage 和 IndexDB 无法通过这种方法，规避同源政策，而要使用下文介绍的PostMessage API。

1. 使用window.name来进行跨域

window对象有个name属性，该属性有个特征：即在一个窗口(window)的生命周期内,窗口载入的所有的页面都是共享一个window.name的，每个页面对window.name都有读写的权限，window.name是持久存在一个窗口载入过的所有页面中的
以上两种主要用在 使用`iframe来实现页面结构的页面.完成DOM之间的跨域交互.

1. 使用HTML5中新引进的window.postMessage方法来跨域传送数据

该方法允许跨窗口通信，不论这两个窗口是否同源。
方法的第一个参数是具体的信息内容，第二个参数是接收消息的窗口的源（origin），即"协议 + 域名 + 端口"。也可以设为*，表示不限制域名，向所有窗口发送。
postMessage/addEventListener 基本类似于一个全局的事件管理器.可以通过这两个接口来发送/监听 事件,从而完成信息交互.

节流

不管怎么触发，都是按照指定的间隔来执行，同样给个基本版。

请输入代码function throttle(func, wait) {
  var timer
  return function() {
    var context = this
    var args = arguments
    if (!timer) {
      timer = setTimeout(function () {
        timer = null
        func.apply(context, args)
      }, wait)
    }
  }
}

防抖

不管你触发多少次，都等到你最后触发后过一段你指定的时间才触发。按照这个解释，写一个基本版的。

function debounce(func, wait) {
  var timer
  return function() {
    var context = this
    var args = arguments
    clearTimeout(timer)
    timer = setTimeout(function() {
      func.apply(context, args)
    }, wait)
  }
}

HTMl&Css

元素水平居中

• 如果需要居中的元素为常规流中inline元素，为父元素设置text-align: center;即可实现
• 如果需要居中的元素为常规流中block元素，1）为元素设置宽度，2）设置左右margin为auto。3）IE6下需在父元素上设置text-align: center;,再给子元素恢复需要的值
• 如果需要居中的元素为浮动元素，1）为元素设置宽度，2）position: relative;，3）浮动方向偏移量（left或者right）设置为50%，4）浮动方向上的margin设置为元素宽度一半乘以-1
• 如果需要居中的元素为绝对定位元素，1）为元素设置宽度，2）偏移量设置为50%，3）偏移方向外边距设置为元素宽度一半乘以-1
• 如果需要居中的元素为绝对定位元素，1）为元素设置宽度，2）设置左右偏移量都为0,3）设置左右外边距都为auto

元素竖直居中

• 需要居中元素为单行文本，为包含文本的元素设置大于font-size的line-height：

如块级格式化上下文

(block formatting context),
创建规则：

1. 根元素（html）
2. 浮动元素（float不是none）
3. 绝对定位元素（position取值为absolute或fixed）
4. display取值为inline-block,table-cell, table-caption,flex, inline-flex之一的元素
5. overflow不是visible的元素

作用：

1. 可以包含浮动元素
2. 不被浮动元素覆盖
3. 阻止父子元素的margin折叠

CSS元素匹配

　　根据css rules 与dom tree 生成render tree。浏览器先产生一个元素集合，这个集合往往由最后一个部分的索引产生（如果没有索引就是所有元素的集合）。
然后向上匹配，如果不符合上一个部分，就把元素从集合中删除，直到真个选择器都匹配完，还在集合中的元素就匹配这个选择器了。

举个例子，有选择器：
body.ready #wrapper > .lol233
　　先把所有 class 中有 lol233 的元素拿出来组成一个集合，然后上一层，对每一个集合中的元素，如果元素的 parent id 不为 #wrapper 则把元素从集合中删去。 再向上，从这个元素的父元素开始向上找，没有找到一个 tagName 为 body 且 class 中有 ready 的元素，就把原来的元素从集合中删去。至此这个选择器匹配结束，所有还在集合中的元素满足。

为什么从后往前匹配因为效率和文档流的解析方向。

　　1）效率，找元素的父亲和之前的兄弟比遍历所有儿子快而且方便。

　　2）关于文档流的解析方向，是因为现在的 CSS，一个元素只要确定了这个元素在文档流之前出现过的所有元素，就能确定他的匹配情况。应用在即使 html 没有载入完成，浏览器也能根据已经载入的这一部分信息完全确定出现过的元素的属性。

为什么是用集合

主要也还是效率。
基于 CSS Rule 数量远远小于元素数量的假设和索引的运用，遍历每一条 CSS Rule 通过集合筛选，比遍历每一个元素再遍历每一条 Rule 匹配要快得多。

position四个值的区别

先看下各个属性值的定义：

1、static：默认值。没有定位，元素出现在正常的流中（忽略 top, bottom, left, right 或者 z-index 声明）。

2、relative：生成相对定位的元素，通过top,bottom,left,right的设置相对于其正常位置进行定位。可通过z-index进行层次分级。

3、absolute：生成绝对定位的元素，相对于 static 定位以外的第一个父元素进行定位。元素的位置通过 "left", "top", "right" 以及 "bottom" 属性进行规定。可通过z-index进行层次分级。

4、fixed：生成绝对定位的元素，相对于浏览器窗口进行定位。元素的位置通过 "left", "top", "right" 以及 "bottom" 属性进行规定。可通过z-index进行层次分级。

static与fixed的定位方式较好理解，在此不做分析。下面对应用的较多的relative和absolute进行分析：

1、relative。定位为relative的元素脱离正常的文本流中，但其在文本流中的位置依然存在，依然占有原来的位置，后面的元素无法向前补充。

2、absolute。定位为absolute的层脱离正常文本流，但与relative的区别是其在正常流中的位置不在存在，相当于被提升到另一个层面去了，后面的元素会补占它的位置。

relative与absolute的主要区别：

首先，是上面已经提到过的在正常流中的位置存在与否。

其次，relative定位的层总是相对于其最近的父元素，absolute定位的层总是相对于其最近的定义为absolute或 relative的父层，而这个父层并不一定是其直接父层。如果其父层中都未定义absolute或relative，则其将相对body进行定位。

fixed：生成绝对定位的元素，相对于浏览器窗口进行定位。

响应式设计和自适应设计

　　自适应布局（Adaptive Layout）

　　自适应布局（Adaptive）的特点是分别为不同的屏幕分辨率定义布局。布局切换时页面元素发生改变，但在每个布局中，页面元素不随窗口大小的调整发生变化。
就是说你看到的页面，里面元素的位置会变化而大小不会变化；你可以把自适应布局看作是静态布局的一个系列。

　　流式布局（Liquid Layout）

　　流式布局（Liquid）的特点（也叫"Fluid") 是页面元素的宽度按照屏幕进行适配调整，主要的问题是如果屏幕尺度跨度太大，那么在相对其原始设计而言过小或过大的屏幕上不能正常显示。

　　响应式布局（Responsive Layout）

分别为不同的屏幕分辨率定义布局，同时，在每个布局中，应用流式布局的理念，即页面元素宽度随着窗口调整而自动适配。

可以把响应式布局看作是流式布局和自适应布局设计理念的融合。

其它

HTTP状态码及其含义

1XX 提示信息 - 表示请求已被成功接收，继续处理

100 (继续) 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101 (切换协议) 请求者已要求服务器切换协议，服务器已确认并准备切换。

2XX 成功 - 表示请求已被成功接收，理解，接受
200 (成功) 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 (已创建) 请求成功并且服务器创建了新的资源。

3XX 重定向 - 要完成请求必须进行更进一步的处理
304 (未修改) 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。

4XX 客户端错误 - 请求有语法错误或请求无法实现
400 (错误请求) 服务器不理解请求的语法。
401 (未授权) 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 (禁止) 服务器拒绝请求。
404 (未找到) 服务器找不到请求的网页。

5XX 服务器端错误 - 服务器未能实现合法的请求
500 (服务器内部错误) 服务器遇到错误，无法完成请求。
501 (尚未实施) 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 (错误网关) 服务器作为网关或代理，从上游服务器收到无效响应。
503 (服务不可用) 服务器目前无法使用(由于超载或停机维护)。 通常，这只是暂时状态。
504 (网关超时) 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 (HTTP 版本不受支持) 服务器不支持请求中所用的 HTTP 协议版本。

sessionStorage,localStorage,cookie区别

1. 都会在浏览器端保存，有大小限制，同源限制
2. cookie会在请求时发送到服务器，作为会话标识，服务器可修改cookie；web storage不会发送到服务器
3. cookie有path概念，子路径可以访问父路径cookie，父路径不能访问子路径cookie
4. 有效期：cookie在设置的有效期内有效，默认为浏览器关闭；sessionStorage在窗口关闭前有效，localStorage长期有效，直到用户删除
5. 共享：sessionStorage不能共享，localStorage在同源文档之间共享，cookie在同源且符合path规则的文档之间共享
6. localStorage的修改会促发其他文档窗口的update事件
7. cookie有secure属性要求HTTPS传输
8. 浏览器不能保存超过300个cookie，单个服务器不能超过20个，每个cookie不能超过4k。web storage大小支持能达到5M

网站优化

• content方面

  1. 减少HTTP请求：合并文件、CSS精灵、inline Image
  2. 减少DNS查询：DNS查询完成之前浏览器不能从这个主机下载任何任何文件。方法：DNS缓存、将资源分布到恰当数量的主机名，平衡并行下载和DNS查询
  3. 避免重定向：多余的中间访问
  4. 使Ajax可缓存
  5. 非必须组件延迟加载
  6. 未来所需组件预加载
  7. 减少DOM元素数量
  8. 将资源放到不同的域下：浏览器同时从一个域下载资源的数目有限，增加域可以提高并行下载量
  9. 减少iframe数量
  10. 不要404

• Server方面

  1. 使用CDN
  2. 添加Expires或者Cache-Control响应头
  3. 对组件使用Gzip压缩
  4. 配置ETag
  5. Flush Buffer Early
  6. Ajax使用GET进行请求
  7. 避免空src的img标签

• Cookie方面

  1. 减小cookie大小
  2. 引入资源的域名不要包含cookie

• css方面

  1. 将样式表放到页面顶部
  2. 不使用CSS表达式
  3. 使用<link>不使用@import
  4. 不使用IE的Filter

• Javascript方面

  1. 将脚本放到页面底部
  2. 将javascript和css从外部引入
  3. 压缩javascript和css
  4. 删除不需要的脚本
  5. 减少DOM访问
  6. 合理设计事件监听器

• 图片方面

  1. 优化图片：根据实际颜色需要选择色深、压缩
  2. 优化css精灵
  3. 不要在HTML中拉伸图片
  4. 保证favicon.ico小并且可缓存

• 移动方面

  1. 保证组件小于25k
  2. Pack Components into a Multipart Document
• 文件合并， 减少调用其他页面、文件的数量。
• 文件最小化/文件压缩

即将需要传输的内容压缩后传输到客户端再解压，这样在网络上传输的 数据量就会大幅减小。通常在服务器上的Apache、Nginx可以直接开启这个设置，也可以从代码角度直接设置传输文件头，增加gzip的设置，也可以 从 负载均衡设备直接设置。不过需要留意的是，这个设置会略微增加服务器的负担。建议服务器性能不是很好的网站，要慎重考虑。

• 使用 CDN 托管

CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。

• 缓存的使用

Ajax调用都采用缓存调用方式，一般采用附加特征参数方式实现，注意其中的<script src=”xxx.js?{VERHASH}”，{VERHASH}就是特征参数，这个参数不变化就使用缓存文件，如果发生变化则重新下载新文件或更新信息。

• css文件放置在head，js放置在文档尾部
• 在服务器端配置control-cache last-modify-date
• 在服务器配置Entity-Tag if-none-match
• 可再结合H5新特性里的预加载，图片优化方面，可对图片进行压缩，JPG的推荐jpegmin这个软件，png的推荐https://tinypng.com/，前面这两个是压缩后不会失真的，gif的推荐GIF Optimizer，但可能会有毛边。

从浏览器地址栏输入url到显示页面的步骤(以HTTP为例)

1. 在浏览器地址栏输入URL

2. 浏览器查看缓存，如果请求资源在缓存中并且新鲜，跳转到转码步骤

   1. 如果资源未缓存，发起新请求
   2. 如果已缓存，检验是否足够新鲜，足够新鲜直接提供给客户端，否则与服务器进行验证。

   3. 检验新鲜通常有两个HTTP头进行控制Expires和Cache-Control：

      • HTTP1.0提供Expires，值为一个绝对时间表示缓存新鲜日期
      • HTTP1.1增加了Cache-Control: max-age=,值为以秒为单位的最大新鲜时间
3. 浏览器解析URL获取协议，主机，端口，path
4. 浏览器组装一个HTTP（GET）请求报文

5. 浏览器获取主机ip地址，过程如下：

   1. 浏览器缓存
   2. 本机缓存
   3. hosts文件
   4. 路由器缓存
   5. ISP DNS缓存
   6. DNS递归查询（可能存在负载均衡导致每次IP不一样）

6. 打开一个socket与目标IP地址，端口建立TCP链接，三次握手如下：

   1. 客户端发送一个TCP的SYN=1，Seq=X的包到服务器端口
   2. 服务器发回SYN=1， ACK=X+1， Seq=Y的响应包
   3. 客户端发送ACK=Y+1， Seq=Z
7. TCP链接建立后发送HTTP请求
8. 服务器接受请求并解析，将请求转发到服务程序，如虚拟主机使用HTTP Host头部判断请求的服务程序
9. 服务器检查HTTP请求头是否包含缓存验证信息如果验证缓存新鲜，返回304等对应状态码
10. 处理程序读取完整请求并准备HTTP响应，可能需要查询数据库等操作
11. 服务器将响应报文通过TCP连接发送回浏览器

12. 浏览器接收HTTP响应，然后根据情况选择关闭TCP连接或者保留重用，关闭TCP连接的四次握手如下：

    1. 主动方发送Fin=1， Ack=Z， Seq= X报文
    2. 被动方发送ACK=X+1， Seq=Z报文
    3. 被动方发送Fin=1， ACK=X， Seq=Y报文
    4. 主动方发送ACK=Y， Seq=X报文
13. 浏览器检查响应状态吗：是否为1XX，3XX， 4XX， 5XX，这些情况处理与2XX不同
14. 如果资源可缓存，进行缓存
15. 对响应进行解码（例如gzip压缩）
16. 根据资源类型决定如何处理（假设资源为HTML文档）
17. 解析HTML文档，构件DOM树，下载资源，构造CSSOM树，执行js脚本，这些操作没有严格的先后顺序，以下分别解释

18. 构建DOM树：

    1. Tokenizing：根据HTML规范将字符流解析为标记
    2. Lexing：词法分析将标记转换为对象并定义属性和规则
    3. DOM construction：根据HTML标记关系将对象组成DOM树
19. 解析过程中遇到图片、样式表、js文件，启动下载

20. 构建CSSOM树：

    1. Tokenizing：字符流转换为标记流
    2. Node：根据标记创建节点
    3. CSSOM：节点创建CSSOM树

21. 根据DOM树和CSSOM树构建渲染树:

    1. 从DOM树的根节点遍历所有可见节点，不可见节点包括：1）script,meta这样本身不可见的标签。2)被css隐藏的节点，如display: none
    2. 对每一个可见节点，找到恰当的CSSOM规则并应用
    3. 发布可视节点的内容和计算样式

22. js解析如下：

    1. 浏览器创建Document对象并解析HTML，将解析到的元素和文本节点添加到文档中，此时document.readystate为loading
    2. HTML解析器遇到没有async和defer的script时，将他们添加到文档中，然后执行行内或外部脚本。这些脚本会同步执行，并且在脚本下载和执行时解析器会暂停。这样就可以用document.write()把文本插入到输入流中。同步脚本经常简单定义函数和注册事件处理程序，他们可以遍历和操作script和他们之前的文档内容
    3. 当解析器遇到设置了async属性的script时，开始下载脚本并继续解析文档。脚本会在它下载完成后尽快执行，但是解析器不会停下来等它下载。异步脚本禁止使用document.write()，它们可以访问自己script和之前的文档元素
    4. 当文档完成解析，document.readState变成interactive
    5. 所有defer脚本会按照在文档出现的顺序执行，延迟脚本能访问完整文档树，禁止使用document.write()
    6. 浏览器在Document对象上触发DOMContentLoaded事件
    7. 此时文档完全解析完成，浏览器可能还在等待如图片等内容加载，等这些内容完成载入并且所有异步脚本完成载入和执行，document.readState变为complete,window触发load事件
23. 显示页面（HTML解析过程中会逐步显示页面）

什么是web语义化,有什么好处

web语义化是指通过HTML标记表示页面包含的信息，包含了HTML标签的语义化和css命名的语义化。
HTML标签的语义化是指：通过使用包含语义的标签（如h1-h6）恰当地表示文档结构
css命名的语义化是指：为html标签添加有意义的class，id补充未表达的语义，如Microformat通过添加符合规则的class描述信息
为什么需要语义化：

• 去掉样式后页面呈现清晰的结构
• 盲人使用读屏器更好地阅读
• 搜索引擎更好地理解页面，有利于收录
• 便团队项目的可持续运作及维护

Cmd和amd

模块化是软件系统的属性，这个系统被分解为一组高内聚，低耦合的模块。
那么在理想状态下我们只需要完成自己部分的核心业务逻辑代码，其他方面的依赖可以通过直接加载被人已经写好模块进行使用即可。

首先，既然是模块化设计，那么作为一个模块化系统所必须的能力：

1. 定义封装的模块。
2. 定义新模块对其他模块的依赖。
3. 可对其他模块的引入支持。

不同之处
两者的主要区别如下：

1. 定位有差异。

RequireJS 想成为浏览器端的模块加载器，同时也想成为 Rhino / Node 等环境的模块加载器。
Sea.js 则专注于 Web 浏览器端，同时通过 Node 扩展的方式可以很方便跑在 Node 环境中。

1. 遵循的规范不同。
   RequireJS 遵循 AMD（异步模块定义）规范，S
   ea.js 遵循 CMD （通用模块定义）规范。
   规范的不同，导致了两者 API 不同。Sea.js 更贴近 CommonJS Modules/1.1 和 Node Modules 规范。
2. CMD 推崇依赖就近，AMD 推崇依赖前置。看代码：
3. 推广理念有差异。RequireJS 在尝试让第三方类库修改自身来支持 RequireJS，目前只有少数社区采纳。Sea.js 不强推，采用自主封装的方式来“海纳百川”，目前已有较成熟的封装策略。
4. 对开发调试的支持有差异。Sea.js 非常关注代码的开发调试，有 nocache、debug 等用于调试的插件。RequireJS 无这方面的明显支持。
5. 插件机制不同。RequireJS 采取的是在源码中预留接口的形式，插件类型比较单一。Sea.js 采取的是通用事件机制，插件类型更丰富。