pines-cheng / blog Goto Github PK

最近在做React 图片懒加载的，原本以为比较简单，轻轻松松就能搞定，结果碰到了一系列的问题，可谓是一波三折，不过经过这次折腾，对图片懒加载及相关的实现有了更深刻的了解，特此记录一下。

jasonslyvia/react-lazyload

一开始的时候，没打算自己造轮子。直接在网上搜索到了 react-lazyload 的库，用上以后，demo测试也没问题，可是在商品列表却没生效。于是直接去看源码找原因。

图片懒加载一般涉及到的流程为：滚动容器 -> 绑定事件 -> 检测边界 -> 触发事件 -> 图片加载

基本使用

import React from 'react';
import ReactDOM from 'react-dom';
import LazyLoad from 'react-lazyload';
import MyComponent from './MyComponent';

const App = () => {
  return (
    <div className="list">
      <LazyLoad height={200}>
        <img src="tiger.jpg" /> /*
                                  Lazy loading images is supported out of box,
                                  no extra config needed, set `height` for better
                                  experience
                                 */
      </LazyLoad>
      <LazyLoad height={200} once >
                                /* Once this component is loaded, LazyLoad will
                                 not care about it anymore, set this to `true`
                                 if you're concerned about improving performance */
        <MyComponent />
      </LazyLoad>
      <LazyLoad height={200} offset={100}>
                              /* This component will be loaded when it's top
                                 edge is 100px from viewport. It's useful to
                                 make user ignorant about lazy load effect. */
        <MyComponent />
      </LazyLoad>
      <LazyLoad>
        <MyComponent />
      </LazyLoad>
    </div>
  );
};

ReactDOM.render(<App />, document.body);

滚动容器及绑定事件

react-lazyload 有一个props为 overflow，默认为false。

if (this.props.overflow) { // overflow 为true，向上查找滚动容器
      const parent = scrollParent(ReactDom.findDOMNode(this));
      if (parent && typeof parent.getAttribute === 'function') {
        const listenerCount = 1 + (+parent.getAttribute(LISTEN_FLAG));
        if (listenerCount === 1) {
          parent.addEventListener('scroll', finalLazyLoadHandler, passiveEvent);// finalLazyLoadHandler 及passiveEvent 见下面
        }
        parent.setAttribute(LISTEN_FLAG, listenerCount);
      }
    } else if (listeners.length === 0 || needResetFinalLazyLoadHandler) {  // 否则直接绑定window
      const { scroll, resize } = this.props;

      if (scroll) {
        on(window, 'scroll', finalLazyLoadHandler, passiveEvent); 
      }

      if (resize) {
        on(window, 'resize', finalLazyLoadHandler, passiveEvent);
      }
    }

通过源码可以看到，这里当 overflow 为true时，调用 scrollParent 获取滚动容器，否者直接将滚动事件绑定在 window。

scrollParent 代码如下：

/**
 * @fileOverview Find scroll parent
 */

export default (node) => {
  if (!node) {
    return document.documentElement;
  }

  const excludeStaticParent = node.style.position === 'absolute';
  const overflowRegex = /(scroll|auto)/;
  let parent = node;

  while (parent) {
    if (!parent.parentNode) {
      return node.ownerDocument || document.documentElement;
    }

    const style = window.getComputedStyle(parent); //获取节点的所有样式
    const position = style.position;
    const overflow = style.overflow;
    const overflowX = style['overflow-x'];
    const overflowY = style['overflow-y'];

    if (position === 'static' && excludeStaticParent) {
      parent = parent.parentNode;
      continue;
    }

    if (overflowRegex.test(overflow) && overflowRegex.test(overflowX) && overflowRegex.test(overflowY)) {
      return parent;
    }

    parent = parent.parentNode;
  }

  return node.ownerDocument || node.documentElement || document.documentElement;
};

这段代码比较简单，可以看到，scrollParent 默认是迭代向上查找 parentNode 样式的 overflow ，直到找到第一个 overflow 为 auto 或 scroll 的节点。然后返回该节点，作为滚动容器。

看到这里，我就基本知道商品列表懒加载无效的原因了，react-lazyload 仅支持 overflow 的滚动方式，而商品列表由于特殊原因，选用了 transform 的滚动方式。那是否有必要对其进行一下改造呢？接下来，我们继续往下看。

passiveEvent

上面的 passiveEvent 如下，在您的触摸和滚轮事件侦听器上设置 passive 选项可提升滚动性能。

// if they are supported, setup the optional params
// IMPORTANT: FALSE doubles as the default CAPTURE value!
const passiveEvent = passiveEventSupported ? { capture: false, passive: true } : false;

详细可以参考：移动Web滚动性能优化: Passive event listeners

事件回调

这里对 scroll 事件的回调函数 finalLazyLoadHandler 进行了节流或去抖的处理，时间是300毫秒。看起来还不错。

if (!finalLazyLoadHandler) {
      if (this.props.debounce !== undefined) {
        finalLazyLoadHandler = debounce(lazyLoadHandler, typeof this.props.debounce === 'number' ?
                                                         this.props.debounce :
                                                         300);
        delayType = 'debounce';
      } else if (this.props.throttle !== undefined) {
        finalLazyLoadHandler = throttle(lazyLoadHandler, typeof this.props.throttle === 'number' ?
                                                         this.props.throttle :
                                                         300);
        delayType = 'throttle';
      } else {
        finalLazyLoadHandler = lazyLoadHandler;
      }

lazyLoadHandler 如下：

const lazyLoadHandler = () => {
  for (let i = 0; i < listeners.length; ++i) {
    const listener = listeners[i];
    checkVisible(listener); //检测元素是否可见，并设置组件的props：visible
  }
  // Remove `once` component in listeners
  purgePending(); //移除一次性组件的监听
};

这里大家千万不要被函数方法名 checkVisible 给迷惑，这里绝仅仅做了函数名字面意义的事情，而是做了一大堆的事。包括检测是否可见，设置组件 props，更新监听list，还有 component.forceUpdate！也是够了。。。

/**
 * Detect if element is visible in viewport, if so, set `visible` state to true.
 * If `once` prop is provided true, remove component as listener after checkVisible
 *
 * @param  {React} component   React component that respond to scroll and resize
 */
const checkVisible = function checkVisible(component) {
  const node = ReactDom.findDOMNode(component);
  if (!node) {
    return;
  }

  const parent = scrollParent(node);
  const isOverflow = component.props.overflow &&
                     parent !== node.ownerDocument &&
                     parent !== document &&
                     parent !== document.documentElement;
  const visible = isOverflow ?
                  checkOverflowVisible(component, parent) :
                  checkNormalVisible(component);
  if (visible) { //组件是否可见
    // Avoid extra render if previously is visible
    if (!component.visible) {
      if (component.props.once) {
        pending.push(component); //如果只触发一次，则放入pending的列表，然后在purgePending中移除监听
      }

      component.visible = true; //设置组件的props为true
      component.forceUpdate(); //强制更新
    }
  } else if (!(component.props.once && component.visible)) {
    component.visible = false;
    if (component.props.unmountIfInvisible) {
      component.forceUpdate();
    }
  }
};

检测边界

检测组件滚动到可见位置的方法如下：

/**
 * Check if `component` is visible in overflow container `parent`
 * @param  {node} component React component
 * @param  {node} parent    component's scroll parent
 * @return {bool}
 */
const checkOverflowVisible = function checkOverflowVisible(component, parent) {
  const node = ReactDom.findDOMNode(component);

  let parentTop;
  let parentHeight;

  try {
    ({ top: parentTop, height: parentHeight } = parent.getBoundingClientRect());
  } catch (e) {
    ({ top: parentTop, height: parentHeight } = defaultBoundingClientRect);
  }

  const windowInnerHeight = window.innerHeight || document.documentElement.clientHeight;

  // calculate top and height of the intersection of the element's scrollParent and viewport
  const intersectionTop = Math.max(parentTop, 0); // intersection's top relative to viewport
  const intersectionHeight = Math.min(windowInnerHeight, parentTop + parentHeight) - intersectionTop; // height

  // check whether the element is visible in the intersection
  let top;
  let height;

  try {
    ({ top, height } = node.getBoundingClientRect());
  } catch (e) {
    ({ top, height } = defaultBoundingClientRect);
  }

  const offsetTop = top - intersectionTop; // element's top relative to intersection

  const offsets = Array.isArray(component.props.offset) ?
                component.props.offset :
                [component.props.offset, component.props.offset]; // Be compatible with previous API

  return (offsetTop - offsets[0] <= intersectionHeight) &&
         (offsetTop + height + offsets[1] >= 0);
};

看起来好像代码比较多，其实核心方法就一个：getBoundingClientRect() 。Element.getBoundingClientRect() 方法返回元素的大小及其相对于视口的位置。

通过 getBoundingClientRect 方法获取组件的滚动位置（top height等），然后经过一系列计算，就可以判断组件是否已经鼓动到合适的位置上了。

总结

至此，react-lazyload 的代码我们已经大致看完了，总结一下这个库的缺点吧：

• 代码质量一般
• 只能够使用 overflow 滚动
• 直接修改组件的props：component.visible = true; 违背React原则，太暴力
• 使用 component.forceUpdate() ，在滚动列表长，滚动速度快的时候，可能会有性能隐患
• getBoundingClientRect 性能不太好

verlok/lazyload

LazyLoad 是一个快速的，轻量级的，灵活的图片懒加载库，本质是基于 img 标签的 srcset 属性。

简单使用

HTML

<img alt="..." 
     data-src="../img/44721746JJ_15_a.jpg"
     width="220" height="280">

Javascript

var myLazyLoad = new LazyLoad();

滚动容器及回调

入口文件，这里主要是 this._setObserver 方法和 this.update 方法。

 var LazyLoad = function LazyLoad(instanceSettings, elements) {
        this._settings = _extends({}, defaultSettings, instanceSettings);
        this._setObserver();
        this.update(elements);
    };

_setObserver 方法，核心是执行 new IntersectionObserver() 。

IntersectionObserver 是浏览器原生提供的构造函数，接受两个参数：onIntersection 是可见性变化时的回调函数，option是配置对象（该参数可选）。

构造函数的返回值 this._observer 是一个观察器实例。实例的 observer 方法可以指定观察哪个 DOM 节点。

onIntersection 回调用于在图片可见时设置 src 加载图片。

下面可以看到，滚动容器默认为 ducument，否则需手动传一个 DOM 节点 进来。

_setObserver: function _setObserver() {
            var _this = this;

            if (!("IntersectionObserver" in window)) { // IntersectionObserver 方法不存在，直接返回
                return;
            }

            var settings = this._settings;
            var onIntersection = function onIntersection(entries) {
                entries.forEach(function (entry) {
                    if (entry.intersectionRatio > 0) { // intersectionRatio：目标元素的可见比例，即intersectionRect占boundingClientRect的比例，完全可见时为1，完全不可见时小于等于0
                        var element = entry.target;
                        revealElement(element, settings); // 设置img的src
                        _this._observer.unobserve(element); // 停止观察
                    }
                });
                _this._elements = purgeElements(_this._elements);
            };
            this._observer = new IntersectionObserver(onIntersection, { // 获取观察器实例IntersectionObserver对象
                root: settings.container === document ? null : settings.container, // 滚动容器默认为document
                rootMargin: settings.threshold + "px"
            });
        },

其中 revealElement 方法如下：

    var revealElement = function revealElement(element, settings) {
        if (["IMG", "IFRAME"].indexOf(element.tagName) > -1) {
            addOneShotListeners(element, settings);
            addClass(element, settings.class_loading);
        }
        setSources(element, settings); // 设置img的src
        setData(element, "was-processed", true);
        callCallback(settings.callback_set, element);
    };

绑定事件

update 方法，获取需要懒加载的 img 元素，指定观察节点。

        update: function update(elements) {
            var _this2 = this;

            var settings = this._settings;
            var nodeSet = elements || settings.container.querySelectorAll(settings.elements_selector); // 获取所有需要懒加载的的img元素

            this._elements = purgeElements(Array.prototype.slice.call(nodeSet)); // nodeset to array for IE compatibility
            if (this._observer) {
                this._elements.forEach(function (element) {
                    _this2._observer.observe(element); // 开始观察
                });
                return;
            }
            // Fallback: load all elements at once
            this._elements.forEach(function (element) {
                revealElement(element, settings);
            });
            this._elements = purgeElements(this._elements);
        },

检测可见

检测可见这里使用的是 IntersectionObserver 。

传统的实现方法是，监听到scroll事件后，调用目标元素（绿色方块）的 getBoundingClientRect() 方法，得到它对应于视口左上角的坐标，再判断是否在视口之内。这种方法的缺点是，由于scroll事件密集发生，计算量很大，容易造成性能问题。

目前有一个新的 IntersectionObserver API ，可以自动"观察"元素是否可见，Chrome 51+ 已经支持。由于可见（visible）的本质是，目标元素与视口产生一个交叉区，所以这个 API 叫做"交叉观察器"。

详细可见文章下面的参考。

触发事件

下面的代码很好懂，无非就是将 data-src 的值赋给 src 而已，这样，图片就开始加载了。

    var setSourcesForPicture = function setSourcesForPicture(element, settings) {
        var dataSrcSet = settings.data_srcset;

        var parent = element.parentNode;
        if (parent.tagName !== "PICTURE") {
            return;
        }
        for (var i = 0, pictureChild; pictureChild = parent.children[i]; i += 1) {
            if (pictureChild.tagName === "SOURCE") {
                var sourceSrcset = getData(pictureChild, dataSrcSet);
                if (sourceSrcset) {
                    pictureChild.setAttribute("srcset", sourceSrcset);
                }
            }
        }
    };

总结

改懒加载库一共只有两百多行代码，且没有任何依赖。使用 IntersectionObserver 配合 data-src 也极大的提升了性能。不过缺点如下：

• IntersectionObserver 兼容性不好，不支持 IntersectionObserver 的浏览器，直接一次性显示图片。
• 需要手动传容器组件，不能自己向上查找。

写在最后

作为一个不轻易造轮子的程序员，最后我还是选用了 verlok/lazyload ，不过添加 IntersectionObserver 的 polyfill。 顺便提一下，IntersectionObserver 的polyfill 也是基于 getBoundingClientRect 实现的。

然后将第一个库的 scrollParent 方法移植了过来，自动查找父节点的滚动容器，完美！

参考

• IntersectionObserver API 使用教程
• w3c/IntersectionObserver
• 基于IntersectionObserver的曝光统计测试
• 你可能不知道的前端知识点之：IntersectionObserver

与桌面应用不同，网络应用不需要单独的安装过程：只需输入网址，便可启动和运行 - 这是网络的一个关键特色。不过，要做到这一步，我们通常需要获取几十个（有时甚至是几百个）不同的资源，所有这些资源加起来的数据量高达几兆字节，并且必须在短短几百毫秒内汇聚起来，以实现我们想要达到的即时网络体验。

在满足上述要求的前提下实现即时网络体验绝非易事，优化内容效率至关重要的原因就在于此：避免不必要的下载、通过各种压缩技术优化每个资源的传送编码以及尽可能利用缓存来避免多余的下载。

文本编码和大小优化

除了避免不必要的资源下载，在提高网页加载速度上您可以采取的最有效措施就是，通过优化和压缩其余资源来最大限度减小总下载大小。

优化资源

压缩冗余或不必要数据的最佳方法是将其全部消除。我们不能只是删除任意数据，但在某些环境中，我们可能对数据格式及其属性有内容特定了解，往往可以在不影响其实际含义的情况下显著减小负载的大小。

通用压缩程序（例如设计用于压缩任意文本的压缩程序）在压缩以上网页时可能同样可以取得相当不错的效果，但永远别指望它能去除注释、折叠 CSS 规则或者进行大量的其他内容特定优化。正因如此，预处理/源码压缩/环境感知优化才会成为功能如此强大的工具。

注：举个有说服力的例子，JQuery 内容库未压缩开发版本的大小现已接近大约 300KB。而压缩（移除注解等内容）后同一内容库的大小仅为原来的大约 1/3：大约 100KB。

Gzip

Gzip 是一种可以作用于任何字节流的通用压缩程序。它会在后台记忆一些之前看到的内容，并尝试以高效方式查找并替换重复的数据片段。（欲知详情，请参阅浅显易懂的 GZIP 低阶说明。）GZIP 对基于文本的内容的压缩效果最好，在压缩较大文件时往往可实现高达 70-90% 的压缩率，而如果对已经通过替代算法压缩过的资产（例如，大多数图片格式）运行 GZIP，则效果甚微，甚至毫无效果。

上表显示了 GZIP 压缩对几种最流行的 JavaScript 内容库和 CSS 框架可实现的压缩率。压缩率范围为 60% 至 88%，将文件压缩源码后（产生文件名中包含“.min”的文件），再使用 GZIP 进行压缩，可进一步提高压缩率。

HTML5 Boilerplate 项目包含所有最流行服务器的 配置文件样例，其中为每个配置标志和设置都提供了详细的注解。要为您的服务器确定最佳配置，请执行以下操作： 在列表中找到您喜爱的服务器。 查找 GZIP 部分。 * 确认您的服务器配置了推荐的设置。

可通过以下这种快速而又简单的方法了解 GZIP 的实用效果：打开 Chrome DevTools，然后检查“Network”面板中的“Size / Content”列：“Size”表示资产的传送大小，“Content”表示资产的未压缩大小。对于上例中的 HTML 资产，GZIP 在传送时节省了 98.8KB。

最后，尽管大多数服务器会在向用户提供这些资产时自动对其进行压缩，但某些 CDN 需要特别注意和手动操作，以确保 GZIP 资产得到提供。务请审核您的网站并确保资产确实 得到压缩。

Tips:

• GZIP 对基于文本的资产的压缩效果最好：CSS、JavaScript 和 HTML。
• 所有现代浏览器都支持 GZIP 压缩，并且会自动请求该压缩。
• 您的服务器必须配置为启用 GZIP 压缩。
• 某些 CDN 需要特别注意以确保 GZIP 已启用。

图像优化

图像优化既是一门艺术，也是一门科学：说它是一门艺术，是因为单个图像的压缩并不存在明确的最佳方案，说它是一门科学，则是因为有许多发展成熟的方法和算法都能够显著缩减图像的大小。找到图像的最佳设置需要在许多方面进行认真分析：格式能力、编码数据的内容、质量、像素尺寸等。

消除和替换图像

• 消除多余的图像资源
• 尽可能利用 CSS3 效果
• 使用网页字体取代在图像中进行文本编码

首先要问问自己，要实现所需的效果，是否确实需要图像。好的设计应该简单，而且始终可以提供最佳性能。如果您可以消除图像资源（与 HTML、CSS、JavaScript 以及网页上的其他资产相比，需要的字节数通常更大），这种优化策略就始终是最佳策略。不过，如果使用得当，图像传达的信息也可能胜过千言万语，因此需要由您来找到平衡点。

接下来您应该考虑是否存在某种替代技术，能够以更高效的方式实现所需的效果：

• CSS 效果（渐变、阴影等）和 CSS 动画可用于产生与分辨率无关的资产，这些资产在任何分辨率和缩放级别下始终都能清晰地显示，并且需要的字节数往往只是图片文件的几分之一。
• 网页字体可以在保留选择文本、搜索文本和调整文本大小能力的同时使用漂亮的字体，大大提高了易用性。

高分辨率屏幕

高 DPI (HiDPI) 屏幕可以产生绚丽的效果，但也有一个明显的折衷之处：图像资产需要更多的细节，才能对更高的设备像素数加以利用。好在矢量图像最适用于这项任务，因为它们在任何分辨率下都能渲染出清晰的效果。为了渲染出更丰富的细节，我们可能会招致更大的处理开销，但基础资产是相同的，并且与分辨率无关。

另一方面，因为光栅图像是以像素为单位编码图像数据，所以面临的挑战要大得多。因此，像素数越大，光栅图像的文件大小就越大。

如果我们将物理屏幕的分辨率加倍，总像素数将增加四倍：双倍的水平像素数乘以双倍的垂直像素数。因此，如果是“2x”的屏幕，所需的像素数不只是加倍，而是增加到原来的四倍！

那么，这有何实际意义呢？我们可以通过高分辨率屏幕提供绚丽的图像，这可以作为产品的一大特色。不过，高分辨率屏幕也需要高分辨率图像：尽可能优先使用矢量图像，因为它们与分辨率无关，并且能够始终提供清晰的效果，而如果需要使用光栅图像，请借助 srcset 和 picture 提供并优化每个图像的多个变体。

矢量图像

矢量图像最适用于包含几何形状的图像，矢量图像与缩放和分辨率无关。

所有现代浏览器都支持可缩放矢量图形 (SVG)，这种基于 XML 的图片格式适用于二维图形：我们可以将 SVG 标记直接嵌入网页，也可将其作为外部资源嵌入网页。然后，可通过大多数基于矢量的绘图软件创建一个 SVG 文件，或直接在您喜欢的文本编辑器中手动创建。

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 17.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<svg version="1.2" baseProfile="tiny" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
   x="0px" y="0px" viewBox="0 0 612 792" xml:space="preserve">
<g id="XMLID_1_">
  <g>
    <circle fill="red" stroke="black" stroke-width="2" stroke-miterlimit="10" cx="50" cy="50" r="40"/>
  </g>
</g>
</svg>

上例渲染的是一个具有黑色轮廓和红色背景的简单圆形，并且是从 Adobe Illustrator 导出。您可以看出，它包含大量元数据，例如图层信息、注解和 XML 命名空间，而在浏览器中渲染资产时通常不需要这些数据。因此，通过 svgo 之类的工具将您的 SVG 文件缩小绝对有益。

svgo 能够将上面这个由 Illustrator 生成的 SVG 文件的大小减少 58%，使其从 470 个字节缩小到 199 个字节。而且，由于 SVG 是一种基于 XML 的格式，因此我们还可以应用 GZIP 压缩来减小其传送大小 - 确保将您的服务器配置为对 SVG 资产进行压缩！

光栅图像

光栅图像就是一个 2 维“像素”栅格，例如，100x100 像素的图像是 10,000 个像素的序列，而每个像素又存储有“RGBA”值：(R) 红色通道、(G) 绿色通道、(B) 蓝色通道和 (A) alpha（透明度）通道。

在内部，浏览器为每个通道分配 256 个值（色阶），也就是每个通道 8 位 (2 ^ 8 = 256)，每个像素 4 个字节（4 个通道 x 8 位 = 32 位 = 4 个字节）。因此，如果我们知道栅格尺寸，就能轻易计算出文件大小：

• 100 x 100 像素的图像由 10,000 个像素组成
• 10,000 个像素 x 4 个字节 = 40,000 个字节
• 40,000 个字节/1024 = 39 KB

100x100 像素图像的文件大小只有 39KB，可能似乎不是什么大问题，但对于更大的图像，文件大小会迅速暴增，并使图像资产的下载既速度缓慢又开销巨大。幸运的是，目前为止我们所描述是“未压缩”图片格式。我们可以采取什么措施来减小图片文件的大小呢？

一个简单的策略是将图像的“位深”从每个通道 8 位减少为更小的调色板：每个通道 8 位为每个通道提供 256 个值，共计提供 16777216 (2563) 种颜色。如果我们将调色板减少为 256 色，会出现什么情况？那样的话，RGB 通道一共只需要 8 位，每个像素立即可以节约两个字节，与原来每个像素 4 个字节的格式相比，通过压缩节约了 50% 的字节！

注：从左至右 (PNG)：32 位（16M 色）、7 位（128 色）、5 位（32 色）。包含渐变色过渡的复杂场景（渐变、天空等）需要较大的调色板，以避免在 5 位资产中产生马赛克天空之类的视觉伪影。另一方面，如果图像只使用几种颜色，较大的调色板只会浪费宝贵的位数！

接下来，在优化了各个像素中存储的数据之后，我们可以多动动脑筋，看看能不能对相邻像素也做做优化：其实，许多图像（尤其是照片）的大量相邻像素都具有相似的颜色 - 例如，天空、重复的纹理等。压缩程序可以利用这些信息采用“增量编码”，在这种编码方式下，并不为每个像素单独存储值，而是存储相邻像素之间的差异：如果相邻像素相同，则增量为“零”，我们只需存储一位！但是这显然还不够...

人眼对不同颜色的敏感度是不同的：为此，我们可以通过减小或增大这些颜色的调色板来优化颜色编码。“相邻”像素构成二维栅格，这意味着每个像素都有多个相邻像素：我们可以利用这一点进一步改进增量编码。我们不再只是关注每个像素直接相邻的像素，而是着眼于更大块的相邻像素，并使用不同设置对不同的像素块进行编码。当然还不止这些...

您可以看出，图像优化很快就会复杂（或者有趣起来，全凭您怎么看了），这也是学术和商业研究都很活跃的一个领域。由于图像占据了大量字节，因此开发更好的图像压缩方法具有极大价值！如果您很想了解更多信息，请访问 Wikipedia 网页，或查看 WebP 压缩方法白皮书中 提供的实例。

无损图像压缩与有损图像压缩

人眼对不同颜色的敏感度不同，这意味着我们可以使用较少的位数来编码某些颜色。因此，典型的图像优化过程由两个高级步骤组成：

• 使用“有损”过滤器处理图像，去除某些像素数据
• 使用“无损”过滤器处理图像，对像素数据进行压缩

第一步是可选步骤，具体算法将取决于特定的图片格式，但一定要了解，任何图像都可通过有损压缩步骤来减小其大小。 实际上，不同图片格式（例如 GIF、PNG、JPEG 以及其他格式）之间的差异在于它们在执行有损和无损压缩步骤时所使用（或省略）特定算法的组合。

选择正确的图片格式

• 首先选择正确的通用格式：GIF、PNG、JPEG
• 通过试验选出每一种格式的最佳设置：质量、调色板大小等
• 考虑为现代化客户端添加 WebP 和 JPEG XR 资产

除了不同的有损和无损压缩算法外，不同的图片格式还支持不同的功能，例如动画和透明度 (alpha) 通道。因此，需要将所需视觉效果与功能要求相结合来为特定图像选择“正确的格式”。

获得普遍支持的图片格式有三种：GIF、PNG 和 JPEG。除了这些格式外，一些浏览器还支持较新的格式（例如 WebP 和 JPEG XR），它们的总体压缩率更高，提供的功能也更多。那么，您应该使用哪一种格式呢？

• 您是否需要动画？如果需要，GIF 是唯一的通用选择。
  • GIF 将调色板限制为最多 256 色，这对大多数图像而言都不是好的选择。况且，对于调色板较小的图像，PNG-8 的压缩效果更佳。因此，只有需要动画时，GIF 才是正确的选择。
• 您是否需要使用最高分辨率保留精细的细节？请使用 PNG。
  • 除了选择调色板的大小外，PNG 不采用任何有损压缩算法。因此，它能生成最高质量的图像，但代价是文件大小要比其他格式大得多。请谨慎使用。
  • 如果图像资产包含由几何形状组成的图像，请务必考虑将其转换成矢量 (SVG) 格式！
  • 如果图像资产包含文本，请停下来再做考虑。图像中的文本无法选择、搜索或“缩放”。
  • 如果您需要表现一种自定义外观（出于品牌推广或其他原因），请改用网页字体。
• 您是否要优化照片、屏幕截图或类似的图像资产？请使用 JPEG。
  • JPEG 组合使用有损和无损优化来减小图像资产的文件大小。请尝试几种 JPEG 质量级别，为您的资产找到最佳的质量与文件大小平衡点。

最后，为每一项资产确定了最佳图片格式及其设置之后，请考虑增加一个以 WebP 和 JPEG XR 格式编码的变体。这两种格式均为新格式，并且遗憾的是，它们没有（尚未）得到所有浏览器的普遍支持，但尽管如此，它们仍可为较新的客户端显著降低文件大小，例如，平均来说，与可比的 JPEG 图像相比，WebP 可将文件大小减小 30%。

由于 WebP 和 JPEG XR 均未得到普遍支持，您需要向应用或服务器添加额外的逻辑来提供相应的资源：

• 有些 CDN 将图像优化作为一项服务提供，包括提供 JPEG XR 和 WebP。
• 有些开源工具（例如 PageSpeed for Apache 或 PageSpeed for Nginx）自动优化、转换和提供相应资产。
• 您可以添加额外的应用逻辑来检测客户端，检查客户端支持的格式，并提供最合适的图片格式。

最后请注意，如果您使用 Webview 在本机应用中渲染内容，就可以完全控制客户端，并可独占使用 WebP！Facebook、Google+ 以及许多其他应用都使用 WebP 来提供其应用内的所有图像 - 实现的文件大小缩减定然物有所值。如需了解有关 WebP 的更多信息，请观看 Google I/O 2013 上的演讲 WebP：部署更快速、更小并且更绚丽的图像。

提供缩放的图像

图像优化可归结为两个标准：优化编码每个图像像素所使用的字节数，和优化总像素数：图像的文件大小就是总像素数与编码每个像素所使用字节数的乘积。不多不少。

图像优化检查清单

图像优化既是一门艺术，也是一门科学：说它是一门艺术，是因为单个图像的压缩并不存在明确的最佳方案，说它是一门科学，则是因为有一些发展成熟的方法和算法有助于显著缩减图像的大小。

在您努力优化图像时，要记住以下这些技巧和方法：

• 首选矢量格式：矢量图像与分辨率和缩放无关，这使它们成为多设备和高分辨率情况的完美选择。
• 缩小和压缩 SVG 资产： 大多数绘图应用程序生成的 XML 标记往往包含可以移除的多余元数据；确保您的服务器配置为对 SVG 资产采用 GZIP 压缩。
• 挑选最佳光栅图片格式：确定您的功能要求并选择适合每个特定资产的格式。
• 通过试验为光栅格式找到最佳质量设置：不要害怕调低“质量”设置，调低后的效果通常很不错，并且字节数的缩减很显著。
• 移除多余的图像元数据：许多光栅图像都包含多余的资产元数据：地理信息、相机信息等。请使用合适的工具删除这些数据。
• 提供缩放的图像：调整服务器上的图像尺寸，并确保图像的“显示”尺寸尽可能接近其“自然”尺寸。尤其要密切注意较大的图像，因为在调整尺寸时，它们占用的开销最大！
• 自动化、自动化、自动化：投资购置自动化工具和基础设施，这样可以确保您的所有图像资产始终得到优化。

网页字体优化

网页字体详解

Unicode 字体可能包含数千种字形。字体格式有四种：WOFF2、WOFF、EOT 和 TTF。

目前网络上使用的字体容器格式有四种：EOT、TTF、WOFF 和 WOFF2。遗憾的是，尽管选择范围很广，但仍然缺少在所有新旧浏览器上都能使用的单一通用格式：EOT 只有 IE 支持，TTF 获得了部分 IE 支持，WOFF 获得了最广泛的支持，但在某些较旧的浏览器上不受支持，而 WOFF 2.0 支持对许多浏览器来说尚未实现。

我们需要提供多种格式才能实现一致的体验：

• 将 WOFF 2.0 变体提供给支持它的浏览器。
• 将 WOFF 变体提供给大多数浏览器。
• 将 TTF 变体提供给旧 Android（4.4 版以下）浏览器。
• 将 EOT 变体提供给旧 IE（IE9 版以下）浏览器。

注：考虑使用 Zopfli 压缩处理 EOT、TTF 和 WOFF 格式。Zopfli 是一种兼容 zlib 的压缩工具，提供的文件大小压缩率比 gzip 高大约 5%。

网页字体和关键渲染路径

字体延迟加载带有一个可能会延迟文本渲染的重要隐藏影响：浏览器必须构建渲染树（它依赖 DOM 和 CSSOM 树），然后才能知道需要使用哪些字体资源来渲染文本。因此，字体请求的处理将远远滞后于其他关键资源请求的处理，并且在获取资源之前，可能会阻止浏览器渲染文本。

1. 浏览器请求 HTML 文档。
2. 浏览器开始解析 HTML 响应和构建 DOM。
3. 浏览器发现 CSS、JS 以及其他资源并分派请求。
4. 浏览器在收到所有 CSS 内容后构建 CSSOM，然后将其与 DOM 树合并以构建渲染树。
   • 在渲染树指示需要哪些字体变体在网页上渲染指定文本后，将分派字体请求。
5. 浏览器执行布局并将内容绘制到屏幕上。
   • 如果字体尚不可用，浏览器可能不会渲染任何文本像素。
   • 字体可用之后，浏览器将绘制文本像素。

网页内容的首次绘制（可在渲染树构建后不久完成）与字体资源请求之间的“竞赛”产生了“空白文本问题”，出现该问题时，浏览器会在渲染网页布局时遗漏所有文本。

不同浏览器之间实际行为有所差异：

• Safari 会在字体下载完成之前延迟文本渲染。
• Chrome 和 Firefox 会将字体渲染暂停最多 3 秒，之后他们会使用一种后备字体。并且字体下载完成后，他们会使用下载的字体重新渲染一次文本。
• IE 会在请求字体尚不可用时立即使用后备字体进行渲染，然后在字体下载完成后进行重新渲染。

通过 Font Loading API 优化字体渲染

Font Loading API 提供了一种脚本编程接口来定义和操纵 CSS 字体，追踪其下载进度，以及替换其默认延迟下载行为。例如，如果您确定将需要特定字体变体，您可以定义它并指示浏览器启动对字体资源的立即获取：

var font = new FontFace("Awesome Font", "url(/fonts/awesome.woff2)", {
  style: 'normal', unicodeRange:'U+000-5FF', weight:'400'
});

font.load(); // don't wait for the render tree, initiate an immediate fetch!

font.ready().then(function() {
  // apply the font (which may re-render text and cause a page reflow)
  // after the font has finished downloading
  document.fonts.add(font);
  document.body.style.fontFamily = "Awesome Font, serif";

  // OR... by default the content is hidden, 
  // and it's rendered after the font is available
  var content = document.getElementById("content");
  content.style.visibility = "visible";

  // OR... apply your own render strategy here... 
});

并且，由于您可以检查字体状态（通过 check() 方法）并追踪其下载进度，因此您还可以为在网页上渲染文本定义一种自定义策略：

• 您可以在获得字体前暂停所有文本渲染。
• 您可以为每种字体实现自定义超时。
• 您可以利用后备字体解除渲染阻止，并在获得字体后注入使用所需字体的新样式。

最重要的是，您还可以混用和匹配上述策略来适应网页上的不同内容。例如，在获得字体前延迟某些部分的文本渲染；使用后备字体，然后在字体下载完成后进行重新渲染；指定不同的超时，等等。

注：在某些浏览器上，Font Loading API 仍处于开发阶段。可以考虑使用 FontLoader polyfill 或 webfontloader 内容库来提供类似功能，尽管附加的 JavaScript 依赖关系会产生开销。

通过内联优化字体渲染

使用 Font Loading API 消除“空白文本问题”的简单替代策略是将字体内容内联到 CSS 样式表内：

• 浏览器会使用高优先级自动下载具有匹配媒体查询的 CSS 样式表，因为需要使用它们来构建 CSSOM。
• 将字体数据内联到 CSS 样式表中会强制浏览器使用高优先级下载字体，而不等待渲染树。即它起到的是手动替换默认延迟加载行为的作用。

内联策略不那么灵活，不允许您为不同的内容定义自定义超时或渲染策略，但不失为是一种适用于所有浏览器并且简单而又可靠的解决方案。为获得最佳效果，请将内联字体分成独立的样式表，并为它们提供较长的 max-age。这样一来，在您更新 CSS 时，就不会强制访问者重新下载字体。

注：有选择地使用内联。回想一下，@font-face 使用延迟加载行为来避免下载多余的字体变体和子集的原因。此外，通过主动式内联增加 CSS 的大小将对您的关键渲染路径产生不良影响。浏览器必须下载所有 CSS，然后才能构造 CSSOM，构建渲染树，以及将页面内容渲染到屏幕上。

通过HTTP缓存优化字体重复使用

字体资源通常是不会频繁更新的静态资源。因此，它们非常适合较长的 max-age 到期 - 确保您为所有字体资源同时指定了条件 ETag 标头和最佳 Cache-Control 策略。

您无需在 localStorage 中或通过其他机制存储字体，其中的每一种机制都有各自的性能缺陷。 浏览器的 HTTP 缓存与 Font Loading API 或 webfontloader 内容库相结合，实现了最佳并且最可靠的机制来向浏览器提供字体资源。

优化检查清单

与普遍的观点相反，使用网页字体不需要延迟网页渲染，也不会对其他性能指标产生不良影响。在充分优化的情况下使用字体可大幅提升总体用户体验：出色的品牌推广，改进的可读性、易用性和可搜索性，并一直提供可扩展的多分辨率解决方案，能够出色地适应各种屏幕格式和分辨率。不要害怕使用网页字体！

不过，直接实现可能招致下载内容庞大和不必要的延迟。您需要通过对字体资产本身及其在网页上的获取和使用方式进行优化来为浏览器提供协助的环节。

• 审核并监控您的字体使用：不要在网页上使用过多字体，并且对于每一种字体，最大限度减少使用的变体数量。这将有助于为您的用户带来更加一致且更加快速的体验。
• 对您的字体资源进行子集内嵌：许多字体都可进行子集内嵌，或者拆分成多个 unicode-range 以仅提供特定网页需要的字形。这样就减小了文件大小，并提高了资源的下载速度。不过，在定义子集时要注意针对字体重复使用进行优化。例如，您一定不希望在每个网页上都下载不同但重叠的字符集。最好根据文字系统（例如拉丁文、西里尔文等）进行子集内嵌。
• 向每个浏览器提供优化过的字体格式：每一种字体都应以 WOFF2、WOFF、EOT 和 TTF 格式提供。务必对 EOT 和 TTF 格式应用 GZIP 压缩，因为默认情况下不会对它们进行压缩。
• 指定重新验证和最佳缓存策略：字体是不经常更新的静态资源。确保您的服务器提供长期的 max-age 时间戳和重新验证令牌，以实现不同网页之间高效的字体重复使用。
• 使用 Font Loading API 来优化关键渲染路径：默认延迟加载行为可能导致文本渲染延迟。您可以通过 Font Loading API 为特定字体替换这一行为，以及为网页上的不同内容指定自定义渲染和超时策略。对于不支持该 API 的较旧浏览器，您可以使用网页字体加载程序 JavaScript 内容库或使用 CSS 内联策略。

参考

• 从案例分析如何优化前端性能
• optimizing-content-efficiency

方法一：通过正则表达式进行替换

//HTML标签转义（< -> &lt;）
function html2Escape(sHtml) {
 return sHtml.replace(/[<>&"]/g,function(c){
   return {'<':'&lt;','>':'&gt;','&':'&amp;','"':'&quot;'}[c];
 });
}

方法二：通过 innerText 与 innerHTML 配合实现转换

这个实现原理是：innerText(textContent) 会获取纯文本内容，忽略 html 节点标签，而 innerHTML 会显示标签内容。

HTML 标签的转义方法

我们先将需转义的内容赋值给 innerText(textContent)，再获取它的 innerHTML 属性，这时获取到的就是转义后文本内容。

//HTML标签转义（< -> &lt;）
function html2Escape(sHtml) {
  var temp = document.createElement("div");
  (temp.textContent != null) ? (temp.textContent = sHtml) : (temp.innerText = sHtml);
  var output = temp.innerHTML;
  temp = null;
  return output;
}

HTML 标签的反转义方法

反转义的方法为先将转义文本赋值给 innerHTML，然后通过 innerText(textContent) 获取转义前的文本内容。

//HTML标签反转义（&lt; -> <）
function escape2Html(str) {
  var temp = document.createElement("div");
  temp.innerHTML = str;
  var output = temp.innerText || temp.textContent;
  temp = null;
  return output;
}

渲染一个网页，浏览器需要完成的步骤：

1. 处理 HTML 标记并构建 DOM 树。
2. 处理 CSS 标记并构建 CSSOM 树。
3. 将 DOM 与 CSSOM 合并成一个渲染树。
4. 根据渲染树来布局（Layout），以计算每个节点的几何信息。
5. 将各个节点绘制到屏幕上。

我们的演示网页看起来可能很简单，实际上却需要完成相当多的工作。如果 DOM 或 CSSOM 被修改，您只能再执行一遍以上所有步骤，以确定哪些像素需要在屏幕上进行重新渲染。

构建对象模型

浏览器渲染页面前需要先构建 DOM 和 CSSOM 树。因此，我们需要确保尽快将 HTML 和 CSS 都提供给浏览器。

TL;DR

• 字节 → 字符 → 令牌 → 节点 → 对象模型。
• HTML 标记转换成文档对象模型 (DOM)；CSS 标记转换成 CSS 对象模型 (CSSOM)。
• DOM 和 CSSOM 是独立的数据结构。
• Chrome DevTools Timeline 让我们可以捕获和检查 DOM 和 CSSOM 的构建和处理开销。

文档对象模型 (DOM)

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg"></div>
  </body>
</html>

让我们从可能的最简单情况入手：一个包含一些文本和一幅图片的普通 HTML 页面。浏览器如何处理此页面？

1. 转换： 浏览器从磁盘或网络读取 HTML 的原始字节，并根据文件的指定编码（例如 UTF-8）将它们转换成各个字符。
2. 令牌化： 浏览器将字符串转换成 W3C HTML5 标准规定的各种令牌，例如，“”、“”，以及其他尖括号内的字符串。每个令牌都具有特殊含义和一组规则。
3. 词法分析： 发出的令牌转换成定义其属性和规则的“对象”。
4. DOM 构建： 最后，由于 HTML 标记定义不同标记之间的关系（一些标记包含在其他标记内），创建的对象链接在一个树数据结构内，此结构也会捕获原始标记中定义的父项-子项关系：HTML 对象是 body 对象的父项，body 是 paragraph 对象的父项，依此类推。

整个流程的最终输出是我们这个简单页面的文档对象模型 (DOM)，浏览器对页面进行的所有进一步处理都会用到它。

浏览器每次处理 HTML 标记时，都会完成以上所有步骤：将字节转换成字符，确定令牌，将令牌转换成节点，然后构建 DOM 树。这整个流程可能需要一些时间才能完成，有大量 HTML 需要处理时更是如此。

需要快速温习相关内容，请查看 Chrome DevTools 文档；如果您未接触过 DevTools，建议学习 Codeschool Discover DevTools 课程。

如果您打开 Chrome DevTools 并在页面加载时记录时间线，就可以看到执行该步骤实际花费的时间。在上例中，将一堆 HTML 字节转换成 DOM 树大约需要 5 毫秒。对于较大的页面，这一过程需要的时间可能会显著增加。创建流畅动画时，如果浏览器需要处理大量 HTML，这很容易成为瓶颈。

DOM 树捕获文档标记的属性和关系，但并未告诉我们元素在渲染后呈现的外观。那是 CSSOM 的责任。

CSS 对象模型 (CSSOM)

在浏览器构建我们这个简单页面的 DOM 时，在文档的 head 部分遇到了一个 link 标记，该标记引用一个外部 CSS 样式表：style.css。由于预见到需要利用该资源来渲染页面，它会立即发出对该资源的请求，并返回以下内容：

body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }

