README

该文件用来测试和展示书写README的各种markdown语法。GitHub的markdown语法在标准的markdown语法基础上做了扩充，称之为GitHub Flavored Markdown。简称GFM，GFM在GitHub上有广泛应用，除了README文件外，issues和wiki均支持markdown语法。

###　　　　　　　　　　　　Author:果冻虾仁
###　　　　　　　　　 E-mail:[email protected]

===========================

##目录

• 横线
• 标题
• 文本
  • 普通文本
  • 单行文本
  • 多行文本
  • 文字高亮
  • 换行
  • 斜体
  • 粗体
  • 删除线
• 图片
  • 来源于网络的图片
  • GitHub仓库中的图片
• 链接
  • 文字超链接
    • 链接外部URL
    • 链接本仓库里的URL
  • 锚点
  • 图片链接
• 列表
  • 无序列表
  • 有序列表
  • 复选框列表
• 块引用
• 代码高亮
• 表格
• 表情

横线

***、---、___可以显示横线效果

标题

#一级标题
##二级标题
###三级标题
####四级标题
#####五级标题
######六级标题

文本

###普通文本
这是一段普通的文本
###单行文本

Hello,大家好，我是果冻虾仁。

在一行开头加入1个Tab或者4个空格。
###文本块
####语法1
在连续几行的文本开头加入1个Tab或者4个空格。

欢迎到访
很高兴见到您
祝您，早上好，中午好，下午好，晚安

####语法2
使用一对各三个的反引号：

欢迎到访
我是C++码农
你可以在知乎、CSDN、简书搜索【果冻虾仁】找到我

该语法也可以实现代码高亮，见代码高亮
###文字高亮
文字高亮功能能使行内部分文字高亮，使用一对反引号。
语法：

`linux` `网络编程` `socket` `epoll` 

效果：linux 网络编程 socket epoll

也适合做一篇文章的tag
####换行
直接回车不能换行，
可以在上一行文本后面补两个空格，
这样下一行的文本就换行了。

或者就是在两行文本直接加一个空行。

也能实现换行效果，不过这个行间距有点大。
####斜体、粗体、删除线

斜体、粗体、删除线可混合使用

图片

基本格式：

![alt](URL title)

alt和title即对应HTML中的alt和title属性（都可省略）：

• alt表示图片显示失败时的替换文本
• title表示鼠标悬停在图片时的显示文本（注意这里要加引号）

URL即图片的url地址，如果引用本仓库中的图片，直接使用相对路径就可了，如果引用其他github仓库中的图片要注意格式，即：仓库地址/raw/分支名/图片路径，如：

https://github.com/guodongxiaren/ImageCache/raw/master/Logo/foryou.gif

#	语法	效果
1	
2	![][foryou]

注意例2的写法使用了URL标识符的形式，在链接一节有介绍。

在文末有foryou的定义：

[foryou]:https://github.com/guodongxiaren/ImageCache/raw/master/Logo/foryou.gif

链接

###链接外部URL

语法2由两部分组成：

• 第一部分使用两个中括号，[ ]里的标识符（本例中zhihu），可以是数字，字母等的组合，标识符上下对应就行了（姑且称之为URL标识符）
• 第二部分标记实际URL。

使用URL标识符能达到复用的目的，一般把全文所有的URL标识符统一放在文章末尾，这样看起来比较干净。

URL标识符是我起的名字，不知道是否准确。囧。。

###链接本仓库里的URL

###图片链接
给图片加链接的本质是混合图片显示语法和普通的链接语法。普通的链接中[ ]内部是链接要显示的文本，而图片链接[ ]里面则是要显示的图片。
直接混合两种语法当然可以，但是十分啰嗦，为此我们可以使用URL标识符的形式。

#	语法	效果
1	[![weibo-logo]](http://weibo.com/linpiaochen)
2	[][zhihu]
3	[![csdn-logo]][csdn]

因为图片本身和链接本身都支持URL标识符的形式，所以图片链接也可以很简洁（见例3）。
注意，此时鼠标悬停时显示的文字是图片的title，而非链接本身的title了。

本文URL标识符都放置于文末

###锚点
其实呢，每一个标题都是一个锚点，和HTML的锚点（#）类似，比如我们

不过要注意，标题中的英文字母都被转化为小写字母了。

以前GitHub对中文支持的不好，所以中文标题不能正确识别为锚点，但是现在已经没问题啦！

##列表
###无序列表

• 昵称：果冻虾仁

• 别名：隔壁老王

• 英文名：Jelly

###多级无序列表

• 编程语言
  • 脚本语言
    • Python

###有序列表
####一般效果
就是在数字后面加一个点，再加一个空格。不过看起来起来可能不够明显。
面向对象的三个基本特征：

1. 封装
2. 继承
3. 多态

####有序列表自动排序
也可以在第一行指定1. ，而接下来的几行用星号*（或者继续用数字1. ）就可以了，它会自动显示成2、3、4……。
面向对象的七大原则：

1. 开闭原则

• 里氏转换原则
• 依赖倒转原则
• 接口隔离原则
• 组合/聚合复用原则
• “迪米特”法则
• 单一职责原则

####多级有序列表
和无序列表一样，有序列表也有多级结构：

1. 这是一级的有序列表，数字1还是1
   1. 这是二级的有序列表，阿拉伯数字在显示的时候变成了罗马数字
      1. 这是三级的有序列表，数字在显示的时候变成了英文字母
      2. 四级的有序列表显示效果，就不再变化了，依旧是英文字母

复选框列表

• 需求分析
• 系统设计
• 详细设计
• 编码
• 测试
• 交付

您可以使用这个功能来标注某个项目各项任务的完成情况。

Tip:

在GitHub的issue中使用该语法是可以实时点击复选框来勾选或解除勾选的，而无需修改issue原文。

##块引用

###常用于引用文本
####文本摘自《深入理解计算机系统》P27
　令人吃惊的是，在哪种字节顺序是合适的这个问题上，人们表现得非常情绪化。实际上术语“little endian”（小端）和“big endian”（大端）出自Jonathan Swift的《格利佛游记》一书，其中交战的两个派别无法就应该从哪一端打开一个半熟的鸡蛋达成一致。因此，争论沦为关于社会政治的争论。只要选择了一种规则并且始终如一的坚持，其实对于哪种字节排序的选择都是任意的。

“端”（endian）的起源
以下是Jonathan Swift在1726年关于大小端之争历史的描述：
“……下面我要告诉你的是，Lilliput和Blefuscu这两大强国在过去36个月里一直在苦战。战争开始是由于以下的原因：我们大家都认为，吃鸡蛋前，原始的方法是打破鸡蛋较大的一端，可是当今的皇帝的祖父小时候吃鸡蛋，一次按古法打鸡蛋时碰巧将一个手指弄破了，因此他的父亲，当时的皇帝，就下了一道敕令，命令全体臣民吃鸡蛋时打破较小的一端，违令者重罚。”

###块引用有多级结构

数据结构

树

二叉树

平衡二叉树

满二叉树

代码高亮

在三个反引号后面加上编程语言的名字，另起一行开始写代码，最后一行再加上三个反引号。

public static void main(String[]args){} //Java

int main(int argc, char *argv[]) //C

echo "hello GitHub" #Bash

document.getElementById("myH1").innerHTML="Welcome to my Homepage"; //javascipt

string &operator+(const string& A,const string& B) //cpp

表格

###对齐
表格可以指定对齐方式

###混合其他语法
表格单元中的内容可以和其他大多数GFM语法配合使用，如：
####使用普通文本的删除线，斜体等效果

图片	描述
	百度

表情

Github的Markdown语法支持添加emoji表情，输入不同的符号码（两个冒号包围的字符）可以显示出不同的表情。

比如:blush:，可以显示:blush:。

具体每一个表情的符号码，可以查询GitHub的官方网页http://www.emoji-cheat-sheet.com。

但是这个网页每次都打开奇慢。。所以我整理到了本repo中，大家可以直接在此查看emoji。

在单页应用上，前端路由并不陌生。很多前端框架也会有独立开发或推荐配套使用的路由系统。那么，当我们在谈前端路由的时候，还可以谈些什么？本文将简要分析并实现一个的前端路由，并对 react-router 进行分析。

一个极简前端路由的实现

说一下前端路由实现的简要原理，以 hash 形式（也可以使用 History API 来处理）为例，当 url 的 hash 发生变化时，触发 hashchange 注册的回调，回调中去进行不同的操作，进行不同的内容的展示。直接看代码或许更直观。

function Router() 
    this.routes = {};
    this.currentUrl = '';
}
Router.prototype.route = function(path, callback) {
    this.routes[path] = callback || function(){};
};
Router.prototype.refresh = function() {
    this.currentUrl = location.hash.slice(1) || '/';
    this.routes[this.currentUrl]();
};
Router.prototype.init = function() {
    window.addEventListener('load', this.refresh.bind(this), false);
    window.addEventListener('hashchange', this.refresh.bind(this), false);
}
window.Router = new Router();
window.Router.init();

