什么是CSS Modules？
根据官方的repository介绍，CSS Modules是：
所有的class的名称和动画的名称默认属于本地作用域的CSS文件。所以CSS Modules不是一个官方的规范，也不是浏览器的一种机制，它是一种构建步骤中的一个进程。（构建通常需要webpack或者browserify的帮助）。通过构建工具的帮助，可以将class的名字或者选择器的名字作用域化。（类似命名空间化。）
这到底是什么呢？我们为什么要这么做呢？我们很快就进行介绍。首先，不要忘记HTML和CSS的工作原理。在HTML中一个类添加：
<h1 class="title">An example heading</h1>
在CSS中这个class的定义如下：
.title { background-color: red; }
只要CSS被添加到HTML文档上，那个<h1>的背景色就是红色。我们不需要人为处理CSS和HTML文件。浏览器本身自己就理解这些文件的格式。
CSS Modules 和上面的方法不一样。我们不写纯HTML，我们需要在一个类似index.js这样的Javascript 文件中取写我们所有的标签。这里有一个例子来说明这是怎么回事（我们之后将会去看更多真实的实例）：
import styles from "./styles.css"; element.innerHTML = `<h1 class="${styles.title}"> An example heading </h1>`;
在我们构建的步骤中，编译器将会搜索我们导入的styles.css文件，然后到我们刚刚写的js文件中，通过styles.title使得.title class可用。我们的构建步骤将会同时处理这些东西成为新的，分离的HTML和CSS文件，并且用一个新的字符串去替换HTML和CSS选择器的class。
通过构建工具生成的HTML也许像下面这样：
<h1 class="_styles__title_309571057"> An example heading </h1>
通过构建工具生成的CSS也许像下面这样：
._styles__title_309571057{ background-color: red; }
class属性和.title选择器已经完全不见了，取而代之的是这个全新的字符串；我们的源CSS文件也没有为浏览器提供服务。
就像Hugo Griaudel在他的这一模块的教程中所说：
[the classes]是动态生成的，唯一的，而且和当前的样式有映射关系的。
这就是样式也有作用域的原因。它们的作用域是特定的模板。如果我们有一个buttons.css文件我们将在buttons.js模板中导入它，并且在css文件内的.btn class相对于其他模板(例如forms.js)也是不可用的，除非我们在这个文件中同样导入了进来。
为什么我们想要把CSS和HTML搞成这样？我们这样做的真真正正的原因是什么？
为什么我们要用CSS Modules?
有了CSS Modules，就可以确保所有的样式能够服务于单个组件：
- 集中在一个地方
- 只应用于那个组件，其他组件不适用
除此之外，任何组件都能拥有真正的依赖，就像下面这样：
import buttons from "./buttons.css"; import padding from "./padding.css"; element.innerHTML = `<div class="${buttons.red}${padding.large}">`;
这样设计的目的在于解决CSS中的全局作用域问题。
你曾有过为了提升效率，节省时间去简略的写css吗？而且是在完全不考虑你会不会影响其他代码的情况下？
你曾有过在样式表的底部随机打了一些的比特和垃圾，然后尝试回过头来重新去组织但是从来没这么做吗？
你曾有过看到样式却不完全知道它的意义的时候吗？即使它们被用在了当前的标签上？
你曾有过思考如何去不破坏任何东西的情况下，去弃用一些现有的样式吗？考虑过这些样式是仅仅作用于自己还是依赖其它样式呢？或者是在哪里重新覆盖了样式了？
这些问题会让人很头痛，项目时间紧张，而你的心思又在窗外的花花世界。
但是当你有了CSS Modules之后，关键是这种默认本地作用域的概念，这个问题将会被避免。你必须去思考写样式的方便性。
例如，如果你在不应用CSS module-style class去做转换的情况下，在HTML中使用random-gross-class，这个样式将不会被应用，因为这个选择器将会被转换为._style_random-gross-class_0038089.
composes 关键词
我们现在拥有一个叫做type.css的模块去渲染text样式。在那个文件中，我们也许会有如下代码：
.serif-font { font-family: Georgia,serif; } .display { composes: serif-font; font-size: 30px; line-height: 35px; }
我们将在我们的模板中声明class：
import type from "./type.css"; element.innerHTML = ` <h1 class="${type.display}"> This is a heading </h1>; `
编译后的模板上的标签会是下面这样：
<h1 class="_type__display_0980340 _type_serif_404840"> Heading title </h1>
使用composes关键词汇将2个class都绑定到元素上，从而避免了类似解决方案的一些问题，类似Sass中的@extend。
我们甚至可以在一个分离的CSS文件中去compose。
.element{ compose: dark-red from "./colors.css"; font-size: 30px; line-height: 1.2; }
不需要BEM
在构建CSS module的过程中，不需要BEM。有2个原因：
- 易解析- 类似type.display这样的代码，对于开发者来说就像BEM-y的.font-size__serif--large。当BEM选择器变长时，可能更容易被理解。
- 本地作用域- 比如我们在模块中有一个类似.big去修改font-size属性的class。同样我们可能还会用.big去同时增大padding和font-size。这没关系！他们不会冲突，因为作用域中的样式是有各自意义的。甚至一个module引入2个样式表，然后它有通常的名字我们的构建工具会为那个class加上前缀作区分。换句话说：CSS modules消除了特殊性问题。
很酷，难道不是吗？
这些仅仅是CSS Modules的部分优点。
如果你想学习更多，Glen Madden写了更多的这样做的好处。
这个系列的下一篇文章将会去探索如何在项目中使用Webpack和CSS Modules。我们将使用最新的ES2015的特性去实现，也会给出一些代码例子去引导大家去理解。