与处理 HTML 时一样，我们需要将收到的 CSS 规则转换成某种浏览器能够理解和处理的东西。因此，我们会重复 HTML 过程，不过是为 CSS 而不是 HTML：

CSS 字节转换成字符，接着转换成令牌和节点，最后链接到一个称为“CSS 对象模型”(CSSOM) 的树结构内：

CSSOM 为何具有树结构？为页面上的任何对象计算最后一组样式时，浏览器都会先从适用于该节点的最通用规则开始（例如，如果该节点是 body 元素的子项，则应用所有 body 样式），然后通过应用更具体的规则（即规则“向下级联”）以递归方式优化计算的样式。

以上面的 CSSOM 树为例进行更具体的阐述。span 标记内包含的任何置于 body 元素内的文本都将具有 16 像素字号，并且颜色为红色 — font-size 指令从 body 向下级联至 span。不过，如果某个 span 标记是某个段落 (p) 标记的子项，则其内容将不会显示。

还请注意，以上树并非完整的 CSSOM 树，它只显示了我们决定在样式表中替换的样式。每个浏览器都提供一组默认样式（也称为“User Agent 样式”），即我们不提供任何自定义样式时所看到的样式，我们的样式只是替换这些默认样式（例如默认 IE 样式）。

要了解 CSS 处理所需的时间，您可以在 DevTools 中记录时间线并寻找“Recalculate Style”事件：与 DOM 解析不同，该时间线不显示单独的“Parse CSS”条目，而是在这一个事件下一同捕获解析和 CSSOM 树构建，以及计算的样式的递归计算。

我们的小样式表需要大约 0.6 毫秒的处理时间，影响页面上的 8 个元素 — 虽然不多，但同样会产生开销。不过，这 8 个元素从何而来呢？CSSOM 和 DOM 是独立的数据结构！都是独立的对象，分别网罗文档不同方面的信息：一个描述内容，另一个则是描述需要对文档应用的样式规则。结果证明，浏览器隐藏了一个重要步骤。接下来，让我们谈一谈将 DOM 与 CSSOM 关联在一起的渲染树。

渲染树（Render Tree）构建、布局(Layout)及绘制(Paint)

CSSOM 树和 DOM 树合并成渲染树，然后用于计算每个可见元素的布局，并输出给绘制流程，将像素渲染到屏幕上。优化上述每一个步骤对实现最佳渲染性能至关重要。

• DOM 树与 CSSOM 树合并后形成渲染树。
• 渲染树只包含渲染网页所需的节点。
• 布局计算每个对象的精确位置和大小。
• 最后一步是绘制，使用最终渲染树将像素渲染到屏幕上。

Render Tree

第一步是让浏览器将 DOM 和 CSSOM 合并成一个“渲染树”，网罗网页上所有可见的 DOM 内容，以及每个节点的所有 CSSOM 样式信息。

为构建渲染树，浏览器大体上完成了下列工作：

1. 从 DOM 树的根节点开始遍历每个可见节点。
   • 某些节点不可见（例如脚本标记、元标记等），因为它们不会体现在渲染输出中，所以会被忽略。
   • 某些节点通过 CSS 隐藏，因此在渲染树中也会被忽略，例如，上例中的 span 节点---不会出现在渲染树中，---因为有一个显式规则在该节点上设置了“display: none”属性。
2. 对于每个可见节点，为其找到适配的 CSSOM 规则并应用它们。
3. 发射可见节点，连同其内容和计算的样式。

终输出的渲染同时包含了屏幕上的所有可见内容及其样式信息。有了渲染树，我们就可以进入“布局”阶段。

Layout

到目前为止，我们计算了哪些节点应该是可见的以及它们的计算样式，但我们尚未计算它们在设备视口内的确切位置和大小---这就是“布局”阶段，也称为“自动重排”。

为弄清每个对象在网页上的确切大小和位置，浏览器从渲染树的根节点开始进行遍历。让我们考虑下面这样一个简单的实例：

<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>Critial Path: Hello world!</title>
  </head>
  <body>
    <div style="width: 50%">
      <div style="width: 50%">Hello world!</div>
    </div>
  </body>
</html>

布局流程的输出是一个“盒模型”，它会精确地捕获每个元素在视口内的确切位置和尺寸：所有相对测量值都转换为屏幕上的绝对像素。

以上网页的正文包含两个嵌套 div：第一个（父）div 将节点的显示尺寸设置为视口宽度的 50%，---父 div 包含的第二个 div---将其宽度设置为其父项的 50%；即视口宽度的 25%。

最后，既然我们知道了哪些节点可见、它们的计算样式以及几何信息，我们终于可以将这些信息传递给最后一个阶段：将渲染树中的每个节点转换成屏幕上的实际像素。这一步通常称为“绘制”或“栅格化”。

Paint

上述步骤都需要浏览器完成大量工作，所以相当耗时。不过，Chrome DevTools 可以帮助我们对上述所有三个阶段进行深入的了解。让我们看一下最初“hello world”示例的布局阶段：

• “Layout”事件在时间线中捕获渲染树构建以及位置和尺寸计算。
• 布局完成后，浏览器会立即发出“Paint Setup”和“Paint”事件，将渲染树转换成屏幕上的像素。

执行渲染树构建、布局和绘制所需的时间将取决于文档大小、应用的样式，以及运行文档的设备：文档越大，浏览器需要完成的工作就越多；样式越复杂，绘制需要的时间就越长（例如，单色的绘制开销“较小”，而阴影的计算和渲染开销则要“大得多”）。

最后将在视口中看到下面的网页：

参考

• Critical Rendering Path
• How Browsers Work: Behind the scenes of modern web browsers

简介

本质都是为了解决异步action的问题

Redux Saga可以理解为一个和系统交互的常驻进程，其中，Saga可简单定义如下：

Saga = Worker + Watcher

saga特点：

• saga的应用场景是复杂异步，如长时事务LLT(long live transcation)等业务场景。
• 方便测试，可以使用takeEvery打印logger。
• 提供takeLatest/takeEvery/throttle方法，可以便利的实现对事件的仅关注最近事件、关注每一次、事件限频
• 提供cancel/delay方法，可以便利的取消、延迟异步请求
• 提供race(effects),[…effects]方法来支持竞态和并行场景
• 提供channel机制支持外部事件

Redux Saga适用于对事件操作有细粒度需求的场景，同时他们也提供了更好的可测试性。

thunk VS saga

这里有一个简单的需求，登录页面，使用redux-thunk与async / await。组件可能看起来像这样，像平常一样分派操作。

组件部分二者应该是大同小异：

import { login } from 'redux/auth';

class LoginForm extends Component {

  onClick(e) {
    e.preventDefault();
    const { user, pass } = this.refs;
    this.props.dispatch(login(user.value, pass.value));
  }

  render() {
    return (<div>
        <input type="text" ref="user" />
        <input type="password" ref="pass" />
        <button onClick={::this.onClick}>Sign In</button>
    </div>);
  } 
}

export default connect((state) => ({}))(LoginForm);

使用redux-thunk

登录的action文件

// auth.js

import request from 'axios';
import { loadUserData } from './user';

// define constants
// define initial state
// export default reducer

export const login = (user, pass) => async (dispatch) => {
    try {
        dispatch({ type: LOGIN_REQUEST });
        let { data } = await request.post('/login', { user, pass });
        await dispatch(loadUserData(data.uid));
        dispatch({ type: LOGIN_SUCCESS, data });
    } catch(error) {
        dispatch({ type: LOGIN_ERROR, error });
    }
}

// more actions...

更新用户数据的页面：

// user.js

import request from 'axios';

// define constants
// define initial state
// export default reducer

export const loadUserData = (uid) => async (dispatch) => {
    try {
        dispatch({ type: USERDATA_REQUEST });
        let { data } = await request.get(`/users/${uid}`);
        dispatch({ type: USERDATA_SUCCESS, data });
    } catch(error) {
        dispatch({ type: USERDATA_ERROR, error });
    }
}

// more actions...

使用redux-saga

export function* loginSaga() {
  while(true) {
    const { user, pass } = yield take(LOGIN_REQUEST) //等待 Store 上指定的 action LOGIN_REQUEST
    try {
      let { data } = yield call(request.post, '/login', { user, pass }); //阻塞，请求后台数据
      yield fork(loadUserData, data.uid); //非阻塞执行loadUserData
      yield put({ type: LOGIN_SUCCESS, data }); //发起一个action，类似于dispatch
    } catch(error) {
      yield put({ type: LOGIN_ERROR, error });
    }  
  }
}