上面路由系统 Router 对象实现，主要提供三个方法

init 监听浏览器 url hash 更新事件
route 存储路由更新时的回调到回调数组routes中，回调函数将负责对页面的更新
refresh 执行当前url对应的回调函数，更新页面
Router 调用方式以及呈现效果如下：点击触发 url 的 hash 改变，并对应地更新内容（这里为 body 背景色）

<ul> 
    <li><a href="#/">turn white</a></li> 
    <li><a href="#/blue">turn blue</a></li> 
    <li><a href="#/green">turn green</a></li> 
</ul> 
var content = document.querySelector('body');
// change Page anything
function changeBgColor(color) {
    content.style.backgroundColor = color;
}
Router.route('/', function() {
    changeBgColor('white');
});
Router.route('/blue', function() {
    changeBgColor('blue');
});
Router.route('/green', function() {
    changeBgColor('green');
});

20160513_150041
以上为一个前端路由的简单实现，点击查看完整代码，虽然简单，但实际上很多路由系统的根基都立于此，其他路由系统主要是对自身使用的框架机制的进行配套及优化，如与 react 配套的 react-router。

react-router 分析

react-router 与 history 结合形式

react-router 是基于 history 模块提供的 api 进行开发的，结合的形式本文记为 包装方式。所以在开始对其分析之前，先举一个简单的例子来说明如何进行对象的包装。

// 原对象

var historyModule = {
    listener: [],
    listen: function (listener) {
        this.listener.push(listener);
        console.log('historyModule listen..')
    },
    updateLocation: function(){
        this.listener.forEach(function(listener){
            listener('new localtion');
        })
    }
}
// Router 将使用 historyModule 对象，并对其包装
var Router = {
    source: {},
    init: function(source){
        this.source = source;
    },
    // 对 historyModule的listen进行了一层包装
    listen: function(listener) {
        return this.source.listen(function(location){
            console.log('Router listen tirgger.');
            listener(location);
        })
    }
}
// 将 historyModule 注入进 Router 中
Router.init(historyModule);
// Router 注册监听
Router.listen(function(location){
    console.log(location + '-> Router setState.');
})
// historyModule 触发回调
historyModule.updateLocation();

返回：
22

可看到 historyModule 中含有机制：historyModule.updateLocation() -> listener( )，Router 通过对其进行包装开发，针对 historyModule 的机制对 Router 也起到了作用，即historyModule.updateLocation() 将触发 Router.listen 中的回调函数 。点击查看完整代码
这种包装形式能够充分利用原对象（historyModule ）的内部机制，减少开发成本，也更好的分离包装函数（Router）的逻辑，减少对原对象的影响。

react-router 使用方式

react-router 以 react component 的组件方式提供 API， 包含 Router，Route，Redirect，Link 等等，这样能够充分利用 react component 提供的生命周期特性，同时也让定义路由跟写 react component 达到统一，如下

render((
  <Router history={browserHistory}>
    <Route path="/" component={App}>
      <Route path="about" component={About}/>
      <Route path="users" component={Users}>
        <Route path="/user/:userId" component={User}/>
      </Route>
      <Route path="*" component={NoMatch}/>
    </Route>
  </Router>
), document.body)

就这样，声明了一份含有 path to component 的各个映射的路由表。
react-router 还提供的 Link 组件（如下），作为提供更新 url 的途径，触发 Link 后最终将通过如上面定义的路由表进行匹配，并拿到对应的 component 及 state 进行 render 渲染页面。

从点击 Link 到 render 对应 component ，路由中发生了什么

为何能够触发 render component ？

主要是因为触发了 react setState 的方法从而能够触发 render component。
从顶层组件 Router 出发（下面代码从 react-router/Router 中摘取），可看到 Router 在 react component 生命周期之组件被挂载前 componentWillMount 中使用 this.history.listen 去注册了 url 更新的回调函数。回调函数将在 url 更新时触发，回调中的 setState 起到 render 了新的 component 的作用。

Router.prototype.componentWillMount = function componentWillMount() {
    // .. 省略其他
    var createHistory = this.props.history;

    this.history = _useRoutes2['default'](createHistory)({
      routes: _RouteUtils.createRoutes(routes || children),
      parseQueryString: parseQueryString,
      stringifyQuery: stringifyQuery
    });

    this._unlisten = this.history.listen(function (error, state) {
        _this.setState(state, _this.props.onUpdate);
    });
  };

上面的 _useRoutes2 对 history 操作便是对其做一层包装，所以调用的 this.history 实际为包装以后的对象，该对象含有 _useRoutes2 中的 listen 方法，如下