export function* loadUserData(uid) {
  try {
    yield put({ type: USERDATA_REQUEST });
    let { data } = yield call(request.get, `/users/${uid}`);
    yield put({ type: USERDATA_SUCCESS, data });
  } catch(error) {
    yield put({ type: USERDATA_ERROR, error });
  }
}

我们使用形式yield call(func，… args)调用api函数。调用不会执行效果，它只是创建一个简单的对象，如{type：’CALL’，func，args}。执行被委托给redux-saga中间件，该中间件负责执行函数并且用其结果恢复generatorr。

优点

相比Redux Thunk，使用Redux Saga有几处明显的变化：

• 在组件中，不再dispatch(action creator)，而是dispatch(pure action)
• 组件中不再关注由谁来处理当前action，action经由root saga分发
• 具体业务处理方法中，通过提供的call/put等帮助方法，声明式的进行方法调用
• 使用ES6 Generator语法，简化异步代码语法

除开上述这些不同点，Redux Saga真正的威力，在于其提供了一系列帮助方法，使得对于各类事件可以进行更细粒度的控制，从而完成更加复杂的操作。

方便测试

const iterator = loginSaga()

assert.deepEqual(iterator.next().value, take(LOGIN_REQUEST))

// resume the generator with some dummy action
const mockAction = {user: '...', pass: '...'}
assert.deepEqual(
  iterator.next(mockAction).value, 
  call(request.post, '/login', mockAction)
)

// simulate an error result
const mockError = 'invalid user/password'
assert.deepEqual(
  iterator.throw(mockError).value, 
  put({ type: LOGIN_ERROR, error: mockError })
)

注意，我们通过简单地将模拟数据注入迭代器的下一个方法来检查api调用结果。模拟数据比模拟函数更简单。

监听过滤action

通过yield take(ACTION)可以方便自由的对action进行拦截和过滤。Thunks由每个新动作的动作创建者调用(例如LOGIN_REQUEST)。即动作被不断地推送到thunk，并且thunk不能控制何时停止处理那些动作。

复杂应用场景

假设例如我们要添加以下要求：

• 处理LOGOUT用户操作
• 在第一次成功登录时，服务器返回token，该token在expires_in字段中存储的一些后到期。我们必须在每隔expires_in毫秒时间后的重新向后台刷新授权
• 考虑到在等待api调用的结果(初始登录或刷新)时，用户可以在其间注销

你将如何实现这一点与thunk？同时还为整个流程提供全面的测试覆盖？

可是如果你使用redux-saga：

function* authorize(credentials) {
  const token = yield call(api.authorize, credentials)
  yield put( login.success(token) )
  return token
}

function* authAndRefreshTokenOnExpiry(name, password) {
  let token = yield call(authorize, {name, password})
  while(true) {
    yield call(delay, token.expires_in)
    token = yield call(authorize, {token})
  }
}

function* watchAuth() {
  while(true) {
    try {
      const {name, password} = yield take(LOGIN_REQUEST)

      yield race([
        take(LOGOUT),
        call(authAndRefreshTokenOnExpiry, name, password)
      ])

      // user logged out, next while iteration will wait for the
      // next LOGIN_REQUEST action

    } catch(error) {
      yield put( login.error(error) )
    }
  }
}

在上面的例子中，我们使用race表示了并发要求。

• 如果take(LOGOUT)赢得比赛(即用户点击注销按钮)。比赛将自动取消authAndRefreshTokenOnExpiry后台任务。
• 如果authAndRefreshTokenOnExpiry在调用(授权，{token})调用的中间被阻止，它也将被取消。取消自动向下传播。

其他特殊场景

同时执行多个任务

有时候我们需要在几个ajax请求执行完之后，再执行对应的操作。redux-thunk需要借助第三方的库，而redux-saga是直接实现的。

import { call } from 'redux-saga/effects'

// 正确写法, effects 将会同步执行
const [users, repos] = yield [
  call(fetch, '/users'),
  call(fetch, '/repos')
]

当我们需要 yield 一个包含 effects 的数组， generator 会被阻塞直到所有的 effects 都执行完毕，或者当一个 effect 被拒绝 （就像 Promise.all 的行为）。

监听action

在redux-saga中，我们可以使用了辅助函数 takeEvery 在每个 action 来到时派生一个新的任务。 这多少有些模仿 redux-thunk 的行为：举个例子，每次一个组件调用 fetchProducts Action 创建器（Action Creator），Action 创建器就会发起一个 thunk 来执行控制流。

在现实情况中，takeEvery 只是一个在强大的低阶 API 之上构建的辅助函数。 在这一节中我们将看到一个新的 Effect，即 take。take 让我们通过全面控制 action 观察进程来构建复杂的控制流成为可能。

让我们开始一个简单的 Saga 例子，这个 Saga 将监听所有发起到 store 的 action，然后将它们记录到控制台。

使用 takeEvery('')（ 代表通配符模式），我们就能捕获发起的所有类型的 action。

import { takeEvery } from 'redux-saga'

function* watchAndLog(getState) {
  yield* takeEvery('*', function* logger(action) {
    console.log('action', action)
    console.log('state after', getState())
  })
}

现在我们知道如何使用 take Effect 来实现和上面相同的功能：

import { take } from 'redux-saga/effects'

function* watchAndLog(getState) {
  while(true) {
    const action = yield take('*')
    console.log('action', action)
    console.log('state after', getState())
  })
}

take 就像我们更早之前看到的 call 和 put。它创建另一个命令对象，告诉 middleware 等待一个特定的 action。 正如在 call Effect 的情况中，middleware 会暂停 Generator，直到返回的 Promise 被 resolve。 在 take 的情况中，它将会暂停 Generator 直到一个匹配的 action 被发起了。 在以上的例子中，watchAndLog 处于暂停状态，直到任意的一个 action 被发起。

注意，我们运行了一个无限循环的 while(true)。记住这是一个 Generator 函数，它不具备 从运行至完成 的行为（run-to-completion behavior）。 Generator 将在每次迭代上阻塞以等待 action 发起。

一个简单的例子，假设在我们的 Todo 应用中，我们希望监听用户的操作，并在用户初次创建完三条 Todo 信息时显示祝贺信息。

import { take, put } from 'redux-saga/effects'

function* watchFirstThreeTodosCreation() {
  for(let i = 0; i < 3; i++) {
    const action = yield take('TODO_CREATED')
  }
  yield put({type: 'SHOW_CONGRATULATION'})
}

与 while(true) 不同，我们运行一个只迭代三次的 for 循环。在 take 初次的 3 个 TODO_CREATED action 之后， watchFirstThreeTodosCreation Saga 将会使应用显示一条祝贺信息然后中止。这意味着 Generator 会被回收并且相应的监听不会再发生。

任务取消

一旦任务被 fork，可以使用 yield cancel(task) 来中止任务执行。取消正在运行的任务，将抛出 SagaCancellationException 错误。

防抖动

为了对 action 队列进行防抖动，可以在被 fork 的任务里放置一个 delay。

const delay = (ms) => new Promise(resolve => setTimeout(resolve, ms))

function* handleInput(input) {
  // 500ms 防抖动
  yield call(delay, 500)
  ...
}

function* watchInput() {
  let task
  while(true) {
    const { input } = yield take('INPUT_CHANGED')
    if(task)
      yield cancel(task)
    task = yield fork(handleInput, input)
  }
}

在上面的示例中，handleInput 在执行之前等待了 500ms。如果用户在此期间输入了更多文字，我们将收到更多的 INPUT_CHANGED action。 并且由于 handleInput 仍然会被 delay 阻塞，所以在执行自己的逻辑之前它会被 watchInput 取消。

常用

Effect

一个 effect 就是一个纯文本 JavaScript 对象，包含一些将被 saga middleware 执行的指令。

使用 redux-saga 提供的工厂函数来创建 effect。 举个例子，你可以使用 call(myfunc, 'arg1', 'arg2') 指示 middleware 调用 myfunc('arg1', 'arg2') 并将结果返回给 yield 了 effect 的那个 Generator。

从 Saga 内触发异步操作（Side Effect）总是由 yield 一些声明式的 Effect 来完成的 （你也可以直接 yield Promise，但是这会让测试变得困难。使用 Effect 诸如 call 和 put，与高阶 API 如 takeEvery 相结合，让我们实现与 redux-thunk 同样的东西， 但又有额外的易于测试的好处。

task

一个 task 就像是一个在后台运行的进程。在基于 redux-saga 的应用程序中，可以同时运行多个 task。通过 fork 函数来创建 task：

function* saga() {
  ...
  const task = yield fork(otherSaga, ...args)
  ...
}

Watcher/Worker

指的是一种使用两个单独的 Saga 来组织控制流的方式。

Watcher: 监听发起的 action 并在每次接收到 action 时 fork 一个 worker。

Worker: 处理 action 并结束它。

示例：

function* watcher() {
  while(true) {
    const action = yield take(ACTION)
    yield fork(worker, action.payload)
  }
}

function* worker(payload) {
  // ... do some stuff
}

take(pattern)

创建一条 Effect 描述信息，指示 middleware 等待 Store 上指定的 action。 Generator 会暂停，直到一个与 pattern 匹配的 action 被发起。

用以下规则来解释 pattern：

• 如果调用 take 时参数为空，或者传入 '*'，那将会匹配所有发起的 action（例如，take() 会匹配所有的 action）。
• 如果是一个函数，action 会在 pattern(action) 返回为 true 时被匹配（例如，take(action => action.entities) 会匹配那些 entities 字段为真的 action）。
• 如果是一个字符串，action 会在 action.type === pattern 时被匹配（例如，take(INCREMENT_ASYNC)）。
• 如果参数是一个数组，会针对数组所有项，匹配与 action.type 相等的 action（例如，take([INCREMENT, DECREMENT]) 会匹配 INCREMENT 或 DECREMENT 类型的 action）。

put(action)

用于触发 action，功能上类似于dispatch。

创建一条dispatch Effect 描述信息，指示 middleware 发起一个 action 到 Store。

• action: Object - 完整信息可查看 Redux 的 dispatch 文档

直接使用dispatch：

//...

function* fetchProducts(dispatch)
  const products = yield call(Api.fetch, '/products')
  dispatch({ type: 'PRODUCTS_RECEIVED', products })
}

该解决方案与我们在上一节中看到的从 Generator 内部直接调用函数，有着相同的缺点。如果我们想要测试 fetchProducts 接收到 AJAX 响应之后执行 dispatch， 我们还需要模拟 dispatch 函数。

相反，我们需要同样的声明式的解决方案。只需创建一个对象来指示 middleware 我们需要发起一些 action，然后让 middleware 执行真实的 dispatch。 这种方式我们就可以同样的方式测试 Generator 的 dispatch：只需检查 yield 后的 Effect，并确保它包含正确的指令。

redux-saga 为此提供了另外一个函数 put，这个函数用于创建 dispatch Effect。

import { call, put } from 'redux-saga/effects'
//...

function* fetchProducts() {
  const products = yield call(Api.fetch, '/products')
  // 创建并 yield 一个 dispatch Effect
  yield put({ type: 'PRODUCTS_RECEIVED', products })
}

现在，我们可以像上一节那样轻易地测试 Generator：

import { call, put } from 'redux-saga/effects'
import Api from '...'

const iterator = fetchProducts()

// 期望一个 call 指令
assert.deepEqual(
  iterator.next().value,
  call(Api.fetch, '/products'),
  "fetchProducts should yield an Effect call(Api.fetch, './products')"
)

// 创建一个假的响应对象
const products = {}

// 期望一个 dispatch 指令
assert.deepEqual(
  iterator.next(products).value,
  put({ type: 'PRODUCTS_RECEIVED', products }),
  "fetchProducts should yield an Effect put({ type: 'PRODUCTS_RECEIVED', products })"
)

call(fn, ...args)

用于调用异步逻辑，支持 promise 。

创建一条 Effect 描述信息，指示 middleware 调用 fn 函数并以 args 为参数。fn 既可以是一个普通函数，也可以是一个 Generator 函数。

middleware 调用这个函数并检查它的结果。

如果结果是一个 Generator 对象，middleware 会执行它，就像在启动 Generator （startup Generators，启动时被传给 middleware）时做的。 如果有子级 Generator，那么在子级 Generator 正常结束前，父级 Generator 会暂停，这种情况下，父级 Generator 将会在子级 Generator 返回后继续执行，或者直到子级 Generator 被某些错误中止， 如果是这种情况，将在父级 Generator 中抛出一个错误。

如果结果是一个 Promise，middleware 会暂停直到这个 Promise 被 resolve，resolve 后 Generator 会继续执行。 或者直到 Promise 被 reject 了，如果是这种情况，将在 Generator 中抛出一个错误。
当 Generator 中抛出了一个错误，如果有一个 try/catch 包裹当前的 yield 指令，控制权将被转交给 catch。 否则，Generator 会被错误中止，并且如果这个 Generator 被其他 Generator 调用了，错误将会传到调用的 Generator。

yield fork(fn ...args) 的结果是一个 Task 对象 —— 一个具备某些有用的方法和属性的对象

fork(fn, ...args)

创建一条 Effect 描述信息，指示 middleware 以 无阻塞调用 方式执行 fn。

fork 类似于 call，可以用来调用普通函数和 Generator 函数。但 fork 的调用是无阻塞的，在等待 fn 返回结果时，middleware 不会暂停 Generator。 相反，一旦 fn 被调用，Generator 立即恢复执行。
fork 与 race 类似，是一个中心化的 Effect，管理 Sagas 间的并发。

race(effects)

创建一条 Effect 描述信息，指示 middleware 在多个 Effect 之间执行一个 race（类似 Promise.race([...]) 的行为）。

api

redux-saga的其他详细API列举如下，API详解可以查看API 参考

• Middleware API
  • createSagaMiddleware(...sagas)
  • middleware.run(saga, ...args)
• Saga Helpers
  • takeEvery(pattern, saga, ...args)
  • takeLatest(pattern, saga, ..args)
• Effect creators
  • take(pattern)
  • put(action)
  • call(fn, ...args)
  • call([context, fn], ...args)
  • apply(context, fn, args)
  • cps(fn, ...args)
  • cps([context, fn], ...args)
  • fork(fn, ...args)
  • fork([context, fn], ...args)
  • join(task)
  • cancel(task)
  • select(selector, ...args)
• Effect combinators
  • race(effects)
  • [...effects] (aka parallel effects)
• Interfaces
  • Task
• External API
  • runSaga(iterator, {subscribe, dispatch, getState}, [monitor])

参考

• 初级教程
• 探索Redux的最佳实践
• redux-saga 实践总结
• Redux Saga实践
• redux-saga vs redux-thunk的优点/缺点
• Redux的全家桶与最佳实践

相关字段简述

RFC2616规定的47种http报文首部字段中与缓存相关的字段。

通用头部字段

请求头部字段

响应头部字段

实体头部字段

Pragma与Expires

在 http1.0 时代，给客户端设定缓存方式可通过两个字段——Pragma和Expires来规范。虽然这两个字段早可抛弃，但为了做http协议的向下兼容，你还是可以看到很多网站依旧会带上这两个字段。

Pragma

当该字段值为no-cache的时候（事实上现在RFC中也仅标明该可选值），会知会客户端不要对该资源读缓存，即每次都得向服务器发一次请求才行。

Expires

有了Pragma来禁用缓存，自然也需要有个东西来启用缓存和定义缓存时间，对http1.0而言，Expires就是做这件事的首部字段。 Expires的值对应一个GMT（格林尼治时间），比如Mon, 22 Jul 2002 11:12:01 GMT来告诉浏览器资源缓存过期时间，如果还没过该时间点则不发请求。

Tips

如果Pragma头部和Expires头部同时存在，则起作用的会是Pragma，有兴趣的同学可以自己试一下。

需要注意的是，响应报文中Expires所定义的缓存时间是相对服务器上的时间而言的，其定义的是资源“失效时刻”，如果客户端上的时间跟服务器上的时间不一致（特别是用户修改了自己电脑的系统时间），那缓存时间可能就意义了。

Cache-Control

针对上述的“Expires时间是相对服务器而言，无法保证和客户端时间统一”的问题，http1.1新增了 Cache-Control 来定义缓存过期时间。注意：若报文中同时出现了 Expires 和 Cache-Control，则以 Cache-Control 为准。

也就是说优先级从高到低分别是 Pragma -> Cache-Control -> Expires 。

Cache-Control也是一个通用首部字段，这意味着它能分别在请求报文和响应报文中使用。在RFC中规范了 Cache-Control 的格式为：

"Cache-Control" ":" cache-directive

作为请求首部时，cache-directive 的可选值有：

作为响应首部时，cache-directive 的可选值有：

Cache-Control 允许自由组合可选值，例如：

Cache-Control: max-age=3600, must-revalidate

它意味着该资源是从原服务器上取得的，且其缓存（新鲜度）的有效时间为一小时，在后续一小时内，用户重新访问该资源则无须发送请求。 当然这种组合的方式也会有些限制，比如 no-cache 就不能和 max-age、min-fresh、max-stale 一起搭配使用。

缓存校验字段

上述的首部字段均能让客户端决定是否向服务器发送请求，比如设置的缓存时间未过期，那么自然直接从本地缓存取数据即可（在chrome下表现为200 from cache），若缓存时间过期了或资源不该直接走缓存，则会发请求到服务器去。

我们现在要说的问题是，如果客户端向服务器发了请求，那么是否意味着一定要读取回该资源的整个实体内容呢？

我们试着这么想——客户端上某个资源保存的缓存时间过期了，但这时候其实服务器并没有更新过这个资源，如果这个资源数据量很大，客户端要求服务器再把这个东西重新发一遍过来，是否非常浪费带宽和时间呢？

答案是肯定的，那么是否有办法让服务器知道客户端现在存有的缓存文件，其实跟自己所有的文件是一致的，然后直接告诉客户端说“这东西你直接用缓存里的就可以了，我这边没更新过呢，就不再传一次过去了”。

为了让客户端与服务器之间能实现缓存文件是否更新的验证、提升缓存的复用率，Http1.1新增了几个首部字段来做这件事情。

Last-Modified

服务器将资源传递给客户端时，会将资源最后更改的时间以“Last-Modified: GMT”的形式加在实体首部上一起返回给客户端。

Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT

客户端会为资源标记上该信息，下次再次请求时，会把该信息附带在请求报文中一并带给服务器去做检查。

• 若传递的时间值与服务器上该资源最终修改时间是一致的，则说明该资源没有被修改过，直接返回304状态码，内容为空。
• 如果两个时间不一致，则服务器会发回该资源并返回200状态码，和第一次请求时类似。

这样保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。一个304响应比一个静态资源通常小得多，这样就节省了网络带宽。

If-Modified-Since: Last-Modified-value

示例为 If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT
该请求首部告诉服务器如果客户端传来的最后修改时间与服务器上的一致，则直接回送304 和响应报头即可。
当前各浏览器均是使用的该请求首部来向服务器传递保存的 Last-Modified 值。

If-Unmodified-Since: Last-Modified-value

该值告诉服务器，若Last-Modified没有匹配上（资源在服务端的最后更新时间改变了），则应当返回412(Precondition Failed) 状态码给客户端。 Last-Modified 存在一定问题，如果在服务器上，一个资源被修改了，但其实际内容根本没发生改变，会因为Last-Modified时间匹配不上而返回了整个实体给客户端（即使客户端缓存里有个一模一样的资源）。

Etag

为了解决上述Last-Modified可能存在的不准确的问题，Http1.1还推出了 ETag 实体首部字段。 服务器会通过某种算法，给资源计算得出一个唯一标志符（比如md5标志），在把资源响应给客户端的时候，会在实体首部加上“ETag: 唯一标识符”一起返回给客户端。例如：

Etag: "5d8c72a5edda8d6a:3239"

客户端会保留该 ETag 字段，并在下一次请求时将其一并带过去给服务器。服务器只需要比较客户端传来的ETag跟自己服务器上该资源的ETag是否一致，就能很好地判断资源相对客户端而言是否被修改过了。

• 如果服务器发现ETag匹配不上，那么直接以常规GET 200回包形式将新的资源（当然也包括了新的ETag）发给客户端
• 如果ETag是一致的，则直接返回304知会客户端直接使用本地缓存即可。

那么客户端是如何把标记在资源上的 ETag 传回给服务器的呢？请求报文中有两个首部字段可以带上 ETag 值：

If-None-Match: ETag-value

示例为 If-None-Match: "5d8c72a5edda8d6a:3239"

• 告诉服务端如果 ETag 没匹配上需要重发资源数据
• 否则直接回送304和响应报头即可。 当前各浏览器均是使用的该请求首部来向服务器传递保存的 ETag 值。

If-Match: ETag-value

• 告诉服务器如果没有匹配到ETag，或者收到了“*”值而当前并没有该资源实体，则应当返回412(Precondition Failed) 状态码给客户端。
• 否则服务器直接忽略该字段。

需要注意的是，如果资源是走分布式服务器（比如CDN）存储的情况，需要这些服务器上计算ETag唯一值的算法保持一致，才不会导致明明同一个文件，在服务器A和服务器B上生成的ETag却不一样。

缓存头部对比

几种字段的对比：

用户刷新/访问行为

我们可以把刷新/访问界面的手段分成三类,在浏览器中，有时候你会发现通过不同的手段访问/刷新界面页面的呈现速度是不一样的，那么它们到底有什么区别呢?

在URI输入栏中输入然后回车/通过书签访问

返回响应码是 200 OK (from cache)，浏览器发现该资源已经缓存了而且没有过期（通过Expires头部或者Cache-Control头部），没有跟服务器确认，而是直接使用了浏览器缓存的内容。其中响应内容和之前的响应内容一模一样，例如其中的Date时间是上一次响应的时间。

F5/点击工具栏中的刷新按钮/右键菜单重新加载

F5的作用和直接在URI输入栏中输入然后回车是不一样的，F5会让浏览器无论如何都发一个HTTP Request给Server，即使先前的响应中有Expires头部。所以，当我在当前 腾讯课堂 网页中按F5的时候，浏览器会发送一个HTTP Request给Server，但是包含这样的Headers:

Cache-Control: max-age=0
If-Modified-Since: Fri, 15 Jul 2016 04:11:51 GMT

其中Cache-Control是Chrome强制加上的，而If-Modified-Since是因为获取该资源的时候包含了Last-Modified头部，浏览器会使用If-Modified-Since头部信息重新发送该时间以确认资源是否需要重新发送。 实际上Server没有修改这个index.css文件，所以返回了一个304(Not Modified)，这样的响应信息很小，所消耗的route-trip不多，网页很快就刷新了。

上面的例子中没有ETag，如果Response中包含ETag，F5引发的Http Request中也是会包含If-None-Match的。

Ctl+F5

Ctrl+F5要的是彻底的从Server拿一份新的资源过来，所以不光要发送HTTP request给Server，而且这个请求里面连If-Modified-Since/If-None-Match都没有，这样就逼着Server不能返回304，而是把整个资源原原本本地返回一份，这样，Ctrl+F5引发的传输时间变长了，自然网页Refresh的也慢一些。我们可以看到该操作返回了200，并刷新了相关的缓存控制时间。

实际上，为了保证拿到的是从Server上最新的，Ctrl+F5不只是去掉了If-Modified-Since/If-None-Match，还需要添加一些HTTP Headers。

按照HTTP/1.1协议，Cache不光只是存在Browser终端，从Browser到Server之间的中间节点(比如Proxy)也可能扮演Cache的作用，为了防止获得的只是这些中间节点的Cache，需要告诉他们，别用自己的Cache敷衍我，往Upstream的节点要一个最新的copy吧。

在Chrome 51 中会包含两个头部信息， 作用就是让中间的Cache对这个请求失效，这样返回的绝对是新鲜的资源。

Cache-Control: no-cache
Pragma: no-cache

缓存实践

综上对各种HTTP缓存控制头部的对比以及用户可能出现的浏览器刷新行为的讨论，当我们在一个项目上做http缓存的应用时，我们实际上还是会把上述提及的大多数首部字段均使用上。

Expires / Cache-Control

Expires用时刻来标识失效时间，不免收到时间同步的影响，而Cache-Control使用时间间隔很好的解决了这个问题。 但是 Cache-Control 是 HTTP1.1 才有的，不适用于 HTTP1.0，而 Expires 既适用于 HTTP1.0，也适用于 HTTP1.1，所以说在大多数情况下同时发送这两个头会是一个更好的选择，当客户端两种头都能解析的时候，会优先使用 Cache-Control。

Last-Modified / ETag

二者都是通过某个标识值来请求资源， 如果服务器端的资源没有变化，则自动返回 HTTP 304 （Not Changed）状态码，内容为空，这样就节省了传输数据量。而当资源发生比那话后，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。

其中Last-Modified使用文件最后修改作为文件标识值，它无法处理文件一秒内多次修改的情况，而且只要文件修改了哪怕文件实质内容没有修改，也会重新返回资源内容；ETag作为“被请求变量的实体值”，其完全可以解决Last-Modified头部的问题，但是其计算过程需要耗费服务器资源。

from-cache / 304

Expires和Cache-Control都有一个问题就是服务端作为的修改，如果还在缓存时效里，那么客户端是不会去请求服务端资源的（非刷新），这就存在一个资源版本不符的问题，而强制刷新一定会发起HTTP请求并返回资源内容，无论该内容在这段时间内是否修改过；而Last-Modified和Etag每次请求资源都会发起请求，哪怕是很久都不会有修改的资源，都至少有一次请求响应的消耗。

对于所有可缓存资源，指定一个Expires或Cache-Control max-age以及一个Last-Modified或ETag至关重要。同时使用前者和后者可以很好的相互适应。

前者不需要每次都发起一次请求来校验资源时效性，后者保证当资源未出现修改的时候不需要重新发送该资源。而在用户的不同刷新页面行为中，二者的结合也能很好的利用HTTP缓存控制特性，无论是在地址栏输入URI然后输入回车进行访问，还是点击刷新按钮，浏览器都能充分利用缓存内容，避免进行不必要的请求与数据传输。

避免304

同学们是否还记得我们在讨论用户刷新页面行为中体积的index.css文件，它实际上被命名为index.03d344bd.css。而细心的同学也会发现它的Expires和Cache-Control时间出奇的长，这难道不会导致用户无法得到其最近的内容吗？

其做法实际上很简单，它把服务侧ETag的那一套理论搬到了前端来使用。 页面的静态资源以版本形式发布，常用的方法是在文件名或参数带上一串md5或时间标记符：

https://hm.baidu.com/hm.js?e23800c454aa573c0ccb16b52665ac26
http://tb1.bdstatic.com/tb/_/tbean_safe_ajax_94e7ca2.js
http://img1.gtimg.com/ninja/2/2016/04/ninja145972803357449.jpg

可以看到上面的例子中有不同的做法，有的在URI后面加上了md5参数，有的将md5值作为文件名的一部分，有的将资源放在特性版本的目录中。

那么在文件没有变动的时候，浏览器不用发起请求直接可以使用缓存文件；而在文件有变化的时候，由于文件版本号的变更，导致文件名变化，请求的url变了，自然文件就更新了。这样能确保客户端能及时从服务器收取到新修改的文件。通过这样的处理，增长了静态资源，特别是图片资源的缓存时间，避免该资源很快过期，客户端频繁向服务端发起资源请求，服务器再返回304响应的情况（有Last-Modified/Etag）。

Tips

• 需要兼容HTTP1.0的时候需要使用Expires，不然可以考虑直接使用Cache-Control
• 需要处理一秒内多次修改的情况，或者其他Last-Modified处理不了的情况，才使用ETag，否则使用Last-Modified。
• 对于所有可缓存资源，需要指定一个Expires或Cache-Control，同时指定Last-Modified或者Etag。
• 可以通过标识文件版本名、加长缓存时间的方式来减少304响应。

总结

参考

• HTTP缓存小结
• HTTP/1.1: Caching in HTTP
• HTTP conditional requests - HTTP | MDN

抽取不相关的子问题

大部分代码都是一般代码。通过建立一大组库和辅助函数来解决一般问题，剩下的只是让你的程序与众不同的核心部分。

这个技巧有帮助的原因是它使程序员关注小而定义良好的问题，这些问题已经同项目的其他部分脱离。其结果是，对于这些子问题的解决方案倾向于更加完整和正确。你也可以在以后重用它们。

一次只做一件事

应该把代码组织得一次只做一件事情。

如果你有很难读的代码，尝试把它所做的所有任务列出来。其中一些任务可以很容易地变成单独的函数（或类）。其他的可以简单地成为一个函数中的逻辑“段落”。具体如何拆分这些任务没有它们已经分开这个事实那样重要。难的是要准确地描述你的程序所做的所有这些小事情。

把想法变成代码

如果你不能把一件事解释给你祖母听的话说明你还没有真正理解它。

当把一件复杂的事向别人解释时，那些小细节很容易就会让他们迷惑。把一个想法用自然语言解释是个很有价值的能力，因为这样其他知识没有你这么渊博的人才可以理解它。这需要把一个想法精炼成最重要的概念。这样做不仅帮助他人理解，而且也帮助你自己把这个想法想得更清晰。

在你把代码“展示”给读者时也应使用同样的技巧。我们接受代码是你解释程序所做事情的主要手段这一关点。所以代码应当用自然语言编写。

少些代码

最好读的代码就是没有代码。

别费神实现那个功能——你不会需要它

当你开始一个项目，自然会很兴奋并且想着你希望实现的所有很酷的功能。但是程序员倾向于高估有多少功能真的对于他们的项目来讲是必不可少的。很多功能结果没有完成，或者没有用到，也可能只是让程序更复杂。

程序员还倾向于低估实现一个功能所要花的工夫。我们乐观地估计了实现一个粗糙原型所要花的时间，但是忘记了在将来代码库的维护、文件以及后增的“重量”所带来的额外时间。

质疑和拆分你的需求

不是所有的程序都需要运行得快，100%准确，并且能处理所有的输入。如果你真的仔细检查你的需求，有时你可以把它削减成一个简单的问题，只需要较少的代码。

怎么说“减少需求”和“解决更简单的问题”的好处都不为过。需求常常以微妙的方式互相影响。这意味着解决一半的问题可能只需要花四分之一的工夫。

保持小代码库

最好的解决办法就是“让你的代码库越小，越轻量级越好”，就算你的项目在增长。那么你就要：

• 创建越多越好的“工具”代码来减少重复代码（见第10章）。
• 减少无用代码或没有用的功能（见下图）。
• 让你的项目保持分开的子项目状态。
• 总的来说，要小心代码的“重量”。让它保持又轻又灵。

熟悉你周边的库

很多时候，程序员就是不知道现有的库可以解决他们的问题。或者有时，它们忘了库可以做什么。知道你的库能做什么以便你可以使用它，这一点很重要。

这里有一条比较中肯的建议：每隔一段时间，花15分钟来阅读标准库中的所有函数/模块/类型的名字。这包括C++标准模板库（STL）、Java API、Python内置的模块以及其他内容。

这样做的目的不是记住整个库。这只是为了了解有什么可以用的，以便下次你写新代码时会想：“等一下，这个听起来和我在API中见到的东西有点像……” 我们相信提前做这种准备很快就会得到回报，起码因为你会更倾向于使用库了。

一个常被引用的统计结果是一个平均水平的软件工程师每天写出10行可以放到最终产品中的代码。当程序员们刚一听到这个，他们根本不相信——“10行代码？我一分钟就写出来了！”

这里的关键词是“最终产品中的”。在一个成熟的库中，每一行代码都代表相当大量的设计、调试、重写、文档、优化和测试。任何经受了这样达尔文进化过程一样的代码行就是很有价值的。这就是为什么重用库有这么大的好处，不仅节省时间，还少写了代码。

你可以通过以下方法避免编写新代码：

• 从项目中消除不必要的功能，不要过度设计。
• 重新考虑需求，解决版本最简单的问题，只要能完成工作就行。
• 经常性地通读标准库的整个API，保持对它们的熟悉程度。

正则表达式（Regular Expression）是一种处理字符串匹配的语言。

很可能你使用过 Windows/Dos 下用于文件查找的通配符(wildcard)，也就是 * 和 ? 。如果你想查找某个目录下的所有的Word文档的话，你会搜索 *.doc。在这里，* 会被解释成任意的字符串。和通配符类似，正则表达式也是用来进行文本匹配的工具，只不过比起通配符，它能更精确地描述你的需求 —— 当然，代价就是更复杂——比如你可以编写一个正则表达式，用来查找所有以0开头，后面跟着2-3个数字，然后是一个连字号 “-”，最后是7或8位数字的字符串(像010-12345678或0376-7654321)。

JavaScript 同样也对正则表达式有很好的支持，RegExp 是 JavaScript 中的内置“类”，通过使用RegExp，用户可以自己定义模式来对字符串进行匹配。而 JavaScrip t中的 String 对象的 replace 方法也支持使用正则表达式对串进行匹配，一旦匹配，还可以通过调用预设的回调函数来进行替换。

入门

学习正则表达式的最好方法是从例子开始，理解例子之后再自己对例子进行修改，实验。下面给出了不少简单的例子，并对它们作了详细的说明。

假设你在一篇英文小说里查找hi，你可以使用正则表达式hi。

这几乎是最简单的正则表达式了，它可以精确匹配这样的字符串：由两个字符组成，前一个字符是 h ,后一个是i。

通常，处理正则表达式的工具会提供一个忽略大小写的选项，如果选中了这个选项，它可以匹配 hi,HI,Hi,hI 这四种情况中的任意一种。

不幸的是，很多单词里包含hi这两个连续的字符，比如 him,history,high 等等。用hi来查找的话，这里边的hi也会被找出来。如果要精确地查找hi这个单词的话，我们应该使用 \bhi\b。

\b 是正则表达式规定的一个特殊代码（好吧，某些人叫它元字符，metacharacter），代表着单词的开头或结尾，也就是单词的分界处。虽然通常英文的单词是由空格，标点符号或者换行来分隔的，但是\b并不匹配这些单词分隔字符中的任何一个，它只匹配一个位置。

如果需要更精确的说法，\b 匹配这样的位置：它的前一个字符和后一个字符不全是(一个是,一个不是或不存在)\w。
假如你要找的是hi后面不远处跟着一个 Lucy，你应该用 \bhi\b.*\bLucy\b。

这里，.是另一个元字符，匹配除了换行符以外的任意字符。*同样是元字符，不过它代表的不是字符，也不是位置，而是数量——它指定*前边的内容可以连续重复使用任意次以使整个表达式得到匹配。

因此，.*连在一起就意味着任意数量的不包含换行的字符。现在 \bhi\b.*\bLucy\b 的意思就很明显了：先是一个单词hi,然后是任意个任意字符(但不能是换行)，最后是Lucy这个单词。

换行符就是\n,ASCII编码为10(十六进制0x0A)的字符。

如果同时使用其它元字符，我们就能构造出功能更强大的正则表达式。比如下面这个例子：

0\d\d-\d\d\d\d\d\d\d\d 匹配这样的字符串：以0开头，然后是两个数字，然后是一个连字号“-”，最后是8个数字(也就是**的电话号码。当然，这个例子只能匹配区号为3位的情形)。

这里的\d是个新的元字符，匹配一位数字(0，或1，或2，或……)。- 不是元字符，只匹配它本身——连字符(或者减号，或者中横线，或者随你怎么称呼它)。

为了避免那么多烦人的重复，我们也可以这样写这个表达式：0\d{2}-\d{8}。这里\d后面的 {2}({8}) 的意思是前面 \d 必须连续重复匹配2次(8次)。

规则

优先权顺序

元字符

**元字符，是一些数学符号，在正则表达式中有特定的含义，而不仅仅表示其“字面”上的含义。**比如星号(*)，表示一个集合的零到多次重复，而问号(?)表示零次或一次。如果你需要使用元字符的字面意义，则需要转义。

常用的元字符

示例

• \ba\w*\b 匹配以字母a开头的单词——先是某个单词开始处(\b)，然后是字母a,然后是任意数量的字母或数字(\w*)，最后是单词结束处(\b)。
• \d+ 匹配1个或更多连续的数字。这里的 + 是和 * 类似的元字符，不同的是 *匹配重复任意次(可能是0次)，而+ 则匹配重复1次或更多次。
• \b\w{6}\b 匹配刚好6个字符的单词

和忽略大小写的选项类似，有些正则表达式处理工具还有一个处理多行的选项。如果选中了这个选项，^和$的意义就变成了匹配行的开始处和结束处。

重复

你已经看过了前面的 *,+,{2},{5,12} 这几个匹配重复的方式了。下面是正则表达式中所有的限定符(指定数量的代码，例如 *,{5,12} 等)

常用的限定符

示例

• Windows\d+ 匹配Windows后面跟1个或更多数字
• ^\w+ 匹配一行的第一个单词(或整个字符串的第一个单词，具体匹配哪个意思得看选项设置)

转义字符

特殊字符，主要是指注入空格，制表符，其他进制(十进制之外的编码方式)等，它们的特点是以转义字符()为前导。如果需要引用这些特殊字符的字面意义，同样需要转义。

字符类

要想查找数字，字母或数字，空白是很简单的，因为已经有了对应这些字符集合的元字符，但是如果你想匹配没有预定义元字符的字符集合(比如元音字母 a,e,i,o,u),应该怎么办？

很简单，你只需要在方括号里列出它们就行了，像 [aeiou] 就匹配任何一个英文元音字母，[.?!] 匹配标点符号(.或?或!)。
我们也可以轻松地指定一个字符范围，像 [0-9] 代表的含意与\d就是完全一致的：一位数字；同理 [a-z0-9A-Z_] 也完全等同于 \w（如果只考虑英文的话）。

下面是一个更复杂的表达式：\(?0\d{2}[) -]?\d{8}。

这个表达式可以匹配几种格式的电话号码，像(010)88886666，或 022-22334455，或 02912345678等。我们对它进行一些分析吧：首先是一个转义字符 \( , 它能出现 0 次或 1 次 (?),然后是一个 0，后面跟着2个数字 (\d{2})，然后是)或 - 或 空格 中的一个，它出现 1 次或不出现 (?)，最后是 8 个数字 (\d{8})。

使用工具可视化显示如下：

“(”和“)” 也是元字符，后面的分组节里会提到，所以在这里需要使用 转义。

分枝条件