function listen(listener) {
      return history.listen(function (location) {
          // .. 省略其他
          match(location, function (error, redirectLocation, nextState) {
            listener(null, nextState);
          });
      });
}

可看到，上面代码中，主要分为两部分

使用了 history 模块的 listen 注册了一个含有 setState 的回调函数（这样就能使用 history 模块中的机制）
回调中的 match 方法为 react-router 所特有，match 函数根据当前 location 以及前面写的 Route 路由表匹配出对应的路由子集得到新的路由状态值 state，具体实现可见 react-router/matchRoutes ，再根据 state 得到对应的 component ，最终执行了 match 中的回调 listener(null, nextState) ，即执行了 Router 中的监听回调（setState），从而更新了展示。
以上，为起始注册的监听，及回调的作用。

如何触发监听的回调函数的执行？

这里还得从如何更新 url 说起。一般来说，url 更新主要有两种方式：简单的 hash 更新或使用 history api 进行地址更新。在 react-router 中，其提供了 Link 组件，该组件能在 render 中使用，最终会表现为 a 标签，并将 Link 中的各个参数组合放它的 href 属性中。可以从 react-router/ Link 中看到，对该组件的点击事件进行了阻止了浏览器的默认跳转行为，而改用 history 模块的 pushState 方法去触发 url 更新。

Link.prototype.render = function render() {
    // .. 省略其他
    props.onClick = function (e) {
      return _this.handleClick(e);
    };
    if (history) {
     // .. 省略其他
      props.href = history.createHref(to, query);
    }
    return _react2['default'].createElement('a', props);
};

Link.prototype.handleClick = function handleClick(event) {
    // .. 省略其他
    event.preventDefault();
    this.context.history.pushState(this.props.state, this.props.to, this.props.query);
};

对 history 模块的 pushState 方法对 url 的更新形式，同样分为两种，分别在 history/createBrowserHistory 及 history/createHashHistory 各自的 finishTransition 中，如 history/createBrowserHistory 中使用的是 window.history.replaceState(historyState, null, path); 而 history/createHashHistory 则使用 window.location.hash = url，调用哪个是根据我们一开始创建 history 的方式。

更新 url 的显示是一部分，另一部分是根据 url 去更新展示，也就是触发前面的监听。这是在前面 finishTransition 更新 url 之后实现的，调用的是 history/createHistory 中的 updateLocation 方法，changeListeners 中为 history/createHistory 中的 listen 中所添加的，如下

function updateLocation(newLocation) {
   // 示意代码
    location = newLocation;
    changeListeners.forEach(function (listener) {
      listener(location);
    });
}
function listen(listener) {
     // 示意代码
    changeListeners.push(listener);
}

总结

可以将以上 react-router 的整个包装闭环总结为

回调函数：含有能够更新 react UI 的 react setState 方法。
注册回调：在 Router componentWillMount 中使用 history.listen 注册的回调函数，最终放在 history 模块的 回调函数数组 changeListeners 中。
触发回调：Link 点击触发 history 中回调函数数组 changeListeners 的执行，从而触发原来 listen 中的 setState 方法，更新了页面
至于前进与后退的实现，是通过监听 popstate 以及 hashchange 的事件，当前进或后退 url 更新时，触发这两个事件的回调函数，回调的执行方式 Link 大致相同，最终同样更新了 UI ，这里就不再说明。

react-router 主要是利用底层 history 模块的机制，通过结合 react 的架构机制做一层包装，实际自身的内容并不多，但其包装的**笔者认为很值得学习，有兴趣的建议阅读下源码，相信会有其他收获。

前言

最近研究各大网站的font-family字体设置，发现每个网站的默认值都不相同，甚至一些大网站也犯了很明显的错误，说明字体还是有很大学问的，值的我们好好研究。

不同的操作系统、不同浏览器下内嵌的默认字体是不同的，错误的字体设置会导致页面在不同环境渲染的混乱，选择一套合适的字体是打造优秀网页的第一步。通过本文，我们会介绍字体的知识点，并探索在PC和Mobile两端该如何正确的设置字体。

字体基础知识

字体的分类

• serif(衬线)
• sans-serif(无衬线)
• monospace(等宽)
• fantasy(梦幻)
• cuisive(草体)

这些不是指某一个字体，而是一个字体族，是一系列字体的集合，我们接触最多的就是衬线字体和无衬线字体。

serif(衬线字体) & sans-serif(无衬线字体)

Serif的意思是，在字的笔划开始及结束的地方有额外的装饰，而且笔画的粗细会有所不同。衬线字体的风格都比较突出，常见的衬线字体有Times New Roman、宋体。

Sans Serif字体没有这些额外的装饰，笔划粗细大致差不多，字形端庄，横平竖直，常见的无衬线字体有Tahoma、Verdana、Arial、Helvetica、苹方、微软雅黑等等。

monospace(等宽字体)

等宽字体是指字符宽度相同的字体，通常用于编辑器以及技术文章的代码块中，等宽主要针对西文字体，而对于中文每个汉字都是等宽的，courier是最常见的等宽字体。

fantasy(梦幻字体) & cuisive(草书字体)

在浏览器中使用的场景不多，不多做介绍。

font-family属性

设置元素的字体，可以同时指定多个，如果浏览器不支持第一个字体，则会尝试下一个，可以设置字体或字体系列。

如：font-family: Arial, sans-serif;

如果不设置font-family则使用浏览器默认字体，如果设置的font-family无效，也会fallback到浏览器的默认字体。

常见字体介绍

Helvetica

苹果系统支持的一种西文无衬线字体，是苹果生态中最常用的一套西文字体。Helvetica Neue是Helvetica字体改善版本，增加了更多不同粗细与宽度的字形。

Arial

是为了与Helvetica竞争而设计的无衬线西文字体，表现形式和Helvetica类似，在不同系统的浏览器都支持，兼容性非常好。

Tahoma

一种无衬线字体，间距较小，在不同系统的浏览器都支持，兼容性良好，可以解决Helvetica和Arial所为人诟病的缺点，比如大写的 I 和小写的 L 难以分辨。

San Francisco

苹果于2017年推出一种无衬线字体，也是目前苹果系统的默认西文字体，相比于Helvetica字体，San Francisco的字体风格更加简洁，减少了一些修饰的细节，支持符号的整体居中，比如时间显示，之前的 Helvetica 的冒号是不居中的。

最低兼容版本：ios9、macOS10.11

PingFang SC(苹方-简)

苹果专为**用户打造的一个中文无衬线字体，在2017年和San Francisco一起推出，SC代表简体，同时还有**繁体和香港繁体，整体造型简洁美观，是苹果系统默认的中文字体。

最低兼容版本：ios9、macOS10.11

Hiragino Sans GB(冬青黑体)、Heiti SC(黑体)

苹果系统中较早的中文无衬线字体，为了兼容旧版macOS系统，我们一般用它们作为苹方字体的fallback。

Segoe UI

windows系统下的一种无衬线西文字体，也是windows系统的默认西文字体。

Microsoft YaHei(微软雅黑)

Windows系统默认的中文字体，也是一套无衬线字体。macOS上的浏览器大都预装微软雅黑，但不包括safari浏览器。

ios和android系统不支持微软雅黑，所以设置移动端字体时可以忽略微软雅黑。

宋体

一种中文衬线字体，windows 和 macOS都有支持，字体偏瘦，风格明显。

宋体也是windows XP及更早系统的默认中文字体。

WenQuanYi Micro Hei(文泉驿微米黑)

Linux系统下默认中文字体，一般为了兼容Linux系统才会设置这个字体。

Roboto

Android系统的默认西文字体，也是一种无衬线字体

Noto Sans (思源黑体)

Android系统的默认中文无衬线字体，由google推出的一款开源字体。

Apple Color Emoji

苹果产品的文字表情，在Mac和iOS系统中到处都可以看到，也是我们接触的最多的Emoji表情。

Segoe UI Emoji

Windows10系统中的Emoji表情，黑描边风格，没有苹果的圆润和质感。

Noto Color Emoji

Google推出的表情，和苹果的较为类似，更加扁平。

浏览器默认字体

默认字体分为系统默认字体和浏览器默认字体，这两者是不同的。

这里我们讨论的是浏览器默认字体，系统默认字体会在下面的system-ui中介绍。

当元素没有指定font-family或者设置的font-family无效时，会fallback到浏览器默认字体。

PC端

PC端的浏览器支持设置不同的默认字体。

下图是chrome的配置选项，标准字体就是默认字体，当font-family属性没有设置时会启用这个字体。

因为Arial是西文字体，对中文无效，浏览器会选择合适的中文字体，在Windows上一般为微软雅黑，在macOS一般为苹方。但是部分浏览器会根据默认字体的风格选择近似的中文字体，Arial是无衬线字体，浏览器也会选择一种无衬线字体适配中文，如果默认字体是衬线字体，那么浏览器就会选择一种衬线中文字体，为了抹平这种差异，我们通常在font-family最后设置sans-serif指定无衬线字体作为兜底。

移动端

移动端浏览器通常不支持指定默认字体。

ios的默认中文字体为苹方，当lang设置为zh-CN，西文也是苹方。当lang不设置或者设置为en时，西文默认字体为Times New Roman，一种衬线字体。

<!DOCTYPE html>
<html lang='zh-CN'>
...

android的字体稍微复杂，它的的默认字体为西文：Roboto，中文：Noto Sans (思源黑体)，但不同厂商可能会使用自定义的字体，比如小米部分手机使用的是小米兰亭。

android端lang设置为zh-CN或en时表现也有可能不同，虽然都是无衬线字体，但差异很明显。即便lang都设置为zh-CN，不同的安卓机上的默认西文字体表现也有可能是不同的，一个字形容：乱。

以上提到的移动端系统版本：ios9+ android4+

正是由于浏览器默认字体的复杂体现出设置font-family的重要性。

system-ui

system-ui是一种通用字体系列，它选择当前操作系统下的默认系统字体，它的优势在于和当前系统使用的字体相匹配，可以让Web页面和App风格看起来更统一。

使用方式

font-family: system-ui;

兼容性

system-ui推出的时间较晚，但兼容性比较不错，目前主流的浏览器都已经支持。

下图是Can I Use上统计的兼容信息

-apple-system
-apple-system是system-ui的兼容写法，只在ios和macOS上的safari、Firefox、webview等环境下支持。

BlinkMacSystemFont
也是system-ui的兼容写法，只在macOS chrome下支持，主要针对chrome 53-55版本

效果

在ios和macOS上，system-ui指向的中文字体为苹方，西文字体为San Francisco。android系统下中文通常为Noto Sans (思源黑体)，西文字体为Roboto。windows系统上一般为微软雅黑，但是在部分windows系统上的字体会出现问题，所以windows上不建议使用system-ui。

sans-serif(无衬线字体)

在现行主流终端设备中，无衬线体比有衬线体更易读，无衬线体更适合作为网页的默认全局字体设置。

每个系统都会带有无衬线字体，所以sans-serif一般放在最后作为兜底，sans-serif之后的字体都不会生效，除了Emoji字体。

PC端浏览器可以在设置中指定sans-serif字体。

移动端浏览器不能在设置中指定sans-serif字体，它们会根据lang指定的语言环境选择合适的字体，和system-ui指定的字体不一定相同。

书写字体规则

在介绍字体规则前，有几点是需要注意的：

1、不同平台，预置的字体并不相同。比如Helvetica和苹方也只有苹果系统内置，微软雅黑只有windows系统内置(由于很多人安装Office的缘故，Mac电脑中也会出现微软雅黑字体)，android 和 iOS 系统内置的字体各不相同。

2、字体是有版权的，但是如果没有引用外部字体文件（如 Web font 或者内嵌到 App 中），而仅仅是在 CSS 中指定字体名称，不需要购买授权，因为其只是一段声明，表示期望浏览器优先使用某种字体渲染文本。

3、中文网站涉及两种文字类型：西文字体和中文字体，西文字体包括英文数字等，不包括中文，但是中文字体一般包括英文和数字，我们一般先设置西文字体，后设置中文。

4、如果字体包含空格或者是中文，需要添加引号。

5、大部分字体全名中会包含字体粗细、斜体（italic）、长体（condensed）等具体属性，但一般不建议直接使用，字体的风格应该在 CSS 中通过 font-weight、font-style、font-stretch等属性指定，由浏览器决定实际渲染的字体。

6、font-family属于可继承属性，全局的font-family一般设置在body元素上。

我们可以总结字体定义的大概规则如下：

1、西文在前，中文在后

中文字体大多都包含西文，但西文的部分又不好看，而西文不包含中文，通常先定义西文，后定义中文以达到更优的显示效果。

2、优先使用system-ui

system-ui使用当前系统的默认字体，让web页面和操作系统的风格统一，体验更好。

3、兼顾不同的操作系统

选择字体的时候要考虑不同的操作系统，还需要考虑旧版本操作系统的用户。

即便是同一个字体在不同的操作下也会有细微的差别，我们要尽量做到相同系统使用同一种字体，保证同一个系统下的字体一致性。对于不同系统尽量保证字体风格接近，比如都使用无衬线字体。

为了保证苹果系统中使用更优雅的中文字体，优先声明苹方字体, 对于不支持苹方的低版本macOS，使用Hiragino Sans GB(冬青黑体)字体做兜底。

如果需要兼容Linux系统，还需要添加WenQuanYi Micro Hei(文泉驿微米黑)字体。

如果需要兼容不同平台的表情符号，一般在sans-serif后添加"Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"等字体。

4、以serif或sans-serif字体族结尾