不幸的是，刚才那个表达式也能匹配 010)12345678 或 (022-87654321 这样的 “不正确” 的格式。要解决这个问题，我们需要用到分枝条件。正则表达式里的分枝条件指的是有几种规则，如果满足其中任意一种规则都应该当成匹配，具体方法是用 | 把不同的规则分隔开。 听不明白？没关系，看例子：

0\d{2}-\d{8}|0\d{3}-\d{7} 这个表达式能匹配两种以连字号分隔的电话号码：一种是三位区号，8位本地号(如010-12345678)，一种是4位区号，7位本地号(0376-2233445)。

\(0\d{2}\)[- ]?\d{8}|0\d{2}[- ]?\d{8} 这个表达式匹配3位区号的电话号码，其中区号可以用小括号括起来，也可以不用，区号与本地号间可以用连字号或空格间隔，也可以没有间隔。你可以试试用分枝条件把这个表达式扩展成也支持4位区号的。

\d{5}-\d{4}|\d{5}这个表达式用于匹配美国的邮政编码。美国邮编的规则是5位数字，或者用连字号间隔的9位数字。之所以要给出这个例子是因为它能说明一个问题：使用分枝条件时，要注意各个条件的顺序。 如果你把它改成 \d{5}|\d{5}-\d{4} 的话，那么就只会匹配5位的邮编(以及9位邮编的前5位)。原因是匹配分枝条件时，将会从左到右地测试每个条件，如果满足了某个分枝的话，就不会去再管其它的条件了。

分组

我们已经提到了怎么重复单个字符（直接在字符后面加上限定符就行了）；但如果想要重复多个字符又该怎么办？你可以用小括号来指定子表达式(也叫做分组)，然后你就可以指定这个子表达式的重复次数了， 你也可以对子表达式进行其它一些操作(后面会有介绍)。

(\d{1,3}\.){3}\d{1,3} 是一个简单的IP地址匹配表达式。要理解这个表达式，请按下列顺序分析它：\d{1,3} 匹配1到3位的数字，(\d{1,3}\.){3} 匹配三位数字加上一个英文句号(这个整体也就是这个分组)重复3次，最后再加上一个一到三位的数字(\d{1,3})。

不幸的是，它也将匹配 256.300.888.999 这种不可能存在的IP地址。如果能使用算术比较的话，或许能简单地解决这个问题，但是正则表达式中并不提供关于数学的任何功能，所以只能使用冗长的分组，选择，字符类来描述一个正确的IP地址：((2[0-4]\d|25[0-5]|[01]?\d\d?)\.){3}(2[0-4]\d|25[0-5]|[01]?\d\d?)。

理解这个表达式的关键是理解 2[0-4]\d|25[0-5]|[01]?\d\d?，这里我就不细说了，你自己应该能分析得出来它的意义。

IP地址中每个数字都不能大于255. 经常有人问我, 01.02.03.04 这样前面带有0的数字, 是不是正确的IP地址呢? 答案是: 是的, IP 地址里的数字可以包含有前导 0 (leading zeroes).

反义

有时需要查找不属于某个能简单定义的字符类的字符。比如想查找除了数字以外，其它任意字符都行的情况，这时需要用到反义：

常用的反义代码

示例

• \S+ 匹配不包含空白符的字符串。
• <a[^>]+> 匹配用尖括号括起来的以a开头的字符串。

后向引用（Javascript 部分支持）

使用小括号指定一个子表达式后，匹配这个子表达式的文本(也就是此分组捕获的内容)可以在表达式或其它程序中作进一步的处理。默认情况下，每个分组会自动拥有一个组号，规则是：从左向右，以分组的左括号为标志，第一个出现的分组的组号为1，第二个为2，以此类推。

后向引用 用于重复搜索前面某个分组匹配的文本。例如，\1 代表分组1匹配的文本。难以理解？请看示例：

\b(\w+)\b\s+\1\b 可以用来匹配重复的单词，像 go go, 或者 kitty kitty。这个表达式首先是一个单词，也就是单词开始处和结束处之间的多于一个的字母或数字 (\b(\w+)\b) ，这个单词会被捕获到编号为1的分组中，然后是1个或几个空白符 (\s+)，最后是分组1中捕获的内容（也就是前面匹配的那个单词）(\1)。

你也可以自己指定子表达式的组名。要指定一个子表达式的组名，请使用这样的语法：(?<Word>\w+) (或者把尖括号换成'也行：(?'Word'\w+)) ,这样就把 \w+ 的组名指定为Word了。要反向引用这个分组捕获的内容，你可以使用\k<Word> ,所以上一个例子也可以写成这样：\b(?<Word>\w+)\b\s+\k<Word>\b。

使用小括号的时候，还有很多特定用途的语法。下面列出了最常用的一些：

• 分组0对应整个正则表达式
• 实际上组号分配过程是要从左向右扫描两遍的：
  • 第一遍只给未命名组分配，
  • 第二遍只给命名组分配－－因此所有命名组的组号- 都大于未命名的组号
• 你可以使用 (?:exp) 这样的语法来剥夺一个分组对组号分配的参与权．

零宽断言（Javascript部分支持）

接下来的四个用于查找在某些内容(但并不包括这些内容)之前或之后的东西，也就是说它们像 \b,^,$那样用于指定一个位置，这个位置应该满足一定的条件(即断言)，因此它们也被称为零宽断言。最好还是拿例子来说明吧：

断言用来声明一个应该为真的事实。正则表达式中只有当断言为真时才会继续进行匹配。

(?=exp) 也叫零宽度正预测先行断言，它断言自身出现的位置的后面能匹配表达式 exp。比如 \b\w+(?=ing\b)，匹配以ing结尾的单词的前面部分(除了ing以外的部分)，如查找I'm singing while you're dancing.时，它会匹配sing和danc。

(?<=exp) 也叫零宽度正回顾后发断言，它断言自身出现的位置的前面能匹配表达式 exp。比如 (?<=\bre)\w+\b会匹配以re开头的单词的后半部分(除了re以外的部分)，例如在查找 reading a book时，它匹配 ading。

假如你想要给一个很长的数字中每三位间加一个逗号(当然是从右边加起了)，你可以这样查找需要在前面和里面添加逗号的部分：((?<=\d)\d{3})+\b ，用它对 1234567890 进行查找时结果是 234567890。

负向零宽断言 （Javascript部分支持）

前面我们提到过怎么查找不是某个字符或不在某个字符类里的字符的方法(反义)。但是如果我们只是想要确保某个字符没有出现，但并不想去匹配它时怎么办？例如，如果我们想查找这样的单词--它里面出现了字母q,但是q后面跟的不是字母u,我们可以尝试这样：

\b\w*q[^u]\w*\b 匹配包含后面不是字母u的字母q的单词。但是如果多做测试(或者你思维足够敏锐，直接就观察出来了)，你会发现，如果q出现在单词的结尾的话，像 Iraq,Benq，这个表达式就会出错。这是因为 [^u] 总要匹配一个字符，所以如果q是单词的最后一个字符的话，后面的[^u]将会匹配q后面的单词分隔符(可能是空格，或者是句号或其它的什么)，后面的 \w*\b 将会匹配下一个单词，于是 \b\w*q[^u]\w*\b 就能匹配整个 Iraq fighting。

负向零宽断言能解决这样的问题，因为它只匹配一个位置，并不消费任何字符。 现在，我们可以这样来解决这个问题：\b\w*q(?!u)\w*\b。

零宽度负预测先行断言(?!exp)，断言此位置的后面不能匹配表达式exp。例如：\d{3}(?!\d) 匹配三位数字，而且这三位数字的后面不能是数字；\b((?!abc)\w)+\b 匹配不包含连续字符串abc的单词。

同理，我们可以用 (?<!exp),零宽度负回顾后发断言 来断言此位置的前面不能匹配表达式exp：(?<![a-z])\d{7} 匹配前面不是小写字母的七位数字。

一个更复杂的例子：(?<=<(\w+)>).*(?=<\/\1>) 匹配不包含属性的简单HTML标签内里的内容。

(?<=<(\w+)>) 指定了这样的前缀：被尖括号括起来的单词(比如可能是<b>)，然后是 .* (任意的字符串),最后是一个后缀 (?=<\/\1>)。注意后缀里的 \/，它用到了前面提过的字符转义；\1则是一个反向引用，引用的正是捕获的第一组，前面的 (\w+) 匹配的内容，这样如果前缀实际上是 <b> 的话，后缀就是 </b> 了。整个表达式匹配的是 <b> 和 </b> 之间的内容(再次提醒，不包括前缀和后缀本身)。

注释 (Javascript不支持)

小括号的另一种用途是通过语法 (?#comment) 来包含注释。例如：2[0-4]\d(?#200-249)|25[0-5](?#250-255)|[01]?\d\d?(?#0-199)。

要包含注释的话，最好是启用“忽略模式里的空白符”选项，这样在编写表达式时能任意的添加空格，Tab，换行，而实际使用时这些都将被忽略。启用这个选项后，在#后面到这一行结束的所有文本都将被当成注释忽略掉。例如，我们可以前面的一个表达式写成这样：

(?<=    # 断言要匹配的文本的前缀
<(\w+)> # 查找尖括号括起来的字母或数字(即HTML/XML标签)
)       # 前缀结束
.*      # 匹配任意文本
(?=     # 断言要匹配的文本的后缀
<\/\1>  # 查找尖括号括起来的内容：前面是一个"/"，后面是先前捕获的标签
)       # 后缀结束

贪婪与懒惰

**当正则表达式中包含能接受重复的限定符时，通常的行为是（在使整个表达式能得到匹配的前提下）匹配尽可能多的字符。**以这个表达式为例：a.*b ，它将会匹配最长的以a开始，以b结束的字符串。如果用它来搜索 aabab 的话，它会匹配整个字符串 aabab。这被称为 贪婪匹配。

有时，我们更需要 **懒惰匹配 **，也就是匹配尽可能少的字符。前面给出的限定符都可以被转化为懒惰匹配模式，只要在它后面加上一个问号 ? 。这样 .*? 就意味着匹配任意数量的重复，但是在能使整个匹配成功的前提下使用最少的重复。现在看看懒惰版的例子吧：

a.*?b 匹配最短的，以a开始，以b结束的字符串。如果把它应用于aabab的话，它会匹配aab（第一到第三个字符）和ab（第四到第五个字符）。

处理选项

平衡组/递归匹配

有时我们需要匹配像( 100 * ( 50 + 15 ) )这样的可嵌套的层次性结构，这时简单地使用 \(.+\) 则只会匹配到最左边的左括号和最右边的右括号之间的内容(这里我们讨论的是贪婪模式，懒惰模式也有下面的问题)。假如原来的字符串里的左括号和右括号出现的次数不相等，比如( 5 / ( 3 + 2 ) ) )，那我们的匹配结果里两者的个数也不会相等。有没有办法在这样的字符串里匹配到最长的，配对的括号之间的内容呢？

为了避免(和(把你的大脑彻底搞糊涂，我们还是用尖括号代替圆括号吧。现在我们的问题变成了如何把 xx <aa aa> yy这样的字符串里，最长的配对的尖括号内的内容捕获出来？
这里需要用到以下的语法构造：

• (?'group') 把捕获的内容命名为group,并压入堆栈(Stack)
• (?'-group') 从堆栈上弹出最后压入堆栈的名为group的捕获内容，如果堆栈本来为空，则本分组的匹配失败
• (?(group)yes|no) 如果堆栈上存在以名为group的捕获内容的话，继续匹配yes部分的表达式，否则继续匹配no部分
• (?!) 零宽负向先行断言，由于没有后缀表达式，试图匹配总是失败

我们需要做的是每碰到了左括号，就在压入一个"Open",每碰到一个右括号，就弹出一个，到了最后就看看堆栈是否为空－－如果不为空那就证明左括号比右括号多，那匹配就应该失败。正则表达式引擎会进行回溯(放弃最前面或最后面的一些字符)，尽量使整个表达式得到匹配。

<                         #最外层的左括号
    [^<>]*                #最外层的左括号后面的不是括号的内容
    (
        (
            (?'Open'<)    #碰到了左括号，在黑板上写一个"Open"
            [^<>]*       #匹配左括号后面的不是括号的内容
        )+
        (
            (?'-Open'>)   #碰到了右括号，擦掉一个"Open"
            [^<>]*        #匹配右括号后面不是括号的内容
        )+
    )*
    (?(Open)(?!))         #在遇到最外层的右括号前面，判断黑板上还有没有没擦掉的"Open"；如果还有，则匹配失败

>                         #最外层的右括号

平衡组的一个最常见的应用就是匹配HTML,下面这个例子可以匹配嵌套的

//Email正则
/^([A-Za-z0-9_\-\.])+\@([A-Za-z0-9_\-\.])+\.([A-Za-z]{2,4})$/.test("[email protected]");
//输出 true

// 1.邮箱以a-z、A-Z、0-9开头，最小长度为1.
// 2.如果左侧部分包含-、_、.则这些特殊符号的前面必须包一位数字或字母。
// 3.@符号是必填项
// 4.右则部分可分为两部分，第一部分为邮件提供商域名地址，第二部分为域名后缀，现已知的最短为2位。
//   最长的为6为。
// 5.邮件提供商域可以包含特殊字符-、_、.
/^[a-z0-9]+([._\\-]*[a-z0-9])*@([a-z0-9]+[-a-z0-9]*[a-z0-9]+.){1,63}[a-z0-9]+$/.test("[email protected]");

保罗·格雷厄姆出身于一个中产阶级家庭，本科就读于康奈尔大学，研究生阶段去了哈佛大学。他有一套完整的创业哲学，他的创业公式是：

1. 搭建原型
2. 上线运营
3. 搜集反馈
4. 调整产品
5. 成长壮大

他说：创始人本身比他的创意更重要。
他认为：所有的东西都在变成软件。

　　它的作者是美国互联网界举足轻重、有“创业教父”之称的哈佛大学计算机博士保罗·格雷厄姆（Paul Graham）。本书是他的文集。保罗·格雷厄姆.

　　1984年，《新闻周刊》的记者史蒂文·利维出版了历史上第一本介绍黑客的著作——《黑客：计算机革命的英雄》（Hackers: Heroes of the Computer Revolution）。在该书中，他进一步将黑客的价值观总结为六条“黑客伦理”（hacker ethic），直到今天这几条伦理都被视为这方面的最佳论述。

• (1) 使用计算机以及所有有助于了解这个世界本质的事物都不应受到任何限制。任何事情都应该亲手尝试。 　　（Access to computers—and anything that might teach you something about the way the world works—should be unlimited and total. Always yield to the Hands-On Imperative!）
• (2) 信息应该全部免费。 　　（All information should be free.）
• (3) 不信任权威，提倡去中心化。 　　（Mistrust Authority—Promote Decentralization.） 　　
• (4) 判断一名黑客的水平应该看他的技术能力，而不是看他的学历、年龄或地位等其他标准。 　　（Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race, or position.） 　　
• (5) 你可以用计算机创造美和艺术。 　　（You can create art and beauty on a computer.） 　　
• (6) 计算机使生活更美好。 　　（Computers can change your life for the better.） 　　

根据这六条“黑客伦理”，黑客价值观的核心原则可以概括成这样几点：分享、开放、**、计算机的自由使用、进步。

TODO：

简介

meta标签是HTML语言HEAD区的一个辅助性标签。

meta常用于定义页面的说明，关键字，最后修改日期，和其它的元数据。这些元数据将服务于浏览器（如何布局或重载页面），搜索引擎和其它网络服务。

mata 标签包含全局属性

Note: 全局属性name在标签里又特殊的含义，itempro属性不能和name，http-equiv和charset 属性设置在同一个meta标签。

charset

声明网页的字符编码：

<meta charset="UTF-8">

content

content属性的内容是htp-equiv或name属性的值，具体取决于你用哪一个。

http-equiv

该属性可以包含HTTP头的名称，属性的英文全称为http-equivalent。它定义了可以改变server和user-agent行为的指令。该指令的值在content属性内定义，可以是以下之一：

content-language（已过时）

定义页面的默认语言。它可以被任何元素上的lang属性所覆盖。

Pragma

禁止浏览器从本地计算机的缓存中访问页面内容。如：

＜meta http-equiv="Pragma" content="no-cache"＞

expires

可以用于设定网页的到期时间。一旦网页过期，必须到服务器上重新传输。

cache-control

指定请求和响应遵循的缓存机制。共有以下几种用法：

• no-cache: 先发送请求，与服务器确认该资源是否被更改，如果未被更改，则使用缓存。
• no-store: 不允许缓存，每次都要去服务器上，下载完整的响应。（安全措施）
• public : 缓存所有响应，但并非必须。因为max-age也可以做到相同效果
• private : 只为单个用户缓存，因此不允许任何中继进行缓存。（比如说CDN就不允许缓存private的响应）
• max-age : 表示当前请求开始，该响应在多久内能被缓存和重用，而不去服务器重新请求。例如：max-age=60表示响应可以再缓存和重用 60 秒。

content-security-policy

允许页面作者定义当前页面的内容策略。内容策略主要指定允许的服务器地址和脚本端点，这有助于防止cross-site scripting 攻击。

CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。

CSP 大大增强了网页的安全性。攻击者即使发现了漏洞，也没法注入脚本，除非还控制了一台列入了白名单的可信主机。
两种方法可以启用 CSP。一种是通过 HTTP 头信息的Content-Security-Policy的字段。

Content-Security-Policy: script-src 'self'; object-src 'none';
style-src cdn.example.org third-party.org; child-src https:

另一种是通过网页的标签。

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">

上面代码中，CSP 做了如下配置:

• 脚本：只信任当前域名
• 标签：不信任任何URL，即不加载任何资源
• 样式表：只信任cdn.example.org和third-party.org
• 框架（frame）：必须使用HTTPS协议加载
• 其他资源：没有限制

启用后，不符合 CSP 的外部资源就会被阻止加载。

更多介绍可见：Content Security Policy 入门教程

content-type（已过时）

定义文档的MIME类型，后跟其字符编码。

• 不要使用这个值，因为它已经过时了。推荐使用元素上的charset属性。
• 由于无法在XHTML或HTML5的XHTML序列化中更改文档类型，因此不要使用将MIME类型设置为XHTML MIME类型。

refresh

该指令指定：

• 如果content属性只包含一个正整数，则表示该页面重新加载的秒数。
• 如果content属性包含一个正整数，后跟字符串'; url ='，那么表示当前页面XX秒后重定向到另一个有效的URL。

<meta http-equiv="refresh" content="2；URL=http://www.github.com/"> //意思是2秒后跳转到github

set-cookie（已过时）

定义页面的cookie，对应的content值必须遵循IETF HTTP Cookie Specification

不要使用这条指令，使用HTTP头的Set-Cookie替代

X-UA-Compatible

用于告知浏览器以何种版本来渲染页面。

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"/> //指定IE和Chrome使用最新版本渲染当前页面

name

name属性的定义是属于document-level metadata，不能和以下属性同时设置： itemprop, http-equiv 或 charset。

该元数据名称与content属性包含的值相关联。 name属性的可能值为：

application-name

定义在网页中运行的应用程序的名称。

author

用于标注网页作者。

description

包括一个关于页面内容的缩略而精准的描述。一些浏览器，如Firefox和Opera，会使用这个当做网页书签的默认描述。

generator

用于标明网页是什么软件做的。

keywords

用于告诉搜索引擎，你网页的关键字

revisit-after

如果页面不是经常更新，为了减轻搜索引擎爬虫对服务器带来的压力，可以设置一个爬虫的重访时间。如果重访时间过短，爬虫将按它们定义的默认时间来访问。举例：

<meta name="revisit-after" content="7 days" >

renderer

renderer是为双核浏览器准备的，用于指定双核浏览器默认以何种方式渲染页面。比如说360浏览器。举例：

<meta name="renderer" content="webkit"> //默认webkit内核
<meta name="renderer" content="ie-comp"> //默认IE兼容模式
<meta name="renderer" content="ie-stand"> //默认IE标准模式

referrer

referrer 控制document发起的Request请求中附加的Referer HTTP header，相应的值在content中：

content	含义
no-referrer	不发送HTTP Referer头
origin	发送document的origin
no-referrer-when-downgrade	将origin作为referer发送到和当前页面同等安全的URLs（https-> https），但不会将origin发送到不安全的URLS（https-> http）。这是默认行为。
origin-when-crossorigin	same-origin的请求，发送的完整URL（剥离参数），但在其他情况下只发送origin
unsafe-URL	same-origin 或 cross-origin的请求，将发送完整的URL（剥离参数）

robots

robots用来告诉爬虫哪些页面需要索引，哪些页面不需要索引。

值	描述	Used By
index	允许robot索引本页面（默认）	All
noindex	不允许robot索引本页面	All
follow	允许搜索引擎继续通过此网页的链接索引搜索其它的网页（默认）	All
nofollow	搜索引擎不继续通过此网页的链接索引搜索其它的网页	All
none	相当于noindex，nofollow	Google
noodp	禁止使用Open Directory Project描述（如果有的话）作为搜索引擎结果中的页面描述。	Google, Yahoo, Bing
noarchive	要求搜索引擎不缓存页面内容	Google, Yahoo, Bing
nosnippet	禁止在搜索引擎结果中显示该页面的任何描述。	Google, Bing
noimageindex	要求此页面不作为引用页面的索引图像的显示。	Google
nocache	和noarchive同义	Bing

viewport

提供了关于viewport初始大小的大小的提示。仅供移动设备使用。

值	content取值	描述
width	整数或device-width	定义viewport的像素宽度，或允许viewport适应设备的屏幕宽度。
height	整数或device-height	定义viewport的高度。没有任何浏览器使用（？？？）
initial-scale	0.0 - 10.0	定义设备宽度（纵向模式下的设备宽度或横向模式下的设备高度）与viewport大小之间的比例。
maximum-scale	0.0 - 10.0	定义最大的缩放级别。它必须大于或等于minimum-scale，否则视为未定义。浏览器设置可以忽略此规则，iOS10 +默认情况下忽略它。
minimum-scale	0.0 - 10.0	定义最小的缩放级别。它必须小于或等于maximum-scale，否则视为未定义。浏览器设置可以忽略此规则，iOS10 +默认情况下忽略它。
user-scalable	yes 或 no	如果设置为no，用户将无法放大网页。默认值为yes。浏览器设置可以忽略此规则，iOS10 +默认情况下忽略它。

常见用法

禁止缩放：

<meta name=”viewport” content=”initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no”/>

自动刷新网页

你可以设置一段时间后对页面进行刷新操作。meta http-equiv=”refresh”可以指定浏览器延迟一段时间自动刷新页面。下面的meta-tag指定浏览器每5秒自动刷新一次。

<meta http-equiv=”refresh” content=”5″ />

自动重定向

我们可以使用refresh meta标签对页面进行重定向。下面的例子将在5秒后访问www.25xt.com

<meta http-equiv=”refresh” content=”5;url=’http://www.25xt.com’” />

禁止浏览器缓存

当我们在本地测试网页的时候，没有及时更新新内容，可能就是有浏览器缓存。这个时候，我们只要通过使用Meta标签禁用浏览器缓存，可以解决。通用代码如下：

<meta http-equiv="expires" content="0">
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">

禁止百度转码

 <meta http-equiv="Cache-Control" content="no-siteapp"/>

在移动开发当中，屏蔽数字当作电话号码的代码：

<meta content=”telephone=no” name=”format-detection” />

参考

MDN HTML element

简介

SSH（Secure Shell）是一个提供数据通信安全、远程登录、远程指令执行等功能的安全网络协议，由芬兰赫尔辛基大学研究员Tatu Ylönen，于1995年提出，其目的是用于替代非安全的Telnet、rsh、rexec等远程Shell协议。之后SSH发展了两个大版本SSH-1和SSH-2。

通过使用SSH，你可以把所有传输的数据进行加密，这样"中间人"这种攻击方式就不可能实现了，而且也能够防止 DNS欺骗 和 IP欺骗。使用SSH，还有一个额外的好处就是传输的数据是经过压缩的，所以可以加快传输的速度。SSH有很多功能，它既可以代替Telnet，又可以为FTP、Pop、甚至为PPP提供一个安全的"通道"。

SSH为一项创建在应用层和传输层基础上的安全协议，为计算机上的 Shell 提供安全的传输和使用环境。

SSH的基本框架

SSH协议框架中最主要的部分是三个协议：

• 传输层协议（The Transport Layer Protocol）：传输层协议提供服务器认证，数据机密性，信息完整性等的支持。
• 用户认证协议（The User Authentication Protocol）：用户认证协议为服务器提供客户端的身份鉴别。
• 连接协议（The Connection Protocol）：连接协议将加密的信息隧道复用成若干个逻辑通道，提供给更高层的应用协议使用。

SSH-AUTH是SSH里面用于验证客户端身份的协议。我们在用ssh命令输入密码的那一步实际上就是在这个阶段。可以看到的是，虽然传输的是用户名和密码，但是由于这个协议建立在SSH-TRANS之上，所以内容都是加密的，可以放心的传输。

而SSH-CONN是真正的应用协议。在这里可以定义各种不同的协议，其中我们经常使用的scp、sftp还有正常的remote shell都是定义在这里的一种协议实现。这里的各种应用协议都要首先经过SSH-AUTH的验证之后才可以使用。

这个三个协议之间的关系可以用下面这幅图来说明：

SSH的加密

SSH从安全和性能两方面综合考虑，结合使用了 Public Key/Private key（公钥/私钥） 和 Secret Key（密钥）。

• Public Key/Private key：非对称加密，安全，但效率低，不适合大规模进行数据的加密和解密操作
• Secret Key：对称机密，高效，但安全性相对较低，Key的分发尤其不方便

对密码学基础知识和数字签名了解，可以参考阮一峰的博文

• 密码学笔记
• 数字签名是什么

SSH的主要特性

• 加密：避免数据内容泄漏
• 通信的完整性：避免数据被篡改，以及发送或接受地址伪装
  （检查数据是否被篡改，数据是否来自发送者而非攻击者） SSH-2 通过 MD5 和 SHA-1 实现该功能，SSH-1 使用 CRC-32
• 认证：识别数据发送者和接收者身份 客户端验证SSH服务端的身份：防止攻击者仿冒SSH服务端身份，避免中介人攻击和重定向请求的攻击；OpenSSH 通过在 know-hosts 中存储主机名和 host key 对服务端身份进行认证 服务端验证请求者身份：提供安全性较弱的用户密码方式，和安全性更强的 per-user public-key signatures；此外SSH还支持与第三方安全服务系统的集成，如 Kerberos等
• 授权：用户访问控制
• Forwarding or tunneling to encrypt other TCP/IP-based sessions 可以通过SSH为Telnet、FTP等提供通信安全保障，支持三种类型的 Forwarding 操作：Port Forwarding；X Forwarding；Agent Forwarding

SSH中的Key

SSH结合使用了Public Key/Private key和Secret Key：

• Public Key/Private key（非对称加密）用于在建立安全通道前在客户端和服务端之间传输 Secret Key和进行身份认证；
• Secret Key（对称加密）则用来作为SSH会话的安全保证，对数据进行加密和解密。

SSH可以处理4种密钥：

SSH框架：

安全连接的建立

在进行有意义的会话之前，SSH客户端和服务器必须首先建立一条安全连接。该连接可以允许双方共享密钥、密码，最后可以相互传输任何数据。

现在我们介绍SSH-1协议是如何确保网络连接的安全性的。SSH-1客户端和服务器从阿卡似乎经过很多个步骤，协商使用加密算法，生成并共享一个会话密钥，最终建立一条安全连接：

1. 客户端连接到服务器上
2. 客户端和服务器交换自己支持的SSH协议版本号
3. 客户端和服务器切换到基于报文的协议
4. 服务器向客户端提供自己的身份证明和会话参数
5. 客户端给服务器发送一个（会话）密钥
6. 双方启用加密并完成服务器认证
7. 建立安全连接

每个阶段均涉及到客户端与服务端的多次交互，通过这些交互过程完成包括证书传输、算法协商、通道加密等过程。

1 客户端连接到服务器上

这个步骤没什么好说的，就是向服务器的TCP端口（约定是22）发送连接请求。

2 客户端和服务器交换自己支持的协议版本号

这些协议是以 ASCII 字符串表示，例如：SSH-1.5-1.2.27，其意义为SSH协议，版本号是V1.5，SSH1实现版本为1.2.27。可以使用 Telnet 客户端连接到一个SSH服务器端口是看到这个字符串：

➜ telnet 192.168.1.200 22
Trying 192.168.1.200...
Connected to doc.dinghuo123.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u6

如果客户端和服务器确定其协议版本号是兼容的，那么连按就继续进行，否则，双方都可能决定中断连接。例如，如果一个只使用 SSH-1 的客户端连接到一个只使用 SSH-2 的服务器上，那么客户端就会断开连接并打印一条错误消息。实际上还可能执行其他操作：例如，只使用SSH-2的服务器可以调用SSH-1服务器来处理这次连接请求。

3 客户端和服务器切换基于报文的协议

协议版本号交换过程一旦完成，客户端和服务器都立即从下层的 TCP 连接切换到基于子报文的协议。每个报文都包含一个32位的字段，1 - 8字节的填充位[ 用来防止已知明文攻击unknown-plaintext attack ]，一个1字节的报文类型代码, 报文有效数据和一个4字节的完整性检査字段。

4 服务器向客户提洪自己的身份证明和会话参数

服务器向客户端发送以下信息(现在还沒有加密):

• 主机密钥（Host Key），用于后面证明服务器主机的身份
• 服务器密钥（Server Key），用来帮助建立安全连接
• 8个随机字节序列，称为检测字节（check bytes)。客户端在下一次响应中必须包括这些检测字节，否則服务器就会拒绝接收响应信息，这种方法可以防止某些 IP伪装攻击(IP spoofing attack)。
• 该服务器支持的加密、压缩和认证方法

此时，双方都要计算一个通用的 128 位会话标识符(Session ID)。它在某些协议中用来惟一标识这个 SSH 会话。该值是 主机密钥（Host Key）、服务器密钥（Server Key）和检测字节（check bytes)一起应用 MD5散列函数 得到的结果。

当客户端接收到 主机密钥（Host Key）时，它要进行询问：“之前我和这个服务器通信过吗？如果通信过，那么它的主机密钥是什么呢？”要回答这个问题，客户端就要査阅自己的已知名主机数据库。如果新近到达的主机密钥可以和数据库中以前的一个密钥匹，那么就没有问题了。

但是，此时还存在两种可能：已知名主机数据库中没有这个服务器，也可能有这个服务器但是其主机密钥不同。在这两种情况中，客户端要选择是信任这个新近到达的密钥还是拒绝接受该密钥。此时就需要人的指导参与了，例如，客户端用户可能被提示要求确定是接受还是拒绝该密钥。

The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?

如果客户端拒绝接受这个主机密钥，那么连接就中止了。让我们假设客户端接受该密钥，现在继续介绍。

5 客户端给眼务器发送一个(会话)密钥

现在客户端为双方都支持的 bulk箅法 随机生成一个新密钥，称为 会话密钥（Session Key）。其目的是对客户端和服务器之间发送的数据进行加密和解密。所需要做的工作是把这个 会话密钥（Session Key）发送给服务器，双方就可以启用加密并开始安全通信了。

当然，客户端不能简单地把会话密钥（Session Key）发送给服务器。此时数据还没有进行加密，如果第三方中途截获了这个密钥，那么他就可以解密客户端和服务器之间的消息。此后你就和安全性无缘了。因此客户端必须安全地发送会话密钥（Session Key）。 这是通过两次加密实现的：一次使用服务器的公共主机密钥（Host Key），一次使用服务器密钥（Server Key）。

这个步骤确保只有服务器可以读取会话密钥（Session Key）。在会话密钥（Session Key）经过两次加密之后，客户端就将其发送给服务器，同时还会发送检测字节和所选定的算法(这些算法是从第4步中服务器支持的算法列表中挑选出来的）。

6 双方启用加密并完成服务器认证

在发送会话密钥之后，双方开始使用密钥和所选定的 bulk算法 对会话数据进行加密，但是在开始继续发送其他数据之前，客户端要等待服务器发来一个确认消息，该消息（以及之后的所有数据）都必须使用这个会话密钥（Session Key）加密。这是最后一歩，它提供了服务器认证：只有目的服务器才可以解密 会话密钥（Session Key），因为它是使用前面的 主机密钥（Host Key）（这个密钥已经对已知名主机列表进行了验证）进行加密的。

如果没有会话密钥（Session Key），假冒的服务器就不能解密以后的协议通信，也就不能生成有效的通信，客户端会注意到这一点并中断连接。

注意服务器认址是隐含的；并没有显式交换来验证服务器主机密钥（Host Key）。因此客户端在继续发送数椐之前，必须等待服务器使用新会话密钥（Session Key）作出有意义的响应。 从而在处理之前验证服务的身份，虽然 SSH-1 协议在这点上并没有什么特殊 . 但是 SSH-2 需要服务器认证时显示地地交换会话密钥（Session Key）。

使用服务器密钥（Server Key）对会话密钥（Session Key）再进行一次加密就提供了一种称为完美转发安全性的特性。这就是说不存在永久性密钥泄露的可能，因为它不会危害到其他部分和以后SSH会话的安全性。如果我们只使用服务器主机密钥（Host Key）来保护会话密钥（Session Key）， 那么主机密钥（Host Key）的泄露就会危害到以后的通倍，并允许解密原来记录下来的会话。使用服务器密钥（Server Key）再加密次就消除了这种缺点，因为服务器密钥（Server Key）是临时的，它不会保存到磁盘上，而且会周期性地更新（缺省情况下，一小时更新一次)。如果一个入侵者已经获取了服务器的私钥，那么他必须还要执行中间人攻击或服务器欺骗攻击才能对会话造成损害。

7 建立安全连接

由于客户端和服务器现在都知道会话密钥（Session Key），而其他人都不知道，因此他们就可以相互发送加密消息(使用他们一致同意的 bulk算法 )并对其进行解密了。而且，客户端还可以完成服务器认证。我们现在就已经准备好开始客户端认证了。

客户端认证

SSH提供多种客户端认证方式。

SSH-1：

• Password
• Public Key
• Kerberos
• Rhosts && RhostsRSA
• TIS

SSH-2：

• Password
• Public Key
• hostbased 在SSH-2中考虑 Rhosts 存在安全漏洞，废弃了这种方式。

这里之讨论我们经常使用的的 Password 和 Public Key 方式。

此时安全通道已经及建立，之后的所有内容都通过 Session Key 加密后进行传输。

Password

Password 方式既客户端提供用户和密码，服务端对用户和密码进行匹配，完成认证。类Unix系统中，如 OpenSSH 的框架，一般通过系统的本地接口完成认证。

Password 的优势是简单，无需任何而外的配置就可以使用。缺点密码不便于记忆，过于简单的密码容易被暴力破解。

Public Key

Public Key 认证的基本原理是基于非对称加密方式，分别在服务端对一段数据通过公钥进行加密，如果客户端能够证明其可以使用私钥对这段数据进行解密，则可以说明客户端的身份。因为服务端需要使用客户端生成的密钥对的公钥对数据首先加密，所以需要先将公钥存储到服务端的密钥库（Auhtorized Key）。还记得Github中使用git协议push代码前需要先添加SSH KEY吗？

下面详细介绍一个通过 Public Key 进行客户端认证的过程。

1. 客户端发起一个 Public Key 的认证请求，并发送 RSA Key 的模数作为标识符。（如果想深入了解RSA Key详细 --> 维基百科）
2. 服务端检查是否存在请求帐号的公钥（Linux中存储在 ~/.ssh/authorized_keys 文件中），以及其拥有的访问权限。如果没有则断开连接
3. 服务端使用对应的公钥对一个随机的256位的字符串进行加密，并发送给客户端
4. 客户端使用私钥对字符串进行解密，并将其结合 Session ID 生成一个MD5值发送给服务端。 结合 Session ID 的目的是为了避免攻击者采用 重放攻击（replay attack）。
5. 服务端采用同样的方式生成 MD5值 与客户端返回的 MD5值 进行比较，完成对客户端的认证。

图解SSH

参考

• SSH原理简介
• SSH协议介绍
• O‘RELLY的《SSH: The Secure Shell - The Definitive Guide》

文章同步于Github Pines-Cheng/blog

什么是CDN

CDN（内容分发网络）全称是 Content Delivery Network，建立并覆盖在承载网之上、由分布在不同区域的边缘节点服务器群组成的分布式网络，替代传统以 WEB Server 为中心的数据传输模式。

作用是将源内容发布到边缘节点，配合精准的调度系统；将用户的请求分配至最适合他的节点，使用户可以以最快的速度取得他所需的内容，有效解决Internet网络拥塞状况，提高用户访问的响应速度。

CDN的基本工作过程

用户通过浏览器等方式访问网站的过程如图所示：

1. 用户在自己的浏览器中输入要访问的网站域名。

2. 浏览器向 本地DNS服务器 请求对该域名的解析。

3. 本地DNS服务器中如果缓存有这个域名的解析结果，则直接响应用户的解析请求。

4. 本地DNS服务器中如果没有关于这个域名的解析结果的缓存，则以递归方式向整个DNS系统请求解析，获得应答后将结果反馈给浏览器。

5. 浏览器得到域名解析结果，就是该域名相应的服务设备的 IP地址 。

6. 浏览器向服务器请求内容。

7. 服务器将用户请求内容传送给浏览器。

在网站和用户之间加入 CDN 以后，用户不会有任何与原来不同的感觉。最简单的 CDN 网络有一个 DNS 服务器和几台缓存服务器就可以运行了。一个典型的 CDN 用户访问调度流程如图所示:

1. 当用户点击网站页面上的内容URL，经过本地DNS系统解析，DNS 系统会最终将域名的解析权交给 CNAME 指向的 CDN 专用 DNS 服务器。

2. CDN 的 DNS 服务器将 CDN 的全局负载均衡设备 IP 地址返回用户。

3. 用户向 CDN 的全局负载均衡设备发起内容 URL 访问请求。

4. CDN 全局负载均衡设备根据用户 IP 地址，以及用户请求的内容URL，选择一台用户所属区域的区域负载均衡设备，告诉用户向这台设备发起请求。

5. 基于以下这些条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址：

   • 根据用户 IP 地址，判断哪一台服务器距用户最近；
   • 根据用户所请求的 URL 中携带的内容名称，判断哪一台服务器上有用户所需内容；
   • 查询各个服务器当前的负载情况，判断哪一台服务器尚有服务能力。

6. 全局负载均衡设备把服务器的 IP 地址返回给用户。

7. 用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容传送到用户终端。如果这台缓存服务器上并没有用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器就要向它的上一级缓存服务器请求内容，直至追溯到网站的源服务器将内容拉到本地。

**DNS 服务器根据用户 IP 地址，将域名解析成相应节点的缓存服务器IP地址，实现用户就近访问。**使用 CDN 服务的网站，只需将其域名解析权交给 CDN 的全局负载均衡（GSLB）设备，将需要分发的内容注入 CDN，就可以实现内容加速了。

使用CDN后的http请求处理流程如下图，其中左边为DNS解析过程，右边为内容访问过程：

CDN的功能架构

CDN基于这样的原理：

1. 挑选最优设备为用户提供服务；
2. 如果某个内容被很多用户所需要，它就被缓存到距离用户最近的节点中。

CDN 公司在整个互联网上部署数以百计的CDN服务器（Cache），这些服务器通常在运营商的 IDC (互联网数据中心Internet Data Center）中，尽量靠近接入网络和用户。CDN在Cache中复制内容，当内容的提供者更新内容时，CDN 向Cache重新分发这些被刷新的内容。CDN提供一种机制，当用户请求内容时，该内容能够由以最快速度交付的Cache 来向用户提供，这个挑选"最优"的过程就叫做负载均衡。被选中的最优 Cache 可能最靠近用户，或者有一条与用户之间条件最好的路径。

从功能上划分，典型的 CDN 系统架构由分发服务系统、负载均衡系统和运营管理系统三大部分组成，如图所示：

分发服务系统

该系统的主要作用是实现将内容从内容源中心向边缘的推送和存储，承担实际的内容数据流的全网分发工作和面向最终用户的数据请求服务。分发服务系统最基本的工作单元就是许许多多的 Cache设备（缓存服务器），Cache 负责直接响应最终用户的访问请求，把缓存在本地的内容快速地提供给用户。同时 Cache 还负责与源站点进行内容同步，把更新的内容以及本地没有的内容从源站点获取并保存在本地。

一般来说，根据承载内容类型和服务种类的不同，分发服务系统会分为多个子服务系统，如网页加速子系统、流媒体加速子系统、应用加速子系统等。每个子服务系统都是一个分布式服务集群，由一群功能近似的、在地理位置上分布部署的 Cache 或 Cache 集群组成，彼此间相互独立。每个子服务系统设备集群的数量根据业务发展和市场需要的不同，少则几十台，多则可达上万台，对外形成一个整体，共同承担分发服务工作。Cache 设备的数量、规模、总服务能力是衡量一个 CDN 系统服务能力的最基本的指标。

分发服务系统在承担内容的更新、同步和响应用户需求的同时，还需要向上层的调度控制系统提供每个Cache设备的健康状况信息、响应情况，有时还需要提供内容分布信息，以便调度控制系统根据设定的策略决定由哪个Cache（组）来响应用户的请求最优。

负载均衡系统

负载均衡系统是一个 CDN 系统的神经中枢，主要功能是负责对所有发起服务请求的用户进行访问调度，确定提供给用户的最终实际访问地址。大多数 CDN 系统的负载均衡系统是分级实现的，这里以最基本的两级调度体系进行简要说明。一般而言，两级调度体系分为全局负载均衡（GSLB）和本地负载均衡（SLB）。

其中，全局负载均衡（GSLB）主要根据 用户就近性原则，通过对每个服务节点进行"最优"判断，确定向用户提供服务的 Cache 的物理位置。最通用的 GSLB 实现方法是基于DNS解析的方式实现，也有一些系统采用了应用层重定向等方式来解决。本地负载均衡（SLB）主要负责节点内部的设备负载均衡，当用户请求从 GSLB 调度到 SLB 时，SLB 会根据节点内各 Cache 设备的实际能力或内容分布等因素对用户进行重定向，常用的本地负载均衡方法有基于4层调度、基于7层调度、链路负载调度等。

运营管理系统

CDN的运营管理系统与一般的电信运营管理系统类似，分为运营管理和网络管理两个子系统。

运营管理子系统是CDN系统的业务管理功能实体，负责处理业务层面的与外界系统交互所必需的一些收集、整理、交付工作，包含客户管理、产品管理、计费管理、统计分析等功能。

网络管理子系统实现对CDN系统的网络设备管理、拓扑管理、链路监控和故障管理，为管理员提供对全网资源进行集中化管理操作的界面，通常是基于Web方式实现的。

CDN的部署架构

CDN 系统设计的首要目标是尽量减少用户的访问响应时间，为达到这一目标，CDN 系统应该尽量将用户所需要的内容存放在距离用户最近的位置。也就是说，负责为用户提供内容服务的 Cache 设备应部署在物理上的网络边缘位置，我们称这一层为CDN边缘层。CDN 系统中负责全局性管理和控制的设备组成 中心层，中心层同时保存着最多的内容副本，当边缘层设备未命中时，会向中心层请求，如果在中心层仍未命中，则需要中心层向源站回源。

不同CDN系统设计之间存在差异，中心层可能具备用户服务能力，也可能不直接提供服务，只向下级节点提供内容。如果CDN网络规模较大，边缘层设备直接向中心层请求内容或服务会造成中心层设备压力过大，就要考虑在边缘层和中心层之间部署一个区域层，负责一个区域的管理和控制，也保存部分内容副本供边缘层访问。

如图是一个典型的CDN系统三级部署示意图:

节点是 CDN 系统中最基本的部署单元，一个CDN系统由大量的、地理位置上分散的 POP（point-of-presence）节点组成，为用户提供就近的内容访问服务。

CDN 节点网络主要包含 CDN 骨干点和 POP 点。CDN 骨干点和 CDN POP 点在功能上不同。

• 中心和区域节点一般称为骨干点，主要作为内容分发和边缘未命中时的服务点；
• 边缘节点又被称为POP（point-of-presence）节点，CDN POP点主要作为直接向用户提供服务的节点。

但是，从节点构成上来说，无论是CDN骨干点还是CDN POP点，都由Cache设备和本地负载均衡设备构成。

在一个节点中，Cache设备和本地负载均衡设备的连接方式有两种：一种是旁路方式，一种是穿越方式。

如图所示：

在穿越方式下，SLB（Server Load Balancer，负载均衡 一般由 L4-7 交换机实现，SLB 向外提供可访问的 公网IP地址（VIP，每台Cache仅分配私网IP地址，该台SLB下挂的所有Cache构成一个服务组。所有用户请求和媒体流都经过该SLB设备，再由SLB设备进行向上向下转发。SLB实际上承担了 NAT（Network Address Translation，网络地址转换）功能，向用户屏蔽了Cache设备的IP地址。这种方式是CDN系统中应用较多的方式，优点是具有较高的安全性和可靠性，缺点是L4-7交换机通常较为昂贵。另外，当节点容量大时，L4-7交换机容易形成性能瓶颈。不过近年来，随着 LVS (Linux Virtual Server，即Linux虚拟服务器) 等技术的兴起，SLB设备价格有了大幅下降。

在旁路方式下，有两种 SLB 实现方式：

• 在早期，这种 SLB 一般由软件实现。SLB 和 Cache 设备都具有公共的IP地址，SLB 和 Cache 构成并联关系。用户需要先访问 SLB 设备，然后再以重定向的方式访问特定的 Cache。这种实现方式简单灵活，扩展性好，缺点是安全性较差，而且需要依赖于应用层重定向。
• 随着技术的发展，L4-7 交换机也可采用旁路部署（负载均衡硬件设备的部署）方式，旁挂在路由交换设备上，数据流量通过三角传输方式进行。

在CDN系统中，不仅分发服务系统和调度控制系统是分布式部署的，运营管理系统也是分级分布式部署的，每个节点都是运营管理数据的生成点和采集点，通过日志和网管代理等方式上报数据。可以说，CDN本身就是一个大型的具有**控制能力的分布式服务系统。

为什么需要CDN

当下的互联网应用都包含大量的静态内容，但静态内容以及一些准动态内容又是最耗费带宽的，特别是针对全国甚至全世界的大型网站，如果这些请求都指向主站的服务器的话，不仅是主站服务器受不了，单端口500M左右的带宽也扛不住，所以大多数网站都需要CDN服务。

根本上的原因是，访问速度对互联网应用的用户体验、口碑、甚至说直接的营收都有巨大的影响，任何的企业都渴望自己站点有更快的访问速度。而HTTP传输时延对web的访问速度的影响很大，在绝大多数情况下是起决定性作用的，这是由TCP/IP协议的一些特点决定的。物理层上的原因是光速有限、信道有限，协议上的原因有丢包、慢启动、拥塞控制等。

这就是你使用CDN的第一个也是最重要的原因：为了加速网站的访问。

除了加速网站的访问之外，CDN还有一些作用：

• 为了实现跨运营商、跨地域的全网覆盖

互联不互通、区域ISP地域局限、出口带宽受限制等种种因素都造成了网站的区域性无法访问。CDN加速可以覆盖全球的线路，通过和运营商合作，部署IDC资源，在全国骨干节点商，合理部署CDN边缘分发存储节点，充分利用带宽资源，平衡源站流量。阿里云在国内有500+节点，海外300+节点，覆盖主流国家和地区不是问题，可以确保CDN服务的稳定和快速。

• 为了保障你的网站安全

CDN的负载均衡和分布式存储技术，可以加强网站的可靠性，相当无无形中给你的网站添加了一把保护伞，应对绝大部分的互联网攻击事件。防攻击系统也能避免网站遭到恶意攻击。

• 为了异地备援

当某个服务器发生意外故障时，系统将会调用其他临近的健康服务器节点进行服务，进而提供接近100%的可靠性，这就让你的网站可以做到永不宕机。

• 为了节约成本

投入使用CDN加速可以实现网站的全国铺设，你根据不用考虑购买服务器与后续的托管运维，服务器之间镜像同步，也不用为了管理维护技术人员而烦恼，节省了人力、精力和财力。

• 为了让你更专注业务本身

CDN加速厂商一般都会提供一站式服务，业务不仅限于CDN，还有配套的云存储、大数据服务、视频云服务等，而且一般会提供7x24运维监控支持，保证网络随时畅通，你可以放心使用。并且将更多的精力投入到发展自身的核心业务之上。

适用场景

网站站点/应用加速

站点或者应用中大量静态资源的加速分发，建议将站点内容进行动静分离，动态文件可以结合云服务器ECS，静态资源如各类型图片、html、css、js文件等，建议结合 对象存储OSS 存储海量静态资源，可以有效加速内容加载速度，轻松搞定网站图片、短视频等内容分发。

视音频点播/大文件下载分发加速

支持各类文件的下载、分发，支持在线点播加速业务，如mp4、flv视频文件或者平均单个文件大小在20M以上，主要的业务场景是视音频点播、大文件下载（如安装包下载）等，建议搭配对象存储OSS使用，可提升回源速度，节约近2/3回源带宽成本。

视频直播加速

视频流媒体直播服务，支持媒资存储、切片转码、访问鉴权、内容分发加速一体化解决方案。结合弹性伸缩服务，及时调整服务器带宽，应对突发访问流量；结合媒体转码服务，享受高速稳定的并行转码，且任务规模无缝扩展。

移动应用加速

移动APP更新文件（apk文件）分发，移动APP内图片、页面、短视频、UGC等内容的优化加速分发。提供httpDNS服务，避免DNS劫持并获得实时精确的DNS解析结果，有效缩短用户访问时间，提升用户体验。

其他

流量劫持

其实，CDN本身就是一种DNS劫持，只不过是良性的。 不同于黑客强制DNS把域名解析到自己的钓鱼IP上，CDN则是让DNS主动配合，把域名解析到临近的服务器上。

劫持通常分为两类：

1. 域名劫持，又称DNS劫持，通常是指域名指向到非正常IP（恶意IP），该恶意IP通过反向代理的方式，在能返回网页正常内容的情况，可能插入恶意代码、监听网民访问、劫持敏感信息等操作。通常验证一个域名是否被劫持的方法是PING一个域名，如果发现PING出来的IP不是您的服务器真实IP，则可以确定被劫持了（当然如果使用了知道创宇云安全等安全加速平台，得到的IP为平台IP，并非劫持）

2. 数据劫持，通常由电信运营商中某些员工等勾结犯罪分子，在公网中进行数据支持，插入，此类情况极隐蔽，不会改变用户域名解析IP，而是直接数据流经运营商宽带时在网页中挺入内容，此类情况，建议网页启用HTTPS加密，可以解决这一问题（通信是加密的，运营商无法插入恶意内容）

某运营商对新浪首页的广告强制插入：

如果使用CDN服务时，当源站向CDN返回被劫持的内容时，此时CDN将获取到的并不是正确的网页内容（而是经运营商篡改强制植入广告的页面），此时可能导致该内容在CDN中长时间缓存，发现这种问题，可以清理CDN缓存后，一般即可恢复正常。

遇到劫持现象，可以向工信部投诉：http://www.chinatcc.gov.cn:8080/cms/shensus/

可参考：

• 互联网黑势力之流量劫持
• 流量劫持是如何产生的？

CDN缓存

CDN边缘节点缓存策略因服务商不同而不同，但一般都会遵循http标准协议，通过http响应头中的 Cache-control: max-age的字段来设置CDN边缘节点数据缓存时间。

当客户端向CDN节点请求数据时，CDN节点会判断缓存数据是否过期，若缓存数据并没有过期，则直接将缓存数据返回给客户端；否则，CDN节点就会向源站发出回源请求（back to the source request），从源站拉取最新数据，更新本地缓存，并将最新数据返回给客户端。

CDN服务商一般会提供基于文件后缀、目录多个维度来指定CDN缓存时间，为用户提供更精细化的缓存管理。

CDN缓存时间会对回源率产生直接的影响。若CDN缓存时间较短，CDN边缘节点上的数据会经常失效，导致频繁回源，增加了源站的负载，同时也增大的访问延时；若CDN缓存时间太长，会带来数据更新时间慢的问题。开发者需要增对特定的业务，来做特定的数据缓存时间管理。

CDN边缘节点对开发者是透明的，相比于浏览器 Ctrl+F5 的强制刷新来使浏览器本地缓存失效，开发者可以通过CDN服务商提供的“刷新缓存”接口来达到清理CDN边缘节点缓存的目的。这样开发者在更新数据后，可以使用 刷新缓存 功能来强制CDN节点上的数据缓存过期，保证客户端在访问时，拉取到最新的数据。

可参考：

• 清除静态cdn缓存的研究

深入研究

• 阿里基于Nginx开发的高性能HTTP服务器，已经开源，详细请了解 The Tengine Web Server

参考

• CDN技术详解

和其他许多编程语言一样，JavaScript使用分号(;)将语句分隔 开。这对增强代码的可读性和整洁性是非常重要的：缺少分隔符，一条语句的结束 就成了下一条语句的开始，反之亦然。在JavaScript中，如果语句各自独占一行，通 常可以省略语句之间的分号(程序结尾或右花括号“}”之前的分号也可以省略)。

许多JavaScript程序员(包括本书中的示例代码)使用分号来明确标记语句的结束， 即使在并不完全需要分号的时候也是如此。另一种风格就是，在任何可以省略分号 的地方都将其省略，只有在不得不用的时候才使用分号。不管采用哪种编程风格， 关于JavaScript中可选分号的问题有几个细节需要注意。

考虑如下代码，因为两条语句用两行书写，第一个分号是可以省略掉的:

a=3; 
b=4;

如果按照如下格式书写，第一个分号则不能省略掉:

a=3;b=4;

需要注意的是，JavaScript并不是在所有换行处都填补分号：只有在缺少了分号 就无法正确解析代码的时候，JavaScript才会填补分号。 换句话讲（类似下面代码中的两处异常），如果当前语句和随后的非空格字符不能当成一个整体来解析的话， JavaScript就在当前语句行结束处填补分号。看一下如下代码:

var a
a
=
3 console.log(a)

JavaScript将其解析为:

var a;a=3;console.log(a);

JavaScript给第一行换行处添加了分号，因为如果没有分号，JavaScript就无法解析代码 var a a。第二个a可以单独当做一条语句“a;”，但JavaScript并没有给第二行结 尾填补分号，因为它可以和第三行内容一起解析成 “a=3;”。

这些语句的分隔规则会导致一些意想不到的情形，这段代码写成了两行，看起来是两条独立的语句:

var y=x+f 
(a+b).toString()

但第二行的圆括号却和第一行的f组成了一个函数调用，JavaScript会把这段代 码看做:

var y=x+f(a+b).toString();

而这段代码的本意并不是这样。为了能让上述代码解析为两条不同的语句，必须手动填写行尾的显式分号。

通常来讲，如果一条语句以“(”、“[”、“/”、“+”或“-”开始，那么它极有可能和前一条语句合在一起解析。

以“/”、“+”和“-”开始的语句并不常见，而以“(”和“[”开始的 语句则非常常见，至少在一些JavaScript编码风格中是很普遍的。有些程序员喜欢保守地在语句前加上一个分号（有些代码合并工具也是这么干的），这样哪怕之前的语句被修改了、分号被误删除了，当 前语句还是会正确地解析:

var x=0//这里省略了分号 
;[x，x+1，x+2].forEach(console.log)//前面的分号保证了正确地语句解析

如果当前语句和下一行语句无法合并解析，JavaScript则在第一行后填补分号， 这是通用规则，但有两个例外。第一个例外是在涉及 return、break 和 continue 语句的场景中。如果这三个关键字后紧跟着换行，JavaScript则会在换行 处填补分号。例如，这段代码:

return 
true;

JavaScript会解析成:

return;true;

而代码的本意是这样:

return true;

也就是说，在 return、break 和 continue 和随后的表达式之间不能有换行。如果添加了换行，程序则只有在极特殊的情况下才会报错，而且程序的调试非常不方便。

第二个例外是在涉及“++”和“——”运算符的时候。这些运算符可以 作为表达式的前缀，也可以当做表达式的后缀。如果将其用做后缀表达式，它和表 达式应当在同一行。否则，行尾将填补分号，同时“++”或“——”将会作为下一行代 码的前缀操作符并与之一起解析，例如，这段代码:

x 
++ 
y

这段代码将解析为“x;++y”，而不是“x++;y”。

在实际的工作中，我们可能还有些疑惑，当有多个选择器作用在一个元素上时，哪个规则最终会应用到元素上？其实这是通过层叠机制来控制的，这也和样式继承(元素从其父元素那里获得属性值)有关。

层叠

CSS 是 Cascading Style Sheets 的缩写，这暗示层叠（cascade）的概念是很重要的。在最基本的层面上，它表明CSS规则的顺序很重要，但它比那更复杂。什么选择器在层叠中胜出取决于三个因素（这些都是按重量级顺序排列的——前面的的一种会否决后一种）：

• 重要性（Importance）
• 特殊性（Specificity）也有译为 优先级
• 源代码次序（Source order）

重要性

!important

在CSS中，有一个特别的语法可以让一条规则总是优先于其他规则：!important。把它加在属性值的后面可以使这条声明有无比强大的力量。

注意: 重载这个 !important 声明的唯一方法是在后面的源码或者是一个拥有更高特殊性的源码中包含相同的 !important 特性的声明。

知道 !important存在是很有用的，这样当你在别人的代码中遇到它时，你就知道它是什么了。但是！我们建议你千万不要使用它，除非你绝对必须使用它。您可能不得不使用它的一种情况是，当您在CMS中工作时，您不能编辑核心的CSS模块，并且您确实想要重写一种不能以其他方式覆盖的样式。 但是，如果你能避免的话，不要使用它。由于 !important 改变了层叠正常工作的方式，因此调试CSS问题，尤其是在大型样式表中，会变得非常困难。

样式表来源

要注意一个CSS声明的重要性取决于它被指定在什么样式表内——用户可以设置自定义样式表覆盖开发商的样式，例如用户可能有视力障碍，想设置字体大小对所有网页的访问是双倍的正常大小，以便更容易阅读。

相互冲突的声明将按以下顺序适用，后一种将覆盖先前的声明：

• 在用户代理样式表的声明 (例如：浏览器在没有其他声明的默认样式).
• 用户样式表中的普通声明（由用户设置的自定义样式）。
• 作者样式表中的普通声明（这是我们设置的样式，Web开发人员）。
• 作者样式表中的重要声明
• 用户样式表中的重要声明(优先级最高)

Web开发者的样式表覆盖用户的样式表是合理的，所以设计可以保持预期，但是有时候用户有很好的理由来重写web开发人员样式，如上所述，这可以通过在用户的规则中使用 !important。

特殊性

特殊性基本上是衡量选择器的具体程度的一种方法——它能匹配多少元素。如上面所示的示例所示，元素选择器具有很低的特殊性。类选择器具有更高特殊性，所以将战胜元素选择器。ID选择器有甚至更高的专用性, 所以将战胜类选择器。

一个选择器具有的专用性的量是用四种不同的值（或组件）来衡量的，它们可以被认为是千位，百位，十位和个位——在四个列中的四个简单数字：

• 千位：如果声明是在 style 属性中该列加1分（这样的声明没有选择器，所以它们的专用性总是1000。）否则为0。
• 百位：在整个选择器中每包含一个 ID选择器就 在该列中加1分。
• 十位：在整个选择器中每包含一个 类选择器、属性选择器、或者 伪类 就在该列中加1分。
• 个位：在整个选择器中每包含一个 元素选择器 或 伪元素 就在该列中加1分。

注意: 通用选择器 (*), 复合选择器 (+, >, ~, ' ') 和否定伪类 (:not) 在专用性中无影响。

示例

注意: 如果多个选择器具有相同的重要性和专用性，则选择哪一个选择器取决于 Source order（源代码次序）。

源代码次序（Source order）

如果多个相互竞争的选择器具有相同的重要性和专用性，那么第三个因素将帮助决定哪一个规则获胜——后面的规则将战胜先前的规则。

继承

CSS继承是我们需要研究的最后一部分，以获取所有信息并了解什么样式应用于元素。其**是，应用于某个元素的一些属性值将由该元素的子元素继承，而有些则不会。

哪些属性默认被继承哪些不被继承大部分符合常识。如果你想确定，你可以 参考CSS参考资料—— 每个单独的属性页都会从一个汇总表开始，其中包含有关该元素的各种详细信息，包括是否被继承。

继承属性是CSS最基本的内容之一，一般不会特别考虑，但是还是要记住的是：

• 大部分框模型属性（如border）不会继承。
• 继承没有特殊性，且低于0,0,0,0 如 * {color: red;}

控制继承

CSS为处理继承提供了三种特殊的通用属性值：

• inherit： 该值将应用到选定元素的属性值设置为与其父元素一样。
• initial ：该值将应用到选定元素的属性值设置为与浏览器默认样式表中该元素设置的值一样。如果浏览器默认样式表中没有设置值，并且该属性是自然继承的，那么该属性值就被设置为 inherit。
• unset ：该值将属性重置为其自然值，即如果属性是自然继承的，那么它就表现得像 inherit，否则就是表现得像 initial。

总结

层叠样式表这个名字很贴切。 CSS所采用的方法就是让样式层叠在一起，这是通过结合继承和特殊性做到的•。CSS2.1 的层叠规则相当简单。

1. 找出所有相关的规则，这些规则都包含与一个给定元素匹配的选择器。
2. 按显式权重对应用到该元素的所有声明排序。标志 !important 的规则的权重要高于没有 !important 标志的规则。按来源对应用到给定元素的所有声明排序。共有3种来源：创作人员、读者和用户代理。正常情况下，创作人员的样式要胜过读者的样式。有 !important 标志的读者样式要强于所有其他样式，这包括有 !important 标志的创作人员样式。创作人员样式和读者样式都比用户代理的默认样式要强。
3. 按特殊性对应用到给定元素的所有声明排序，有较高特殊性的元素权重大于有较低特殊性的元素.
4. 按出现的序对应用到给定元素的所和声明排序。一个声明在样式表或文档中越后出现，它的权重越大，如果样式表中有导入的样式表，一般认为出现在导入样式表中的声明在前，主样式表中的所有声明在后。

参考

• 《CSS 权威指南》
• MDN web docs

需求

公司出于自身隐私保护需要,不想把自己的代码开源到包管理区，但是又急需一套完整包管工具，来管理越来越多的组件、模块和项目。对于前端，最熟悉的莫过于npm，bower等；但是bower的市场兼容性明显没有npm强壮，加之commonjs规范的日益成熟。npm应该是前端包管理的不二选择。

公司对于搭建本地私有npm库有如下要求：

1. 私有包托管在内部服务器中
2. 项目中使用了公共仓库上的公共包，也使用了内部服务器上的私有包
3. 希望下载的时候，公共包走公共仓库，私有包走内部服务器的私有仓库
4. 服务器硬盘有限，希望只缓存下载过的包，而不是全部同步。
5. 对于下载，发布npm包有对应的权限管理，安装方便，配置简单，依赖少。

关于sinopia？

Sinopia 是一个零配置的私有的带缓存功能的npm包管理工具，作者是是rlidwka，一个大神，也是一只猫～ 往社区内贡献过很多代码，包括 jshttp, markdown-it 等等，也是 Node.js 核心代码库的活跃贡献者。

使用sinopia，你不用安装CouchDB或MYSQL之类的数据库，Sinopia有自己的迷你数据库，如果要下载的包不存在，它将自动去你配置的npm地址上去下载，而且硬盘中只缓存你现在过的包，以节省空间。

为什么选择sinopia

sinopia有以下几个优势值得关注：

1. 不同步拉取npm库，占据大量硬盘，没有硬盘被撑爆的问题；
2. 安装配置极其简单,不需要数据库；
3. 支持配置上游registry配置，一次拉取即缓存；
4. 支持forever及pm2守护进程管理；

其他方法

• 使用 git+ssh 这种方式直接引用到 GitHub 项目地址

嗯，这种方式可行，也最简单，但真真的太烂了，姑且不说不能使用 semver，关键还是 url 太丑，如果是强迫症真的没法忍～

• 使用cnpm

暂且不论 cnpm 只是作为镜像使用，其实这个方案缺点就挺多的，用的人多，速度不一定快，缓存，关键是不支持发布包以及登陆、注册，再加上配置过于复杂。而且，还需要安装数据库。

• npm on-site

土豪啊，我还能说什么呢。。。但是问题是，npm在国内访问慢，还是不是的无法访问，花钱也买不到好的服务，何必呢。

部署

安装

首先，你要自己配置nodejs及npm的环境，然后运行

npm install -g sinopia

启动

$ sinopia
 warn  --- config file  - .....\AppData\Roaming\sinopia\config.yaml
 warn  --- http address - http://localhost:4873/

然后打开：http://localhost:4873/

如果能正常显示，说明安装成功。

使用pm2启动

当然，你也可以使用pm2或其他的守护进程进行管理，具体步骤如下：

安装pm2:npm install -g pm2

启动：pm2 start `which sinopia`

更多高级的pm2使用方法可以查看pm2电子书，相当详细，强烈推荐。

服务端配置

Sinopia的特点是，你在哪个目录运行，它的就会在对应的目录下创建自己的文件。目录下默认有两个文件：config.yaml和storage ，htpasswd 是添加用户之后自动创建的。

root@debian:/usr/local/apps/sinopia# ls
config.yaml  htpasswd  storage

其中config.yaml是用来配置访问权限，代理，文件存储路径等所有配置信息的，htpasswd用来保存用户的账号密码等息息，storage是用来存放npm包的。

config.yaml配置文件

#
# This is the default config file. It allows all users to do anything,
# so don't use it on production systems.
#
# Look here for more config file examples:
# https://github.com/rlidwka/sinopia/tree/master/conf
#

# path to a directory with all packages
storage: ./storage  //npm包存放的路径

auth:
  htpasswd:
    file: ./htpasswd   //保存用户的账号密码等信息
    # Maximum amount of users allowed to register, defaults to "+inf".
    # You can set this to -1 to disable registration.
    max_users: -1  //默认为1000，改为-1，禁止注册

# a list of other known repositories we can talk to
uplinks:
  npmjs:
    url: http://registry.npm.taobao.org/  //默认为npm的官网，由于国情，修改 url 让sinopia使用 淘宝的npm镜像地址
    
packages:  //配置权限管理
  '@*/*':
    # scoped packages
    access: $all
    publish: $authenticated

  '*':
    # allow all users (including non-authenticated users) to read and
    # publish all packages
    #
    # you can specify usernames/groupnames (depending on your auth plugin)
    # and three keywords: "$all", "$anonymous", "$authenticated"
    access: $all

    # allow all known users to publish packages
    # (anyone can register by default, remember?)
    publish: $authenticated

    # if package is not available locally, proxy requests to 'npmjs' registry
    proxy: npmjs

# log settings
logs:
  - {type: stdout, format: pretty, level: http}
  #- {type: file, path: sinopia.log, level: info}

# you can specify listen address (or simply a port) 
listen: 0.0.0.0:4873  ////默认没有，只能在本机访问，添加后可以通过外网访问。

部分配置字段意义

storage: 仓库保存的路径

web: 是否支持WEB接口

auth: 验证相关

uplinks: 配置上游的npm服务器，主要是用于请求的仓库不存在时去上游服务器拉取

packages: 配置模块/包的发布(publish)、下载(access)的权限等

listen: 配置监听端口与主机名

auth配置

max_users: -1表示我们将最大用户数设置为－1，表示禁用 npm adduser 命令来创建用户，不过我们仍然可以通过当前目录下的 htpasswd 文件来初始化用户。
示例：

yorkie:{SHA}?????????????????=:autocreated 2016-02-05T15:33:46.238Z

weflex:{SHA}????????????????=:autocreated 2016-02-05T15:39:19.960Z

james:{SHA}????????????????=:autocreated 2016-02-05T17:59:05.041Z

上面的加密算法也很简单，就是简单的SHA1哈稀之后再转换成 Base64 输出就好，后面跟着的只是表示时间。

packages配置

配置大致分为两个部分，一个是以 @weflex/* 为开头的，另一个则是通配符 *。

这个当然就是对 package.json 中的 name 字段进行匹配，比如 @weflex/app 将匹配第一个配置，而 express 则匹配第二个。

这里这么配置的意义在于：一般团队或者公司的私有项目，会采用不同的权限控制，于是这里借用了 NPM 的 scoped name 即 @Company 的形式，例如 @weflex/app 即表示 WeFlex 下属的 app 项目了。

接下来，每一个命名过滤器(filter)下都有三项基本设置：

• access: 表示哪一类用户可以对匹配的项目进行安装(install)

• publish: 表示哪一类用户可以对匹配的项目进行发布(publish)

• proxy: 如其名，这里的值是对应于 uplinks 的

对于1和2的值，我们通常有以下一些可选的配置：

• $all 表示所有人都可以执行对应的操作

• $authenticated 表示只有通过验证的人可以执行对应操作

• $anonymous 表示只有匿名者可以进行对应操作（通常无用）

或者也可以指定对应于之前我们配置的用户表 htpasswd 中的一个或多个用户，这样就明确地指定哪些用户可以执行匹配的操作
配置完成后，再运行：

$ sinopia -c config.yml

客户端使用

强烈推荐使用nrm来管理自己的代理。

安装nrm:

全局安装nrm可以快速修改,切换,增加npm镜像地址。

$ npm install -g nrm # 安装nrm
$ nrm add XXXXX http://XXXXXX:4873 # 添加本地的npm镜像地址
$ nrm use XXXX # 使用本址的镜像地址

nrm的其他命令：

$ nrm --help  # 查看nrm命令帮助
$ nrm list # 列出可用的 npm 镜像地址
$ nrm use taobao # 使用`淘宝npm`镜像地址

安装包

安装完成.之后你通过npm install 安装的包,sinopia都会帮你缓存到本地了.试一下吧。

mkdir test && cd test
npm install lodash # sinopia发现本地没有 lodash包,就会从 taobao镜像下载
rm -rf node-modules # 删除目录
npm insatll lodash # 第二次安装就会从缓存下载了,速度很快

创建用户与发布包

创建新用户

1.确保自己已经切换到配置的代理

➜  ~ nrm ls

  npm ---- https://registry.npmjs.org/
  cnpm --- http://r.cnpmjs.org/
  taobao - http://registry.npm.taobao.org/
  nj ----- https://registry.nodejitsu.com/
  rednpm - http://registry.mirror.cqupt.edu.cn
  npmMirror  https://skimdb.npmjs.com/registry
* sinopia  http://192.168.1.200:4873/

2.运行npm adduser,填写信息，注册账号。如果已经有账号，直接运行npm login即可。

➜  ~ npm adduser
  Username: test
  Password:

3.运行$ npm publish发布新包。

总结

• 到此为止吧，剩下的坑自己踩吧，多踩坑才能多成长。
• 保存好你的 htpasswd 文件，不要泄漏到任何公有仓库中去。
• 以上的情况并没有考虑在遇到一些黑客攻击的情况下，所以为了尽量保证代码的安全，可以在前端加一层 Nginx 然后配置 SSH 公钥来作为双层验证。

替换

通过一些例子来学习正则表达式摘录，js正则函数match、exec、test、search、replace、split

去除首尾的

//去除首尾的‘/’
input = input.replace(/^\/*|\/*$/g,'');

javascript:; 、javascript:void(0)

'javascript:;'.match(/^(javascript\s*\:|#)/);
//["javascript:", "javascript:", index: 0, input: "javascript:;"]

匹配

var str = "access_token=dcb90862-29fb-4b03-93ff-5f0a8f546250; refresh_token=702f4815-a0ff-456c-82ce-24e4d7d619e6; account_uid=1361177947320160506170322436";
str.match(/account_uid=([^\=]+(\;)|(.*))/ig);

匹配一些字符

var str = 'asdf html-webpack-plugin for "index/index.html" asdfasdf';
str.match(/html-webpack-plugin for \"(.*)\"/ig);
console.log(RegExp.$1) //=>index/index.html

关键字符替换

'css/[hash:8].index-index.css'.replace(/\[(?:(\w+):)?(contenthash|hash)(?::([a-z]+\d*))?(?::(\d+))?\]/ig,'(.*)');
//=> css/(.*).index-index.css

替换参数中的值

var str  = '<!DOCTYPE html><html manifest="../../cache.manifest" lang="en"><head><meta charset="UTF-8">';
str.replace(/<html[^>]*manifest="([^"]*)"[^>]*>/,function(word){
   return word.replace(/manifest="([^"]*)"/,'manifest="'+url+'"');
}).replace(/<html(\s?[^\>]*\>)/,function(word){
    if(word.indexOf('manifest')) return word;
    return word.replace('<html','<html manifest="'+url+'"');
});
//原：<!DOCTYPE html><html manifest="../../cache.manifest" lang="en"><head><meta charset="UTF-8">
//替换成=> <!DOCTYPE html><html manifest="cache.manifest" lang="en"><head><meta charset="UTF-8">

匹配括号内容

'max_length(12)'.match(/^(.+?)\((.+)\)$/)
// ["max_length(12)", "max_length", "12", index: 0, input: "max_length(12)"]

调换

var name = "Doe, John"; 
name.replace(/(\w+)\s*, \s*(\w+)/, "$2 $1"); 
//=> "John Doe"

字符串截取

var str = 'asfdf === sdfaf ##'
str.match(/[^===]+(?=[===])/g) // 截取 ===之前的内容

str.replace(/\n/g,'')  // 替换字符串中的 \n 换行字符

验证

小数点后几位验证

// 精确到1位小数
/^[1-9][0-9]*$|^[1-9][0-9]*\.[0-9]$|^0\.[0-9]$/.test(1.2);

// 精确到2位小数
/^[0-9]+(.[0-9]{2})?$/.test(1.221);

密码强度正则

// 必须是包含大小写字母和数字的组合，不能使用特殊字符，长度在8-10之间。
/^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$/.test("weeeeeeeW2");
//密码强度正则，最少6位，包括至少1个大写字母，1个小写字母，1个数字，1个特殊字符
/^.*(?=.{6,})(?=.*\d)(?=.*[A-Z])(?=.*[a-z])(?=.*[!@#$%^&*? ]).*$/.test("diaoD123#");
//输出 true

校验中文

/^[\u4e00-\u9fa5]{0,}$/.test("但是d"); //false
/^[\u4e00-\u9fa5]{0,}$/.test("但是"); //true
/^[\u4e00-\u9fa5]{0,}$/.test("但是"); //true

包含中文正则

/[\u4E00-\u9FA5]/.test("但是d") //true

由数字、26个英文字母或下划线组成的字符串

/^\w+$/.test("ds2_@#"); // false

身份证号正则

//身份证号（18位）正则
/^[1-9]\d{5}(18|19|([23]\d))\d{2}((0[1-9])|(10|11|12))(([0-2][1-9])|10|20|30|31)\d{3}[0-9Xx]$/.test("42112319870115371X");
//输出 false

校验日期

“yyyy-mm-dd“ 格式的日期校验，已考虑平闰年。

//日期正则，简单判定,未做月份及日期的判定
var dP1 = /^\d{4}(\-)\d{1,2}\1\d{1,2}$/;
//输出 true
console.log(dP1.test("2017-05-11"));
//输出 true
console.log(dP1.test("2017-15-11"));
//日期正则，复杂判定
var dP2 = /^(?:(?!0000)[0-9]{4}-(?:(?:0[1-9]|1[0-2])-(?:0[1-9]|1[0-9]|2[0-8])|(?:0[13-9]|1[0-2])-(?:29|30)|(?:0[13578]|1[02])-31)|(?:[0-9]{2}(?:0[48]|[2468][048]|[13579][26])|(?:0[48]|[2468][048]|[13579][26])00)-02-29)$/;
//输出 true
console.log(dP2.test("2017-02-11"));
//输出 false
console.log(dP2.test("2017-15-11"));
//输出 false
console.log(dP2.test("2017-02-29"));
// true

校验文件后缀

  var strRegex = "(.jpg|.gif|.txt)";
  var re=new RegExp(strRegex);
  if (re.test(str)){
    
  }
/(.jpg|.gif)+(\?|\#|$)/.test('a/b/c.jpgsss'); //=> false
/(.jpg|.gif)+(\?|\#|$)/.test('a/b/c.jpg?'); //=> true

用户名正则

//用户名正则，4到16位（字母，数字，下划线，减号）
/^[a-zA-Z0-9_-]{4,16}$/.test("diaodiao");
//输出 true

整数正则

/^\d+$/.test("42");    //正整数正则  -> 输出 true
/^-\d+$/.test("-42");  //负整数正则  -> 输出 true
/^-?\d+$/.test("-42"); //整数正则  -> 输出 true

/^[0-9]+$/.test(25.5455) //正整数正则  -> 输出 false
// 浮点数
/^(?:[-+])?(?:[0-9]+)?(?:\.[0-9]*)?(?:[eE][\+\-]?(?:[0-9]+))?$/.test(0.2)

数字正则

可以是整数也可以是浮点数

/^\d*\.?\d+$/.test("42.2");     //正数正则  -> 输出 true
/^-\d*\.?\d+$/.test("-42.2");   //负数正则 -> 输出 true
/^-?\d*\.?\d+$/.test("-42.2");  //数字正则 -> 输出 true

Email正则

//Email正则
/^([A-Za-z0-9_\-\.])+\@([A-Za-z0-9_\-\.])+\.([A-Za-z]{2,4})$/.test("[email protected]");
//输出 true

// 1.邮箱以a-z、A-Z、0-9开头，最小长度为1.
// 2.如果左侧部分包含-、_、.则这些特殊符号的前面必须包一位数字或字母。
// 3.@符号是必填项
// 4.右则部分可分为两部分，第一部分为邮件提供商域名地址，第二部分为域名后缀，现已知的最短为2位。
//   最长的为6为。
// 5.邮件提供商域可以包含特殊字符-、_、.
/^[a-z0-9]+([._\\-]*[a-z0-9])*@([a-z0-9]+[-a-z0-9]*[a-z0-9]+.){1,63}[a-z0-9]+$/.test("[email protected]");

传真号码

// 国家代码(2到3位)-区号(2到3位)-电话号码(7到8位)-分机号(3位)
/^(([0\+]\d{2,3}-)?(0\d{2,3})-)(\d{7,8})(-(\d{3,}))?$/.test('021-5055455')

手机号码正则

//手机号正则
/^1[34578]\d{9}$/.test("13611778887");
//输出 true

//* 13段：130、131、132、133、134、135、136、137、138、139
//* 14段：145、147
//* 15段：150、151、152、153、155、156、157、158、159
//* 17段：170、176、177、178
//* 18段：180、181、182、183、184、185、186、187、188、189
//* 国际码 如：**(+86)
/^((\+?[0-9]{1,4})|(\(\+86\)))?(13[0-9]|14[57]|15[012356789]|17[03678]|18[0-9])\d{8}$/.test("13611778887");

URL正则

//URL正则
/^((https?|ftp|file):\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/.test("http://wangchujiang.com");
//输出 true

//获取url中域名、协议正则 'http://xxx.xx/xxx','https://xxx.xx/xxx','//xxx.xx/xxx'
/^(http(?:|s)\:)*\/\/([^\/]+)/.test("http://www.baidu.com");

/^((http|https):\/\/(\w+:{0,1}\w*@)?(\S+)|)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-\/]))?$/.test('https://www.baidu.com/s?wd=@#%$^&%$#')

// 必须有协议 
/^[a-zA-Z]+:\/\//.test("http://www.baidu.com");

IPv4地址正则

//ipv4地址正则
/^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/.test("192.168.130.199");
//输出 true

十六进制颜色正则

//RGB Hex颜色正则
/^#?([a-fA-F0-9]{6}|[a-fA-F0-9]{3})$/.test("#b8b8b8");
//输出 true

QQ号码正则

//QQ号正则，5至11位
/^[1-9][0-9]{4,10}$/.test("398188661");//输出 true

微信号正则

//微信号正则，6至20位，以字母开头，字母，数字，减号，下划线
/^[a-zA-Z]([-_a-zA-Z0-9]{5,19})+$/.test("jslite"); //输出 true

车牌号正则

//车牌号正则
/^[京津沪渝冀豫云辽黑湘皖鲁新苏浙赣鄂桂甘晋蒙陕吉闽贵粤青藏川宁琼使领A-Z]{1}[A-Z]{1}[A-Z0-9]{4}[A-Z0-9挂学警港澳]{1}$/.test("沪B99116") //输出 true

颜色值校验

// HEX 颜色正则
/^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$/.test("#ccb2b2")

背景

在很久很久以前，我们访问各种网站都是简单而直接的，用户的请求通过互联网发送到服务提供方，服务提供方直接将信息反馈给用户。

后来，GFW 就出现了，他像一个收过路费的强盗一样夹在了在用户和服务之间，每当用户需要获取信息，都经过了 GFW，GFW将它不喜欢的内容统统过滤掉，于是客户当触发 GFW 的过滤规则的时候，就会收到 Connection Reset 这样的响应内容，而无法接收到正常的内容。

GFW 内部结构：

GFW 列表可以参考这里：gfwlist/gfwlist

聪明的人们想到了利用境外服务器代理的方法来绕过 GFW 的过滤，其中包含了各种HTTP代理服务、Socks服务、VPN服务等。

SSH Tunnel

SSH（Secure Shell）是一个提供数据通信安全、远程登录、远程指令执行等功能的安全网络协议，由芬兰赫尔辛基大学研究员Tatu Ylönen，于1995年提出，其目的是用于替代非安全的Telnet、rsh、rexec等远程Shell协议。之后SSH发展了两个大版本SSH-1和SSH-2。

想深入了解SSH的原理，可以查看 O‘RELLY的 《SSH: The Secure Shell - The Definitive Guide》，这是一本非常不错的书。

那么我们来看看搭建一个SSH隧道翻墙，究竟有多简单。首先你需要有一台支持SSH的墙外服务器，此服务器啥都不需要，只要能SSH连接即可。

客户端SSH执行如下命令：

ssh -D 7001 username@remote-host

上述命令中-D表示动态绑定，7001表示本地SOCKS代理的侦听端口，可以改成别的，后面的 username@remote-host就是你登录远程服务器的用户名和主机。当然，这个命令后会提示输入密码，就是username这个用户的密码（除非你配置了SSH公钥认证，可以不输入密码），这样隧道就打通了。

1. 首先用户和境外服务器基于 ssh 建立起一条加密的通道 (1)
2. 用户通过建立起的隧道进行代理，通过 ssh server 向真实的服务发起请求 (2-3)
3. 服务通过 ssh server，再通过创建好的隧道返回给用户 (4-5)

由于 ssh 本身就是基于 RSA 加密技术，所以 GFW 无法从数据传输的过程中的加密数据内容进行关键词分析，避免了被重置链接的问题，但由于创建隧道和数据传输的过程中，ssh 本身的特征是明显的，所以 GFW 一度通过分析连接的特征进行干扰，导致 ssh 存在被定向进行干扰的问题。

至于干扰的原理，shadowsocks的作者 @clowwindy 认为：

从校长最近的论文上上看，GFW 最近弄的是先检测首部特征判断 SSL 和 SSH，然后统计包长度和方向，用实现训练好的模型去判断承载的流量是否为 HTTP。如果你用 SSH 翻墙，或者你的操作行为发的数据包过于接近 HTTP，就会被 reset。反过来，如果你想用 SSH 翻墙，只要在用来翻墙的那个 ssh 连接里做些别的操作（比如反复 tail 一个长文件，这样会不停的输出；或者用管道不停的往 ssh 里写命令，这样会不停的输入），就可以让这个模型失效，从而不会被判定为翻墙。

VPN

随着时代的发展以及企业规模的发展壮大，企业网络也在不断发生变化。例如，一家总部设在北京的企业，可能会在上海、广州和深圳等地都设有分支机构，因此需要把各个分支机构连接在一起，以便共享资源、协同工作，提高工作效率。但传统的专线联网方式价格昂贵，一般中小企业难以负担。这时低成本的VPN技术就孕育而生了。VPN（Virtual Private Network）即虚拟专用网络，它可以利用廉价接入的公共网络（主要使用Inter-net）来传输私有数据，相较于传统的专线连网方式具有成本优势，因此被很多企业和电信运营商采用。

VPN 比shadowsocks更加底层，它通过操作系统的接口直接虚拟出一张网卡，后续整个操作系统的网络通讯都将通过这张虚拟的网卡进行收发。这和任何一个代理的实现思路都差不多，应用层并不知道网卡是虚拟的，这样vpn虚拟网卡将以中间人的身份对数据进行加工，从而实现各种神奇的效果。具体来说，vpn是通过编写一套网卡驱动并注册到操作系统实现的虚拟网卡，这样数据只要经过网卡收发就可以进行拦截处理。

VPN和SSH隧道翻墙有如下区别：

• VPN的设置是全局的，即电脑一旦挂上VPN，所有的联网程序都将自动使用VPN；而建立好SSH隧道后，需要程序设定使用隧道才会使用隧道联网。
• 如果使用商用的VPN一般要花钱，如果自己搭，VPN的搭建难度大于SSH隧道。因为SSH隧道只要一台可以SSH的服务器即可，根本不需要在服务器上配置任何东西。
• vpn在IP层工作，而shadowsocks在TCP层工作。

shadowsocks

简单理解的话，shadowsocks 是将原来 ssh 创建的 Socks5 协议拆开成 server 端和 client 端，所以下面这个原理图基本上和利用 ssh tunnel 大致类似。

• 1、6) 客户端发出的请求基于 Socks5 协议跟 ss-local 端进行通讯，由于这个 ss-local 一般是本机或路由器或局域网的其他机器，不经过 GFW，所以解决了上面被 GFW 通过特征分析进行干扰的问题
• 2、5) ss-local 和 ss-server 两端通过多种可选的加密方法进行通讯，经过 GFW 的时候是常规的TCP包，没有明显的特征码而且 GFW 也无法对通讯数据进行解密
• 3、4) ss-server 将收到的加密数据进行解密，还原原来的请求，再发送到用户需要访问的服务，获取响应原路返回

PAC模式

代理自动配置（Proxy auto-config，简称PAC） 是一种网页浏览器技术，用于定义浏览器该如何自动选择适当的代理服务器来访问一个网址。

一个PAC文件包含一个JavaScript形式的函数 FindProxyForURL(url, host)。这个函数返回一个包含一个或多个访问规则的字符串。用户代理根据这些规则适用一个特定的代理其或者直接访问。当一个代理服务器无法响应的时候，多个访问规则提供了其他的后备访问方法。浏览器在访问其他页面以前，首先访问这个PAC文件。PAC文件中的URL可能是手工配置的，也可能是是通过网页的 网络代理自发现协议（Web Proxy Autodiscovery Protocol） 自动配置的。

上面是从维基百科摘录的关于PAC的解释，我做了一个简单的图片解释什么是PAC：

简单的讲，PAC就是一种配置，它能让你的浏览器智能判断哪些网站走代理，哪些不需要走代理。点击 Shadowsocks 的菜单，选择 编辑自动模式的 PAC，如下图

在上面的目录下有两个文件，一个是 gfwlist.js，还有一个是
user-rule.txt,确保当前的模式为自动代理模式，打开系统设置-->网络，点击高级，查看代理选项卡，如下图

Shadowsocks全局模式与PAC模式的区别

Shadowsocks 的全局模式，是设置你的系统代理的代理服务器，使你的所有http/socks数据经过代理服务器的转发送出。而只有支持 socks 5或者使用系统代理的软件才能使用 Shadowsocks（一般的浏览器都是默认使用系统代理）。

而PAC模式就是会在你连接网站的时候读取PAC文件里的规则，来确定你访问的网站有没有被墙，如果符合，那就会使用代理服务器连接网站，而PAC列表一般都是从 GFWList 更新的。GFWList 定期会更新被墙的网站（不过一般挺慢的）。

简单地说，在全局模式下，所有网站默认走代理。而PAC模式是只有被墙的才会走代理，推荐PAC模式，如果PAC模式无法访问一些网站，就换全局模式试试，一般是因为PAC更新不及时（也可能是GFWList更新不及时）导致的。

还有，说一下Chrome不需要 Proxy SwitchyOmega 和 Proxy SwitchySharp 插件，这两个插件的作用就是，快速切换代理，判断网站需不需要使用某个代理的（shadowsocks已经有pac模式了，所以不需要这个）。如果你只用shadowsocks的话，就不需要这个插件了！

经过代理服务器的IP会被更换。连接 Shadowsocks 需要知道IP、端口、账号密码和加密方式。但是Shadowsocks因为可以自由换端口，所以定期换端口就可以有效避免IP被封！

Socks代理和http代理的区别

Socks代理

本地浏览器SOCKS服务器通常是用来做代理的，它通过TCP连接把目标主机和客户端连接在一起， 并转发所有的流量。SOCKS代理能在任何端口，任何协议下运行（额，好想有点不对， 这货是运行在session层，所以在他之下的层他就无法代理了）。SOCKS V4只支持 TCP连接，而SOCKS V5在其基础上增加了安全认证以及对UDP协议的支持（也就是说， SOCKS5支持密码认证以及转发UDP流量，注意，HTTP是不支持转发UDP的）。

SOCKS代理在任何情况下都不会中断server与client之间的数据（这是由这种协议的 特性决定的，毕竟非明文，但是在SOCKS代理服务器上还是可以还原出TCP和UDP的原始 流量的），当你的防火墙不允许你上网的时候，你就可以通过SOCKS代理来上网（这里的 意思是，如果GFW把google屏蔽了，你就可以通过一台海外的SOCKS代理服务器上谷歌）。

大多数的浏览器都支持SOCKS代理（这篇文章是三年前的，抱歉，谷歌第一条就是它）。（ 浏览器上网的时候需要与目标主机建立TCP连接，这个时候浏览器就会告诉SOCKS代理，它想 与目标主机进行通讯，然后SOCKS代理就会转发浏览器的数据，并向目标主机发出请求，然 后再把返回的数据转发回来。）（关于shadowsocks的一点题外话：虽然github上的源码 没了，但是耐不住民间私货多呀。shadowsocks有server端和client端，这两个都是用 来转发数据的，但是由于其所处的位置不同，所以功能也不同，client即本地运行的程序， 监听1080端口，并将数据转发到远在他乡的SOCKS服务器，由于这种转发是加密的，在会话层， 所以GFW过滤的难度很大，所以才派人巴拉巴拉让作者删除源码，嗯，一定是这样的。然后server 那边收到数据后，会原原本本的把数据再向目标请求，收到反馈后再返回给本地client的1080端口， 这样，我们向本地的1080请求资源，本地向SOCKS服务器请求资源，SOCKS服务器向目标请求资源， 这一条TCP连接就这样建立起来了。）但是，但是，但是，SOCKS代理原则上是可以还原真实数据的， 所以，第三方的代理也许不是很可靠。

HTTP代理

HTTP代理跟上面原理类似，用处也基本相同，都是让处于防火墙下的主机与外界建立连接，但是它与SOCKS代理不同的是，HTTP代理可以中断连接（即在中间截断数据流），因为HTTP代理是以HTTP请求为基础的 而这些请求大多以明文形式存在，所以HTTP代理可以在Client和下游服务器中间窃听，修改数据。但也正 由于HTTP代理只能处理HTTP请求，所以它对HTTP请求的处理也是很舒服的（原文中是smart）。而也由于 HTTP代理可以获取你的HTTP请求，所以HTTP代理服务器那边就可以根据你提交的数据来把那些资源缓存下来，提升访问的速度（用户亲密度+1）。有好多ISP都用HTTP代理，而不管用户那边的浏览器是怎样配置的，因为不管用户们怎么配置，他们总是要访问80端口，而这些80端口们又掌握在ISP们的手中。（原文完全不是这样说的= =。原文是说，互联网提供商们把流量都通过了HTTP代理，这样代理服务器中就有了缓存，访问的速度会快一些。）

（我来举个栗子：假如你的HTTP代理是Goagent，监听本地127.0.0.1:8080，此刻假设你已经把浏览器 的代理设置为：127.0.0.1:8080，那么你在浏览器中，所有的POST，GET，以及其他的请求，都会通过 本地的代理转发给远程的服务器，然后再通过远程的服务器去请求你所请求的这些资源，大家知道，HTTP协议是通过明文传输的，无论是在本地还是远程的服务器上，都是可以监听到这些流量的，所以才会有GFW的存在……HTTP协议属于应用层，而SOCKS协议属于传输层，ps：传输层在应用层之下，这就决定了两者的能力大小。）

参考

• shadowsocks 源码阅读
• Shadowsocks 源码分析——协议与结构
• 写给非专业人士看的 Shadowsocks 简介
• SSH原理简介
• RSA算法原理（一）
• 详解代理自动配置 PAC
• 科学上网漫游指南
• Socks代理和http代理的区别

随着前端这几年的风生水起，CSS作为前端的三剑客之一，各种技术方案也是层出不穷。从CSS prepocessor（SASS、LESS、Stylus）到后来的后起之秀 PostCSS，再到 CSS Modules、Styled-Component 等。有人维护了一份完整的 CSS in JS 技术方案的对比，里面已经有将近50种技术方案。CSS Modules就是其中一种。

CSS Modules 介绍

要弄懂CSS Modules是什么，可以先看官方介绍：GitHub – css-modules/css-modules: Documentation about css-modules

通过上面介绍可以看出，CSS Modules既不是官方标准，也不是浏览器的特性，而是在构建步骤（例如使用Webpack或Browserify）中对CSS类名选择器限定作用域的一种方式（通过hash实现类似于命名空间的方法）。例如我们在buttons.js里引入buttons.css文件，并使用.btn的样式，在其他组件里是不会被.btn影响的，除非它也引入了buttons.css.

CSS模块化

JS已经全面实现了模块化，但是css还处于探索阶段。为什么我们需要css模块化？主要由一下几个原因。

CSS全局作用域问题

CSS的规则都是全局的，任何一个组件的样式规则，都对整个页面有效。现在的前端工程大多是基于组件开发，随着工程的页面数量好复杂度的提升，相信写css的人都会遇到样式冲突（污染）的问题。一般我们会采用一下几种方法：

• class命名写长一点吧，降低冲突的几率
• 加个父元素的选择器，限制范围
• 重新命名个class吧，比较保险

可是以上方案只是降低了全局冲突的概率，并不能彻底解决全局冲突的问题。并且，实现方式也不够优雅，还增加了代码的复杂和冗余。

我们的追求

• 面向组件开发 ： 处理 UI 复杂性的最佳实践就是将 UI 分割成一个个的小组件，React 就鼓励高度组件化和分割。我们希望有一个 CSS 架构去匹配。
• 沙箱化（Sandboxed） ： 如果一个组件的样式会对其他组件产生不必要以及意想不到的影响，那么将 UI 分割成组件并没有什么用。就这方面而言，CSS的全局作用域会给你造成负担。
• 方便 ：不会增加开发的负担和代码的冗余。

方案

CSS 模块化的解决方案有很多，但主要有三类。

CSS 命名约定

规范化CSS的模块化解决方案（比如BEM BEM — Block Element Modifier ,OOCSS,AMCSS,SMACSS,SUITCSS)
但存在以下问题：

• JS CSS之间依然没有打通变量和选择器等
• 复杂的命名

CSS in JS

彻底抛弃 CSS，用 JavaScript 写 CSS 规则，并内联样式。styled-components 就是其中代表。styled-components可以让CSS真正意义地写到JS里面，同时让标签更具有语意化，这跟HTML5新标签**相同；该框架让样式也具备组件化**，让前端完全面向组件化编程，就像java的包装类型。
但存在以下问题：

• 样式代码也会出现大量重复。
• 不能利用成熟的 CSS 预处理器（或后处理器）

使用 JS 来管理样式模块

使用JS编译原生的CSS文件，使其具备模块化的能力，代表是 CSS Modules。

CSS Module还是JS和CSS分离的写法，不会改变大家的书写习惯，CSS Module只需修改构建代码和使用模块依赖引入className的方式即可使用，且支持less和sass的语法，

使用CSS Modules可以让组件className控制权转交给JS，我们不会去关心命名冲突污染等问题，同时可以灵活控制生成的命名，样式代码不用修改即可让使用CSS语法的旧项目零成本接入。

CSS Modules 能最大化地结合现有 CSS 生态(预处理器/后处理器等)和 JS 模块化能力，几乎零学习成本。只要你使用 Webpack，可以在任何项目中使用。是目前最好的 CSS 模块化解决方案。

使用

配置

CSS Modules配置非常简单，如果你使用webpack，只需要在配置文件中改动一行即可。

// webpack.config.js
css?modules&localIdentName=[name]__[local]-[hash:base64:5]
 

加上 modules 即为启用，localIdentName 是设置生成样式的命名规则。

编码

css

/* components/Button.css */
.normal { /* normal 相关的所有样式 */ }
 

js

// components/Button.js
import styles from './Button.css';
console.log(styles);
buttonElem.outerHTML = `<button class=${styles.normal}>Submit</button>`

上例中 console 打印styles的结果是：

Object {
  normal: 'button--normal-abc53',
  disabled: 'button--disabled-def886',
}
 

注意到 button--normal-abc53 是 CSS Modules 按照 localIdentName 自动生成的 class 名。其中的 abc53 是按照给定算法生成的序列码。经过这样混淆处理后，class 名基本就是唯一的，大大降低了项目中样式覆盖的几率。同时在生产环境下修改规则，生成更短的 class 名，可以提高 CSS 的压缩率。

CSS Modules 对 CSS 中的 class 名都做了处理，使用对象来保存原 class 和混淆后 class 的对应关系。

React实践

手动引用

import React from 'react';
import styles from './table.css';
 
export default class Table extends React.Component {
    render () {
        return <div className={styles.table}>
            <div className={styles.row}>
            </div>
        </div>;
    }
}
 

渲染结果：

<div class="table__table___32osj">
    <div class="table__row___2w27N">
    </div>
</div>

使用babel-plugin-react-css-modules

babel-plugin-react-css-modules 可以实现使用styleName属性自动加载CSS模块。只需要把className换成styleName即可获得CSS局部作用域的能力，babel插件来自动进行语法树解析并最终生成className。改动成本极小，不会增加JSX的复杂度，也不会给项目带来额外的负担。

import React from 'react';
import styles from './table.css';
 
class Table extends React.Component {
    render () {
        return <div styleName='table'>
        </div>;
    }
}
 
export default Table；
 

CSS Modules 很好的解决了 CSS 目前面临的模块化难题。支持与 CSS处理器搭配使用，能充分利用现有技术积累。如果你的产品中正好遇到类似问题，非常值得一试。

参考

• CSS Modules 入门及 React 中实践
• CSS Modules 用法教程
• Styled Components：让样式也成为组件
• 精读《请停止 css-in-js 的行为》

前言

在前端工程的的打包史中，common文件向来都不是一个好处理的方面。在这一块，webpack提供了CommonsChunkPlugin来处理这个事情，但是在由于文档的模棱两可，再加上各种配置选项的多样性和某些bug，这一块还是有不少坑的。

分析包

所谓工欲善其事必先利其器，我们既然想做common方面的优化，那么首先肯定要知道打包后的文件体积庞大的主要原因。说到这里就不得不提到一个相当好用的工具：webpack-bundle-analyzer

它既是一个webpack插件，又是一个命令行工具。能够将webpack包的内容转换成可缩放的树状图，方便进行交互分析。恩。。。就是这玩意：

安装

npm install --save-dev webpack-bundle-analyzer

作为插件使用

在 webpack.config.js中:

var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

// ...
plugins: [new BundleAnalyzerPlugin()]
// ...

默认配置如下：

new BundleAnalyzerPlugin({
  // Can be `server`, `static` or `disabled`.
  // In `server` mode analyzer will start HTTP server to show bundle report.
  // In `static` mode single HTML file with bundle report will be generated.
  // In `disabled` mode you can use this plugin to just generate Webpack Stats JSON file by setting `generateStatsFile` to `true`.
  analyzerMode: 'server',
  // Host that will be used in `server` mode to start HTTP server.
  analyzerHost: '127.0.0.1',
  // Port that will be used in `server` mode to start HTTP server.
  analyzerPort: 8888,
  // Path to bundle report file that will be generated in `static` mode.
  // Relative to bundles output directory.
  reportFilename: 'report.html',
  // Automatically open report in default browser
  openAnalyzer: true,
  // If `true`, Webpack Stats JSON file will be generated in bundles output directory
  generateStatsFile: false,
  // Name of Webpack Stats JSON file that will be generated if `generateStatsFile` is `true`.
  // Relative to bundles output directory.
  statsFilename: 'stats.json',
  // Options for `stats.toJson()` method.
  // For example you can exclude sources of your modules from stats file with `source: false` option.
  // See more options here: https://github.com/webpack/webpack/blob/webpack-1/lib/Stats.js#L21
  statsOptions: null,
  // Log level. Can be 'info', 'warn', 'error' or 'silent'.
  logLevel: 'info'
})

命令行使用

第一步：

webpack --profile --json > stats.json

第二步：

webpack --profile --json | Out-file 'stats.json' -Encoding OEM

执行成功后，你将看到以下动态网页：

在这里顺便放上线上文件加载waterfall，作为对比。

问题

通过图表可以看到，在以下配置下:

config.plugins.push(new CommonsChunkPlugin('commons', 'js/commons.[hash].bundle.js'));

打包出来的文件还是有很多问题的：

• common包规划不合理， swiper.js ,area.json等公用文件大量重复加载。
• antd 没有抽离出来，无法并行加载，也无法进一步做运行时按需加载。
• echarts在每个使用的包都单独打包一份，只要包含echarts的包，基本一百多kb。（线上压缩并开启gzip）
• import {ImgBigSwiper} from 'components/src/index'; 这种写法会导致将components里面的所有组件全部打包进页面的js。应该这样写：import ImgBigSwiper from 'components/src/ImgBigSwiper';挨个引入，见webpack将ES6编译成CommonJs后只引入用到的模块
• common.js独占490kb，要等这个包加载完后index才开始解析路由。

在这个过程中，会发现一个有趣的事情。就是index.html页面的script加载分为以下两个部分：

......
<script type="text/javascript" src="//res.dinghuo123.com/src/common/ueditor/ueditor.config.js"></script>
<script type="text/javascript" src="//res.dinghuo123.com/src/common/ueditor/ueditor.config.js"></script>
<script type="text/javascript" src="//res.dinghuo123.com/src/common/ueditor/ueditor.config.js"></script>
......
<script>
    document.write('<script src="https://resource.dinghuo123.com/dist/ydhv2/webpack.assets.js?v=' + Math.random() + '"><\/script>');
    document.write('<script src="' + window.WEBPACK_ASSETS['commons'].js + '"><\/script>');
    document.write('<script src="//res.dinghuo123.com/src/common/ueditor/ueditor.config.js"><\/script>');
    document.write('<script src="' + window.WEBPACK_ASSETS['index'].js + '"><\/script>');
</script>

然后你会发现，是上面一块的script并行加载完，才并行加载下一个script标签的内容。大家可以思考一下为什么。

改进配置

进过调整之后的CommonsChunkPlugin配置：

config.plugins.push(new CommonsChunkPlugin({
  name: 'commons',
  minChunks: Infinity // 随着 入口chunk 越来越多，这个配置保证没其它的模块会打包进 公共chunk
}));

config.plugins.push(new CommonsChunkPlugin({
  async:'antd',
  minChunks(module) {
    var context = module.context;
    return context && context.indexOf('antd/dist') >= 0;
  }
}));

config.plugins.push(new CommonsChunkPlugin({
  async:'echarts',
  minChunks(module) {
    var context = module.context;
    return context && (context.indexOf('echarts') >= 0 || context.indexOf('zrender') >= 0);
  }
}));

这里用到了minChunks和async两个配置。

minChunks

其中第一name的commons是一个entry入口，里面是一个依赖包的数组。minChunks设置为Infinity这个配置保证没其它的模块会打包进 公共chunk。因为说实话，CommonsChunkPlugin的commons分析实在是不怎么只能，还是手动控制会更好一些。
当然，你可以传入一个 function ，以添加定制的逻辑（默认是 chunk 的数量），这个函数会被 CommonsChunkPlugin 插件回调，并且调用函数时会传入 module 和 count 参数。
module 参数代表每个 chunks 里的模块，这些 chunks 是你通过 name/names 参数传入的。

• module.context: The directory that stores the file. For example: '/my_project/node_modules/example-dependency'
• module.resource: The name of the file being processed. For example: '/my_project/node_modules/example-dependency/index.js'
• count 参数表示 module 被使用的 chunk 数量。

当你想要对 CommonsChunk 如何决定模块被打包到哪里的算法有更为细致的控制， 这个配置就会非常有用。

async

如果设置为 true，一个异步的 公共chunk 会作为 options.name 的子模块，和 options.chunks 的兄弟模块被创建。它会与 options.chunks 并行被加载。可以通过提供想要的字符串，而不是 true 来对输出的文件进行更换名称。

结果

还是先看打包分析的结果吧：

通过上面分析可以看到：

1. common合理划分，抓大放小。
2. antd和echarts提取出来，并行加载。
3. components 用到什么打包什么。(手动控制的)
4. 大大减小了其他业务包的体积，93%的业务包大小控制在25K以内，剩下7%的业务包大小控制在50k以内。（开启gzip）
5. 首屏加载资源的总大小几乎没有变化。

接下来的方向

1. echarts 和Ueditor运行时按需加载。
2. tree-shaking的探索

参考

Vendor and code splitting in webpack 2
webpack 按需打包加载
weboack Split app and vendor code
awesome-webpack-cn

在 ES6 中增加了对类对象的相关定义和操作（比如 class 和 extends ），这就使得我们在多个不同类之间共享或者扩展一些方法或者行为的时候，变得并不是那么优雅。这个时候，我们就需要一种更优雅的方法来帮助我们完成这些事情。

什么是装饰器

Python 的装饰器

在面向对象（OOP）的设计模式中，decorator被称为装饰模式。OOP的装饰模式需要通过继承和组合来实现，而Python除了能支持 OOP 的 decorator 外，直接从语法层次支持 decorator。

如果你熟悉 python 的话，对它一定不会陌生。那么我们先来看一下 python 里的装饰器是什么样子的吧：

def decorator(f):
    print "my decorator"
    return f
@decorator
def myfunc():
    print "my function"
myfunc()
# my decorator
# my function

这里的 @decorator 就是我们说的装饰器。在上面的代码中，我们利用装饰器给我们的目标方法执行前打印出了一行文本，并且并没有对原方法做任何的修改。代码基本等同于：

def decorator(f):
    def wrapper():
        print "my decorator"
        return f()
    return wrapper
def myfunc():
    print "my function"
myfunc = decorator(myfuc)

通过代码我们也不难看出，装饰器 decorator 接收一个参数，也就是我们被装饰的目标方法，处理完扩展的内容以后再返回一个方法，供以后调用，同时也失去了对原方法对象的访问。当我们对某个应用了装饰以后，其实就改变了被装饰方法的入口引用，使其重新指向了装饰器返回的方法的入口点，从而来实现我们对原函数的扩展、修改等操作。

ES7 的装饰器

ES7 中的 decorator 同样借鉴了这个语法糖，不过依赖于 ES5 的 Object.defineProperty 方法 。

Object.defineProperty

Object.defineProperty() 方法会直接在一个对象上定义一个新属性，或者修改一个对象的现有属性， 并返回这个对象。

该方法允许精确添加或修改对象的属性。通过赋值来添加的普通属性会创建在属性枚举期间显示的属性（for...in 或 Object.keys 方法）， 这些值可以被改变，也可以被删除。这种方法允许这些额外的细节从默认值改变。默认情况下，使用 Object.defineProperty() 添加的属性值是不可变的。

语法

Object.defineProperty(obj, prop, descriptor)

• obj：要在其上定义属性的对象。
• prop：要定义或修改的属性的名称。
• descriptor：将被定义或修改的属性描述符。
• 返回值：被传递给函数的对象。

在ES6中，由于 Symbol类型 的特殊性，用 Symbol类型 的值来做对象的key与常规的定义或修改不同，而Object.defineProperty 是定义 key为 Symbol 的属性的方法之一。

属性描述符

对象里目前存在的属性描述符有两种主要形式：数据描述符和存取描述符。

• 数据描述符是一个具有值的属性，该值可能是可写的，也可能不是可写的。
• 存取描述符是由 getter-setter 函数对描述的属性。

描述符必须是这两种形式之一；不能同时是两者。

数据描述符和存取描述符均具有以下可选键值：

configurable

当且仅当该属性的 configurable 为 true 时，该属性描述符才能够被改变，同时该属性也能从对应的对象上被删除。默认为 false。

enumerable

enumerable定义了对象的属性是否可以在 for...in 循环和 Object.keys() 中被枚举。

当且仅当该属性的 enumerable 为 true 时，该属性才能够出现在对象的枚举属性中。默认为 false。
数据描述符同时具有以下可选键值：

value

该属性对应的值。可以是任何有效的 JavaScript 值（数值，对象，函数等）。默认为 undefined。

writable

当且仅当该属性的 writable 为 true 时，value 才能被赋值运算符改变。默认为 false。

存取描述符同时具有以下可选键值：

get

一个给属性提供 getter 的方法，如果没有 getter 则为 undefined。该方法返回值被用作属性值。默认为 undefined。

set

一个给属性提供 setter 的方法，如果没有 setter 则为 undefined。该方法将接受唯一参数，并将该参数的新值分配给该属性。默认为 undefined。

如果一个描述符不具有value,writable,get 和 set 任意一个关键字，那么它将被认为是一个数据描述符。如果一个描述符同时有(value或writable)和(get或set)关键字，将会产生一个异常。

用法

类的装饰

@testable
class MyTestableClass {
  // ...
}

function testable(target) {
  target.isTestable = true;
}

MyTestableClass.isTestable // true

上面代码中，@testable 就是一个装饰器。它修改了 MyTestableClass这 个类的行为，为它加上了静态属性isTestable。testable 函数的参数 target 是 MyTestableClass 类本身。

基本上，装饰器的行为就是下面这样。

@decorator
class A {}

// 等同于

class A {}
A = decorator(A) || A;

也就是说，装饰器是一个对类进行处理的函数。装饰器函数的第一个参数，就是所要装饰的目标类。

如果觉得一个参数不够用，可以在装饰器外面再封装一层函数。

function testable(isTestable) {
  return function(target) {
    target.isTestable = isTestable;
  }
}

@testable(true)
class MyTestableClass {}
MyTestableClass.isTestable // true

@testable(false)
class MyClass {}
MyClass.isTestable // false

上面代码中，装饰器 testable 可以接受参数，这就等于可以修改装饰器的行为。

注意，装饰器对类的行为的改变，是代码编译时发生的，而不是在运行时。这意味着，装饰器能在编译阶段运行代码。也就是说，装饰器本质就是编译时执行的函数。

前面的例子是为类添加一个静态属性，如果想添加实例属性，可以通过目标类的 prototype 对象操作。

下面是另外一个例子。

// mixins.js
export function mixins(...list) {
  return function (target) {
    Object.assign(target.prototype, ...list)
  }
}

// main.js
import { mixins } from './mixins'

const Foo = {
  foo() { console.log('foo') }
};

@mixins(Foo)
class MyClass {}

let obj = new MyClass();
obj.foo() // 'foo'

上面代码通过装饰器 mixins，把Foo对象的方法添加到了 MyClass 的实例上面。

方法的装饰

装饰器不仅可以装饰类，还可以装饰类的属性。

class Person {
  @readonly
  name() { return `${this.first} ${this.last}` }
}

上面代码中，装饰器 readonly 用来装饰“类”的name方法。

装饰器函数 readonly 一共可以接受三个参数。

function readonly(target, name, descriptor){
  // descriptor对象原来的值如下
  // {
  //   value: specifiedFunction,
  //   enumerable: false,
  //   configurable: true,
  //   writable: true
  // };
  descriptor.writable = false;
  return descriptor;
}

readonly(Person.prototype, 'name', descriptor);
// 类似于
Object.defineProperty(Person.prototype, 'name', descriptor);

• 装饰器第一个参数是 类的原型对象，上例是 Person.prototype，装饰器的本意是要“装饰”类的实例，但是这个时候实例还没生成，所以只能去装饰原型（这不同于类的装饰，那种情况时target参数指的是类本身）；
• 第二个参数是 所要装饰的属性名
• 第三个参数是 该属性的描述对象

另外，上面代码说明，装饰器（readonly）会修改属性的 描述对象（descriptor），然后被修改的描述对象再用来定义属性。

函数方法的装饰

装饰器只能用于类和类的方法，不能用于函数，因为存在函数提升。

另一方面，如果一定要装饰函数，可以采用高阶函数的形式直接执行。

function doSomething(name) {
  console.log('Hello, ' + name);
}

function loggingDecorator(wrapped) {
  return function() {
    console.log('Starting');
    const result = wrapped.apply(this, arguments);
    console.log('Finished');
    return result;
  }
}

const wrapped = loggingDecorator(doSomething);

core-decorators.js

core-decorators.js是一个第三方模块，提供了几个常见的装饰器，通过它可以更好地理解装饰器。

@autoBind

autobind 装饰器使得方法中的this对象，绑定原始对象。

@readonly

readonly 装饰器使得属性或方法不可写。

@OverRide

override 装饰器检查子类的方法，是否正确覆盖了父类的同名方法，如果不正确会报错。

import { override } from 'core-decorators';

class Parent {
  speak(first, second) {}
}

class Child extends Parent {
  @override
  speak() {}
  // SyntaxError: Child#speak() does not properly override Parent#speak(first, second)
}

// or

class Child extends Parent {
  @override
  speaks() {}
  // SyntaxError: No descriptor matching Child#speaks() was found on the prototype chain.
  //
  //   Did you mean "speak"?
}

@deprecate (别名@deprecated)

deprecate 或 deprecated 装饰器在控制台显示一条警告，表示该方法将废除。

import { deprecate } from 'core-decorators';

class Person {
  @deprecate
  facepalm() {}

  @deprecate('We stopped facepalming')
  facepalmHard() {}

  @deprecate('We stopped facepalming', { url: 'http://knowyourmeme.com/memes/facepalm' })
  facepalmHarder() {}
}

let person = new Person();

person.facepalm();
// DEPRECATION Person#facepalm: This function will be removed in future versions.

person.facepalmHard();
// DEPRECATION Person#facepalmHard: We stopped facepalming

person.facepalmHarder();
// DEPRECATION Person#facepalmHarder: We stopped facepalming
//
//     See http://knowyourmeme.com/memes/facepalm for more details.
//

@SuppressWarnings

suppressWarnings 装饰器抑制 deprecated 装饰器导致的 console.warn() 调用。但是，异步代码发出的调用除外。

使用场景

装饰器有注释的作用

@testable
class Person {
  @readonly
  @nonenumerable
  name() { return `${this.first} ${this.last}` }
}