为了保证在各种不同环境或条件下显示正常，我们一般将sans-serif放在字体的后面，非衬线字体在显示器中的显示效果更好。

5、简洁实用

字体设置并不是越多越好，在能满足设计需求的情况下尽量简洁。相同系统下中西文字体各有一个fallback即可，不需要太多。

字体设置

通过字体的知识点和字体设置规范介绍，我们总结出全局默认字体的设置方式。

移动端

兼容版本：ios9+、android4+

推荐写法：

font-family: system-ui, -apple-system, Arial, sans-serif;

解读：优先使用system-ui，使用Arial做西文字体的fallback是因为它和Helvetica字体相似，并且在ios和android支持性很好。

PC端

推荐写法1：
macOS系统优先使用系统字体

font-family: -apple-system, BlinkMacSystemFont, Tahoma, Arial, "Hiragino Sans GB", "Microsoft YaHei", sans-serif;

推荐写法2：
指定字体

font-family: Tahoma, Arial, "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif;

windows系统电脑屏幕分辨率普遍不高，Tahoma字体在小字号下结构清晰端整、阅读辨识容易，在不同操作系统支持性好，所以作为首选字体，如果系统没有预装Tahoma，则使用Arial作为替代。但两者差别不大，Arial优先级提前也行。

需要需要兼容Linux系统和表情符号，可以添加WenQuanYi Micro Hei和Emoji字体，如：

font-family: -apple-system, BlinkMacSystemFont, Tahoma, Arial, "Hiragino Sans GB", "Microsoft YaHei", "WenQuanYi Micro Hei", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";

如想突出macOS和windows的字体特色，可以在Tahoma前面设置Helvetica或Segoe UI为首选字体，如：

font-family: "Helvetica Neue", "Segoe UI", Arial, "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif;

注意：

1、字体的设置没有固定标准，需要根据业务情况进行定夺，以上只是推荐写法，如果设计师有要求可以在此基础上进行改动。

2、css的font-family权重是高于浏览器默认字体的，有一些网站选择不设置font-family，使用浏览器的默认字体，倾向于用户的选择，这就是仁者见仁了。

指定元素字体

当给某个元素设置了font-faimily后，全局默认字体则对这个元素无效，这时也要考虑字体兼容问题，最好指定一个fallback字体，并以sans-serif结尾。

div {
    font-faimiy: "PingFang SC", sans-serif;
}

各大网站font-family点评

首先声明，以下仅为个人观点，如有错误欢迎指出🙂

以下数据取值时间：2020-11-25

淘宝首页

tahoma,arial,'Hiragino Sans GB',\5b8b\4f53,sans-serif

\5b8b\4f53为宋体的Unicode编码，这样可以有效的避免浏览器解释CSS代码时候出现乱码的问题。
淘宝首页的默认字体非常简洁，但是在macOS上使用的中文字体为无衬线的冬青黑体，而在windows上使用的是衬线字体宋体，两个系统字体表现差异还是很明显的。

京东首页

Microsoft YaHei,Heiti SC,tahoma,arial,Hiragino Sans GB,"\5B8B\4F53",sans-serif

京东首页使用微软雅黑作为首选字体，这样中英文都会为微软雅黑，在macOS safari默认是不支持微软雅黑所以会fallback到Heiti SC(黑体)，而黑体作为较早版本macOS的默认中文字体因为喇叭口设计被诟病已久。当然京东这么设置肯定是有他们的考虑，但是中文字体放在tahoma、arial等西文字体前还是不建议的，除非设计师或业务要求。

天猫首页

"Microsoft YaHei",SimSun,'\5b8b\4f53',sans-serif

SimSun：也是宋体

天猫首页默认字体设置和京东类似，首选中英文都是微软雅黑，上面说到过macOS safari默认是不支持微软雅黑，所以会fallback到宋体，宋体是衬线字体，导致macOS上其它浏览器和safari浏览器字体差异很大。

下图分别为macOS10.14.5下，chrome和safari的效果

腾讯网首页

'Microsoft Yahei', 'PingFang SC', 'Avenir', 'Segoe UI', 'Hiragino Sans GB', STHeiti, 'Microsoft Sans Serif', 'WenQuanYi Micro Hei', sans-serif

腾讯网首页也是以微软雅黑作为中西文首选字体，并且在不同系统上都有相应的fallback，理论上是不错的，但还如同上面所说，除非设计师或业务需要，不建议以中文字体开头。

新浪微博

Arial,"PingFang SC","Hiragino Sans GB","Microsoft YaHei","WenQuanYi Micro Hei",sans-serif

新浪微博的默认字体个人觉得是非常好的。

掘金首页

-apple-system,system-ui,Segoe UI,Roboto,Ubuntu,Cantarell,Noto Sans,sans-serif,BlinkMacSystemFont,Helvetica Neue,PingFang SC,Hiragino Sans GB,Microsoft YaHei,Arial

掘金这里犯了一个非常明显的错误，在sans-serif后定义了其它中英文字体，因为sans-serif后定义的中英文字体都是无效的。掘金作为大神云集的地方，犯这么低级的错误实在不应该。

segmentfault首页

-apple-system,"Helvetica Neue",Helvetica,Arial,"PingFang SC","Hiragino Sans GB","WenQuanYi Micro Hei","Microsoft Yahei",sans-serif

个人觉得很好。

知乎首页

-apple-system,BlinkMacSystemFont,Helvetica Neue,PingFang SC,Microsoft YaHei,Source Han Sans SC,Noto Sans CJK SC,WenQuanYi Micro Hei,sans-serif

Source Han Sans SC、Noto Sans CJK SC这两个都是思源黑体，虽然是开源字体，但是在大部分系统中都没有内置，这里设置是不是没必要？

头条首页

PingFang SC,Hiragino Sans GB,Microsoft YaHei,WenQuanYi Micro Hei,Helvetica Neue,Arial,sans-serif

也是如同上面提到的，Helvetica Neue,Arial等西文字体建议放在前面。

在此重申，以上仅是个人经验观点，如有错误欢迎指出🙂

参考链接

Web 字体 font-family 再探秘

你该知道的字体 font-family

字体，以及 font-family

如何优雅的选择字体(font-family)

从Web字体谈起——默认字体样式设置

PingFang SC 不应该作为移动端网页字体的首选项

iOS 9 字体的介绍与使用

做React需要会什么？

react的功能其实很单一，主要负责渲染的功能，现有的框架，比如angular是一个大而全的框架，用了angular几乎就不需要用其他工具辅助配合，但是react不一样，他只负责ui渲染，想要做好一个项目，往往需要其他库和工具的配合，比如用redux来管理数据，react-router管理路由，react已经全面拥抱es6，所以es6也得掌握，webpack就算是不会配置也要会用，要想提高性能，需要按需加载，immutable.js也得用上，还有单元测试。。。。

##React 是什么
用脚本进行DOM操作的代价很昂贵。有个贴切的比喻，把DOM和JavaScript各自想象为一个岛屿，它们之间用收费桥梁连接，js每次访问DOM，都要途径这座桥，并交纳“过桥费”,访问DOM的次数越多，费用也就越高。 因此，推荐的做法是尽量减少过桥的次数，努力待在ECMAScript岛上。因为这个原因react的虚拟dom就显得难能可贵了，它创造了虚拟dom并且将它们储存起来，每当状态发生变化的时候就会创造新的虚拟节点和以前的进行对比，让变化的部分进行渲染。整个过程没有对dom进行获取和操作，只有一个渲染的过程，所以react说是一个ui框架。

##React的组件化

react的一个组件很明显的由dom视图和state数据组成，两个部分泾渭分明。state是数据中心，它的状态决定着视图的状态。这时候发现似乎和我们一直推崇的MVC开发模式有点区别，没了Controller控制器，那用户交互怎么处理，数据变化谁来管理？然而这并不是react所要关心的事情，它只负责ui的渲染。与其他框架监听数据动态改变dom不同，react采用setState来控制视图的更新。setState会自动调用render函数，触发视图的重新渲染，如果仅仅只是state数据的变化而没有调用setState，并不会触发更新。 组件就是拥有独立功能的视图模块，许多小的组件组成一个大的组件，整个页面就是由一个个组件组合而成。它的好处是利于重复利用和维护。

##React的 Diff算法
react的diff算法用在什么地方呢？当组件更新的时候，react会创建一个新的虚拟dom树并且会和之前储存的dom树进行比较，这个比较多过程就用到了diff算法，所以组件初始化的时候是用不到的。react提出了一种假设，相同的节点具有类似的结构，而不同的节点具有不同的结构。在这种假设之上进行逐层的比较，如果发现对应的节点是不同的，那就直接删除旧的节点以及它所包含的所有子节点然后替换成新的节点。如果是相同的节点，则只进行属性的更改。

对于列表的diff算法稍有不同，因为列表通常具有相同的结构，在对列表节点进行删除，插入，排序的时候，单个节点的整体操作远比一个个对比一个个替换要好得多，所以在创建列表的时候需要设置key值，这样react才能分清谁是谁。当然不写key值也可以，但这样通常会报出警告，通知我们加上key值以提高react的性能。

##React组件是怎么来的

组件的创造方法为React.createClass() ——创造一个类，react系统内部设计了一套类系统，利用它来创造react组件。但这并不是必须的，我们还可以用es6的class类来创造组件,这也是Facebook官方推荐的写法。

这两种写法实现的功能一样但是原理却是不同，es6的class类可以看作是构造函数的一个语法糖，可以把它当成构造函数来看，extends实现了类之间的继承 —— 定义一个类Main 继承React.Component所有的属性和方法，组件的生命周期函数就是从这来的。constructor是构造器，在实例化对象时调用，super调用了父类的constructor创造了父类的实例对象this，然后用子类的构造函数进行修改。这和es5的原型继承是不同的，原型继承是先创造一个实例化对象this，然后再继承父级的原型方法。了解了这些之后我们在看组件的时候就清楚很多。

当我们使用组件< Main />时，其实是对Main类的实例化——new Main，只不过react对这个过程进行了封装，让它看起来更像是一个标签。

有三点值得注意：1、定义类名字的首字母必须大写 2、因为class变成了关键字，类选择器需要用className来代替。 3、类和模块内部默认使用严格模式，所以不需要用use strict指定运行模式。

组件的生命周期

组件在初始化时会触发5个钩子函数：

1、getDefaultProps()

设置默认的props，也可以用dufaultProps设置组件的默认属性。

2、getInitialState()

在使用es6的class语法时是没有这个钩子函数的，可以直接在constructor中定义this.state。此时可以访问this.props。

3、componentWillMount()

组件初始化时只调用，以后组件更新不调用，整个生命周期只调用一次，此时可以修改state。

4、 render()

react最重要的步骤，创建虚拟dom，进行diff算法，更新dom树都在此进行。此时就不能更改state了。

5、componentDidMount()

组件渲染之后调用，可以通过this.getDOMNode()获取和操作dom节点，只调用一次。

在更新时也会触发5个钩子函数：

6、componentWillReceivePorps(nextProps)

组件初始化时不调用，组件接受新的props时调用。

7、shouldComponentUpdate(nextProps, nextState)

react性能优化非常重要的一环。组件接受新的state或者props时调用，我们可以设置在此对比前后两个props和state是否相同，如果相同则返回false阻止更新，因为相同的属性状态一定会生成相同的dom树，这样就不需要创造新的dom树和旧的dom树进行diff算法对比，节省大量性能，尤其是在dom结构复杂的时候。不过调用this.forceUpdate会跳过此步骤。

8、componentWillUpdata(nextProps, nextState)

组件初始化时不调用，只有在组件将要更新时才调用，此时可以修改state

9、render()

不多说

10、componentDidUpdate()

组件初始化时不调用，组件更新完成后调用，此时可以获取dom节点。

还有一个卸载钩子函数

11、componentWillUnmount()

组件将要卸载时调用，一些事件监听和定时器需要在此时清除。

以上可以看出来react总共有10个周期函数（render重复一次），这个10个函数可以满足我们所有对组件操作的需求，利用的好可以提高开发效率和组件性能。

React-Router路由

Router就是React的一个组件，它并不会被渲染，只是一个创建内部路由规则的配置对象，根据匹配的路由地址展现相应的组件。Route则对路由地址和组件进行绑定，Route具有嵌套功能，表示路由地址的包涵关系，这和组件之间的嵌套并没有直接联系。Route可以向绑定的组件传递7个属性：children，history，location，params，route，routeParams，routes，每个属性都包涵路由的相关的信息。比较常用的有children（以路由的包涵关系为区分的组件），location（包括地址，参数，地址切换方式，key值，hash值）。react-router提供Link标签，这只是对a标签的封装，值得注意的是，点击链接进行的跳转并不是默认的方式，react-router阻止了a标签的默认行为并用pushState进行hash值的转变。切换页面的过程是在点击Link标签或者后退前进按钮时，会先发生url地址的转变，Router监听到地址的改变根据Route的path属性匹配到对应的组件，将state值改成对应的组件并调用setState触发render函数重新渲染dom。

当页面比较多时，项目就会变得越来越大，尤其对于单页面应用来说，初次渲染的速度就会很慢，这时候就需要按需加载，只有切换到页面的时候才去加载对应的js文件。react配合webpack进行按需加载的方法很简单，Route的component改为getComponent，组件用require.ensure的方式获取，并在webpack中配置chunkFilename。

const chooseProducts = (location, cb) => {
    require.ensure([], require => {
        cb(null, require('../Component/chooseProducts').default)
    },'chooseProducts')
}

const helpCenter = (location, cb) => {
    require.ensure([], require => {
        cb(null, require('../Component/helpCenter').default)
    },'helpCenter')
}

const saleRecord = (location, cb) => {
    require.ensure([], require => {
        cb(null, require('../Component/saleRecord').default)
    },'saleRecord')
}

const RouteConfig = (
    <Router history={history}>
        <Route path="/" component={Roots}>
            <IndexRoute component={index} />//首页
            <Route path="index" component={index} />
            <Route path="helpCenter" getComponent={helpCenter} />//帮助中心
            <Route path="saleRecord" getComponent={saleRecord} />//销售记录
            <Redirect from='*' to='/'  />
        </Route>
    </Router>
);

组件之间的通信

react推崇的是单向数据流，自上而下进行数据的传递，但是由下而上或者不在一条数据流上的组件之间的通信就会变的复杂。解决通信问题的方法很多，如果只是父子级关系，父级可以将一个回调函数当作属性传递给子级，子级可以直接调用函数从而和父级通信。

组件层级嵌套到比较深，可以使用上下文getChildContext来传递信息，这样在不需要将函数一层层往下传，任何一层的子级都可以通过this.context直接访问。

兄弟关系的组件之间无法直接通信，它们只能利用同一层的上级作为中转站。而如果兄弟组件都是最高层的组件，为了能够让它们进行通信，必须在它们外层再套一层组件，这个外层的组件起着保存数据，传递信息的作用，这其实就是redux所做的事情。

组件之间的信息还可以通过全局事件来传递。不同页面可以通过参数传递数据，下个页面可以用location.param来获取。其实react本身很简单，难的在于如何优雅高效的实现组件之间数据的交流。

Redux

首先，redux并不是必须的，它的作用相当于在顶层组件之上又加了一个组件，作用是进行逻辑运算、储存数据和实现组件尤其是顶层组件的通信。如果组件之间的交流不多，逻辑不复杂，只是单纯的进行视图的渲染，这时候用回调，context就行，没必要用redux，用了反而影响开发速度。但是如果组件交流特别频繁，逻辑很复杂，那redux的优势就特别明显了。我第一次做react项目的时候并没有用redux，所有的逻辑都是在组件内部实现，当时为了实现一个逻辑比较复杂的购物车，洋洋洒洒居然写了800多行代码，回头一看我自己都不知道写的是啥，画面太感人。

先简单说一下redux和react是怎么配合的。react-redux提供了connect和Provider两个好基友，它们一个将组件与redux关联起来，一个将store传给组件。组件通过dispatch发出action，store根据action的type属性调用对应的reducer并传入state和这个action，reducer对state进行处理并返回一个新的state放入store，connect监听到store发生变化，调用setState更新组件，此时组件的props也就跟着变化。

流程是这个样子的：

值得注意的是connect，Provider，mapStateToProps,mapDispatchToProps是react-redux提供的，redux本身和react没有半毛钱关系，它只是数据处理中心，没有和react产生任何耦合，是react-redux让它们联系在一起。

####接下来具体分析一下，redux以及react-redux到底是怎么实现的。

先上一张图

明显比第一张要复杂，其实两张图说的是同一件事。从上而下慢慢分析：

###先说说redux：

####redux主要由三部分组成：store，reducer，action。

store是一个对象，它有四个主要的方法：

1、dispatch:

用于action的分发——在createStore中可以用middleware中间件对dispatch进行改造，比如当action传入dispatch会立即触发reducer，有些时候我们不希望它立即触发，而是等待异步操作完成之后再触发，这时候用redux-thunk对dispatch进行改造，以前只能传入一个对象，改造完成后可以传入一个函数，在这个函数里我们手动dispatch一个action对象，这个过程是可控的，就实现了异步。

2、subscribe：

监听state的变化——这个函数在store调用dispatch时会注册一个listener监听state变化，当我们需要知道state是否变化时可以调用，它返回一个函数，调用这个返回的函数可以注销监听。
let unsubscribe = store.subscribe(() => {console.log('state发生了变化')})

3、getState：

获取store中的state——当我们用action触发reducer改变了state时，需要再拿到新的state里的数据，毕竟数据才是我们想要的。getState主要在两个地方需要用到，一是在dispatch拿到action后store需要用它来获取state里的数据，并把这个数据传给reducer，这个过程是自动执行的，二是在我们利用subscribe监听到state发生变化后调用它来获取新的state数据，如果做到这一步，说明我们已经成功了。

4、replaceReducer:

替换reducer，改变state修改的逻辑。

store可以通过createStore()方法创建，接受三个参数，经过combineReducers合并的reducer和state的初始状态以及改变dispatch的中间件，后两个参数并不是必须的。store的主要作用是将action和reducer联系起来并改变state。

action:

action是一个对象，其中type属性是必须的，同时可以传入一些数据。action可以用actionCreactor进行创造。dispatch就是把action对象发送出去。

reducer:

reducer是一个函数，它接受一个state和一个action，根据action的type返回一个新的state。根据业务逻辑可以分为很多个reducer，然后通过combineReducers将它们合并，state树中有很多对象，每个state对象对应一个reducer，state对象的名字可以在合并时定义。

像这个样子：

const reducer = combineReducers({
     a: doSomethingWithA,
     b: processB,
     c: c
})

combineReducers:

其实它也是一个reducer，它接受整个state和一个action，然后将整个state拆分发送给对应的reducer进行处理，所有的reducer会收到相同的action，不过它们会根据action的type进行判断，有这个type就进行处理然后返回新的state，没有就返回默认值，然后这些分散的state又会整合在一起返回一个新的state树。

接下来分析一下整体的流程，首先调用store.dispatch将action作为参数传入，同时用getState获取当前的状态树state并注册subscribe的listener监听state变化，再调用combineReducers并将获取的state和action传入。combineReducers会将传入的state和action传给所有reducer，reducer会根据state的key值获取与自己对应的state，并根据action的type返回新的state，触发state树的更新，我们调用subscribe监听到state发生变化后用getState获取新的state数据。

redux的state和react的state两者完全没有关系，除了名字一样。

上面分析了redux的主要功能，那么react-redux到底做了什么？

React-Redux

如果只使用redux，那么流程是这样的：

component --> dispatch(action) --> reducer --> subscribe --> getState --> component

用了react-redux之后流程是这样的：

component --> actionCreator(data) --> reducer --> component

store的三大功能：dispatch，subscribe，getState都不需要手动来写了。react-redux帮我们做了这些，同时它提供了两个好基友Provider和connect。

Provider是一个组件，它接受store作为props，然后通过context往下传，这样react中任何组件都可以通过contex获取store。也就意味着我们可以在任何一个组件里利用dispatch(action)来触发reducer改变state，并用subscribe监听state的变化，然后用getState获取变化后的值。但是并不推荐这样做，它会让数据流变的混乱，过度的耦合也会影响组件的复用，维护起来也更麻烦。

**connect --connect(mapStateToProps, mapDispatchToProps, mergeProps, options)**是一个函数，它接受四个参数并且再返回一个函数--wrapWithConnect，wrapWithConnect接受一个组件作为参数wrapWithConnect(component)，它内部定义一个新组件Connect(容器组件)并将传入的组件(ui组件)作为Connect的子组件然后return出去。

所以它的完整写法是这样的：connect(mapStateToProps, mapDispatchToProps, mergeProps, options)(component)

mapStateToProps(state, [ownProps])：

mapStateToProps 接受两个参数，store的state和自定义的props，并返回一个新的对象，这个对象会作为props的一部分传入ui组件。我们可以根据组件所需要的数据自定义返回一个对象。ownProps的变化也会触发mapStateToProps

function mapStateToProps(state) {
   return { todos: state.todos };
}

mapDispatchToProps(dispatch, [ownProps])：

mapDispatchToProps如果是对象，那么会和store绑定作为props的一部分传入ui组件。如果是个函数，它接受两个参数，bindActionCreators会将action和dispatch绑定并返回一个对象，这个对象会和ownProps一起作为props的一部分传入ui组件。所以不论mapDispatchToProps是对象还是函数，它最终都会返回一个对象，如果是函数，这个对象的key值是可以自定义的

function mapDispatchToProps(dispatch) {
   return {
      todoActions: bindActionCreators(todoActionCreators, dispatch),
      counterActions: bindActionCreators(counterActionCreators, dispatch)
   };
}

mapDispatchToProps返回的对象其属性其实就是一个个actionCreator，因为已经和dispatch绑定，所以当调用actionCreator时会立即发送action，而不用手动dispatch。ownProps的变化也会触发mapDispatchToProps。

mergeProps(stateProps, dispatchProps, ownProps)：

将mapStateToProps() 与 mapDispatchToProps()返回的对象和组件自身的props合并成新的props并传入组件。默认返回 Object.assign({}, ownProps, stateProps, dispatchProps) 的结果。

options：

pure = true 表示Connect容器组件将在shouldComponentUpdate中对store的state和ownProps进行浅对比，判断是否发生变化，优化性能。为false则不对比。

其实connect函数并没有做什么，大部分的逻辑都是在它返回的wrapWithConnect函数内实现的，确切的说是在wrapWithConnect内定义的Connect组件里实现的。

###下面是一个完整的 react --> redux --> react 流程：

一、Provider组件接受redux的store作为props，然后通过context往下传。

二、connect函数在初始化的时候会将mapDispatchToProps对象绑定到store，如果mapDispatchToProps是函数则在Connect组件获得store后，根据传入的store.dispatch和action通过bindActionCreators进行绑定，再将返回的对象绑定到store，connect函数会返回一个wrapWithConnect函数，同时wrapWithConnect会被调用且传入一个ui组件，wrapWithConnect内部使用class Connect extends Component定义了一个Connect组件，传入的ui组件就是Connect的子组件，然后Connect组件会通过context获得store，并通过store.getState获得完整的state对象，将state传入mapStateToProps返回stateProps对象、mapDispatchToProps对象或mapDispatchToProps函数会返回一个dispatchProps对象，stateProps、dispatchProps以及Connect组件的props三者通过Object.assign()，或者mergeProps合并为props传入ui组件。然后在ComponentDidMount中调用store.subscribe，注册了一个回调函数handleChange监听state的变化。

三、此时ui组件就可以在props中找到actionCreator，当我们调用actionCreator时会自动调用dispatch，在dispatch中会调用getState获取整个state，同时注册一个listener监听state的变化，store将获得的state和action传给combineReducers，combineReducers会将state依据state的key值分别传给子reducer，并将action传给全部子reducer，reducer会被依次执行进行action.type的判断，如果有则返回一个新的state，如果没有则返回默认。combineReducers再次将子reducer返回的单个state进行合并成一个新的完整的state。此时state发生了变化。Connect组件中调用的subscribe会监听到state发生了变化，然后调用handleChange函数，handleChange函数内部首先调用getState获取新的state值并对新旧两个state进行浅对比，如果相同直接return，如果不同则调用mapStateToProps获取stateProps并将新旧两个stateProps进行浅对比，如果相同，直接return结束，不进行后续操作。如果不相同则调用this.setState()触发Connect组件的更新，传入ui组件，触发ui组件的更新，触发ui组件的更新，此时ui组件获得新的props，react --> redux --> react 的一次流程结束。

上面的有点复杂，简化版的流程是：

一、Provider组件接受redux的store作为props，然后通过context往下传。

二、connect函数收到Provider传出的store，然后接受三个参数mapStateToProps，mapDispatchToProps和组件，并将state和actionCreator以props传入组件，这时组件就可以调用actionCreator函数来触发reducer函数返回新的state，connect监听到state变化调用setState更新组件并将新的state传入组件。

connect可以写的非常简洁，mapStateToProps，mapDispatchToProps只不过是传入的回调函数，connect函数在必要的时候会调用它们，名字不是固定的，甚至可以不写名字。

简化版本：

connect(state => state, action)(Component);

##项目搭建

上面说了react，react-router和redux的知识点。但是怎么样将它们整合起来，搭建一个完整的项目。

1、先引用 react.js，redux，react-router 等基本文件，建议用npm安装，直接在文件中引用。

2、从 react.js，redux，react-router 中引入所需要的对象和方法。

import React, {Component, PropTypes} from 'react';
import ReactDOM, {render} from 'react-dom';
import {Provider, connect} from 'react-redux';
import {createStore, combineReducers, applyMiddleware} from 'redux';
import { Router, Route, Redirect, IndexRoute, browserHistory, hashHistory } from 'react-router';

3、根据需求创建顶层ui组件，每个顶层ui组件对应一个页面。

4、创建actionCreators和reducers，并用combineReducers将所有的reducer合并成一个大的reduer。利用createStore创建store并引入combineReducers和applyMiddleware。

5、利用connect将actionCreator，reuder和顶层的ui组件进行关联并返回一个新的组件。

6、利用connect返回的新的组件配合react-router进行路由的部署，返回一个路由组件Router。

7、将Router放入最顶层组件Provider，引入store作为Provider的属性。

8、调用render渲染Provider组件且放入页面的标签中。

可以看到顶层的ui组件其实被套了四层组件，Provider，Router，Route，Connect，这四个组件并不会在视图上改变react，它们只是功能性的。

通常我们在顶层的ui组件打印props时可以看到一堆属性：

上图的顶层ui组件属性总共有18个，如果刚刚接触react，可能对这些属性怎么来的感到困惑，其实这些属性来自五个地方：

组件自定义属性1个，actionCreator返回的对象6个，reducer返回的state4个，Connect组件属性0个，以及Router注入的属性7个。