CSS Modules 不是官方规范或浏览器中的实现，而是构建步骤中的一个过程（在 Webpack 或 Browserify 的帮助下），它改变了类名和选择器的作用域（即有点像命名空间）。
目的： 解决 CSS 中全局作用域的问题
在 React 中默认开启了 CSS Module，样式表文件需要以 xxx.module.sass/less/css 命名
我们也可以通过配置 webpack 来开启 CSS Module
webpack.config.js
localIdentName 可以定义生产的哈希类名，默认是 [hash:base64]
详细配置见: css-loader
localIdentName 选项的占位符有：
默认 CSS 的规则是全局生效的，任何一个组件下的 CSS 样式，都会影响其他组件中使用相同类名的地方。
style.css
App.js
Header.css
Header.js
index.js
此时我们的页面上展示的就是绿色的 Header 组件 和 Hello World
因为定义了两个相同的 title class，虽然是在不同的组件中导入，但是他们的类名是一样的，最终都会在全局作用域下生效，因为这两个组件都渲染在了页面上。
至于为什么会显示成绿色，因为 Header 组件是后导入的，所以 Header 的 title 样式就覆盖了 App 的 title 样式，这就是 CSS 层叠样式的概念了，此处不再赘述。（如果导入顺序换一下，那么就是红色了）
答案： 产生局部作用域的唯一方法，就是使用一个独一无二的 class 的名字，不会与其他选择器重名。这就是 CSS Modules 的做法。
这里就拿 React 项目来进行解释
在 React 中，默认是开启 CSS Module 的。但是对于样式表文件的命名一个约束。需要以 .module.less/css/sass 结尾
随意我们就可以这样改造一下 Header 组件，来使用 CSS Module 的功能。
效果： Header 组件 展示为绿色； Hello World 展示为红色。可以看到 Header 中相同类名的样式并没有影响到我们的 App 组件
此时在控制台中查看 HTML，发现我们 Header 组件中的 h2 标签上的 class 类名变成了 <h2class="_src_Header_module__title">Header 组件</h2>
同理在样式表文件中也变成了
App 组件
随机的 className 是可以配置的：通过 webpack.config.js 中配置 css-loader 的 localIdentName 选项来定义生成的随机类名
通常在我们的日常开发中有这种场景：
我们有一个自己的组件，但是这个组件使用了一些第三方的组件库，对于我们使用的第三方组件我们又想修改一下它的样式。
如果此时，我们直接在当前组件的样式文件中，通过定义一个和第三方组件相同类名的类（比如说 antd button 的 antdr-btn 类），然后写自己的样式：
Button.module.css
然后我在组件中导入
Button.js
此时我们会发现我们的修改并没有生效，为什么呢？原因就是最后我们导入的类名会被 css-loader 处理成一个随机的值，所以导致不再是 antdr-btn 。
那么我们如何实现在自定义组件中修改第三方组件的样式呢？
需要不对第三方组件的类名进行哈希，保留原始类名，才能起到样式覆盖的作用 :global
:global(.className)那么此时这个 className 即使是在组件的样式表中定义的也不会被添加 hash 值，所以就可以影响全局所有类名为 className 的样式
注意：
此时组件中对该类的样式修改会影响全局所有使用该类名的地方，所以为了将样式修改限制到本组件，一般推荐将:global 使用在组件自定义类名范围下，然后添加这个自定义类名到组件中
CSS Modules 还提供一种显式的局部作用域语法:local(.className)，等同于.className（直接在样式文件中写.className）该类名在编译后会被添加 hash 值
在 CSS Modules 中，一个选择器可以继承另一个选择器的规则，这称为"组合"。
在 Header.module.css 中，让.title 继承.back 。
Header.module.css
Header.js
编译后
CSS
HTML
选择器也可以继承其他 CSS 文件里面的规则。
other.module.css
Header.module.css
注意：
导入的类名需要和被导入文件中的类名相同
编译之后的效果和 composes 同一个文件中的 class 效果相同
很多新手纠结这个问题？两个框架都能够支持做手机网页，那么它们的区别是什么呢，适用场景是什么呢？下面我们从这几个方面比较这两个框架：解决问题、功能、适用场景。<h1>解决问题</h1>
1.跨设备的网页响应式布局问题。随着手机、平板、各分辨率屏幕的出现，如何能够一套前端在所有设备上自由适应？
2.多人合作的前端布局和样式的规范问题
3.常用前端css组件，如按钮、连接、表单、表格、分页组件、下拉菜单、导航栏、ICON等等
4.常用JS前端组件（需要扩展js支持），如表单验证、Tips、Popup等等
<h1>jQuery Mobile是移动前端框架</h1>
jQuery Mobile是移动前端框架，包含js、html、css，提供一套完整的移动前端开发组件，可以比喻成Android开发框架，尽可能提供移动APP所具有的所有功能，针对解决的问题有：
1.移动网页APP所常用的组件，例如：手机导航栏、选项卡、底部菜单、列表、表单等各种组件，而这些与Bootstrap提供的组件有很大区别，jQuery Mobile提供的是类似手机APP的组件，只用于移动网页，而Bootstrap提供的是面向所有设备的组件，并没有对移动设备专门考虑，与移动APP的组件体验不一样。
2.网页页面之间转换效果
3.异步数据加载
<h1>功能</h1>
Bootstrap其核心主要是一个css样式框架，基于css 的Media Query功能实现了响应式布局，能够帮助前端开发人员快速布局、快速开发、合作开发。它必须借助jQuery类似的js框架来实现Ajax数据交互。
jQuery Mobile其核心是一个完整的WebAPP框架，加入了一个轻量级的jQuery可以实现Dom操作，在jQuery的基础上提供了一系列类似移动APP的Widget（视图组件），提供了一套不错的页面转场效果，可通过Ajax实现与后端数据交互。
<h1>适用场景</h1>
Bootstrap通常用于：展示网站的响应式布局开发，使得网站可以在不同设备上方便浏览；以及网站后台管理系统的前端CSS框架。
jQuery Mobile通常用于：期望接近移动APP体验的WebAPP，项目只运行在手机端，不用于电脑设备展示（虽然是可以展示的，但是效果不好）。
<h1>总结</h1>
如果做跨设备响应式前端，选择Boostrap；如果仅作移动端，期望得到近似APP的WebAPP，使用jQuery Mobile。
如果做一个产品级的WebAPP，当前jQuery Mobile的能力并不能让你满意，自己开发响应式布局框架和WebApp组件是必然要走的路。
<h1>最后</h1>
希望初学者可以掌握这两种框架，还有推荐一个js库，zepto.js,这个框架在开发移动端的时候，很便利，和jQ很像，但又有所不同，但是zepto.js更小，更便捷，zepto.js还提供了手机端的touch的api，真心很棒！
在瞬息万变的前端开发世界中，很难找到一个真正有意义的概念，并且将其清晰明了的向广大人民群众普及。
把目光投向CSS，一个重大转折就是CSS预处理器的出现（在工具方面来看），其中， Sass 应该是最为著名的一个。此外，还有 PostCSS ，它和Sass略有不同，但是殊途同归——都是用浏览器不能解析的语法编写，并且最终编译成浏览器能够理解的语法。
现在，又有一位新的成员出现了，它就是 CSS模块 。本文就将介绍CSS模块化的诸多优点，以及如何编写模块化的CSS。
首先，让我们从官方文档入手：
事实稍微有一些复杂。由于类名需要 默认具有局部作用域 ，这就涉及到一些初始设置、一个编译过程，以及其他一些难以琢磨的东西。
但是最终，我们会为CSS模块化带来的好处而开心：CCS模块将作用域限制于组件中，从而避免了全局作用域的问题。我们再也不用操心为组件寻找一个好的命名了，因为编译过程已经帮你完成了这个任务。
CSS模块需要在构建步骤进行管道化，这也就是说，它不是自动驱动的。它可以看成是 webpack 或 Browserify 的一个插件。其基本工作方式是：当你在一个JavaScript模块中导入一个CSS文件时（例如，在一个 React 组件中），CSS模块将会定义一个对象，将文件中类的名字动态的映射为JavaScript作用域中可以使用的字符串。举个具体的例子：
如下是一个简单的CSS文件。其中， .base 类名不需要是工程中唯一的，因为它将不会是真正被解析的类名。它可以看成是在JavaScript模块中使用的类在样式表中的别名。
下面是该CSS类在JavaScript组件中的使用方式：
最终，它将生成下面这个东西（当使用webpack的默认步骤时）：
当然，生成的类名可以通过配置，使得它的长度更短或者遵循一些特定的模式。当然了，这些最终都不重要（虽然短的类名意味着更短的样式表），重点在于这些类名是动态生成的、唯一的且和正确的样式表一一对应的。
这就是CSS模块工作的方式了。这时，你可能会想，“这到底是个什么玩意儿，我甚至。。。”。OK，停下！我知道你想说什么。现在就让我一一解答你可能有的疑虑。
这看起来太丑了
确实如此。但是类名并不要求一定要长的好看对不对？只要可以将样式正确的应用于元素就可以了嘛。而CSS模块化方法完成的非常好，所以我觉得，这不是一个问题。
这非常难debug啊
由于需要有一个编译的步骤，所以直接debug是非常困难的。其实，像Sass直接debug也是相当不容易的，所以我们才有了 sourcemaps 。对于CSS模块，我们也可以设置sourcemap。
其实，我还想说的是，虽然在模块中，类的名字是自动生成而不可预知的，但是对于模块来说，它还是比样式表更容易debug的。只要你知道当前在开发者工具中查看的样式属于哪个模块，在相应的样式表中也是很容易定位。
这使得样式不容易复用啦！
这句话既对也不对。一方面来说，确实如此。但这是因为模块将CSS样式和组件相绑定，从而不会发生全局样式的冲突。这其实是一件好事，我相信你也会同意的对不对。
另一方面，要定义全局样式也是可以的，只要使用 :global() 就好了。比如，作者需要保留的全局辅助样式。
CSS模块还可以从其他模块中继承样式，这和Sass中的 @extend 方法其实是一样的。它不会拷贝样式，只是将选择器连接到继承的样式中。
它需要webpack，Browserify或者其他工具！
这和Sass需要将 .scss 文件编译成CSS文件，PostCSS需要将样式表处理成浏览器能够识别的样式其实是一样的。无论如何，都需要一个构建步骤。
我们究竟为什么要讨论这个东西？
其实，我甚至不确定CSS模块在未来到底会不会继续存在，不过，我确定这是一种编写样式的正确方式。试想，在拆分成许多细小组件的庞大站点中，却拥有一个臃肿的全局样式表，这肯定是不合适的。
CSS统一的名空间使得它既强大又脆弱。而CSS模块化或者未来延续这个思想的其他工具可以在支持样式复用的同时，避免命名冲突，这是一个双赢的选择。
如前面所说的，你需要有webpack或者Browserify来实现CSS模块化。
先从webpack版本的模块化开始。在 webpack.config.js 中，加上如下配置，使得webpack将CSS文件作为CSS模块来看待：
这时，它将把样式注入到页面中的``元素中。这可能不是我们想要的，使用 extract text plugin for webpack ，我们可以很方便的抽取出样式表：
对于webpack，要讲的就是这么多了。
我只在命令行中用过Browserify，所以我猜使用起来会更复杂一些。在 package.json 文件中，加入 npm script ：
这条命令告诉Browserify运行 src/index.js ，返回 dist/index.js ，并且使用 css-modulesify 将样式表编译至 dist/main.css 。如果你想再加上 Autoprefixer ，那么命令可以写成这样：
如你所见，使用 --after 选项可以在编译完成样式表时候，继续对它进行处理。
从今天看来， CSS模块化 系统和生态确实有些原始了，从Browserify中的配置就能看出来。不过，我确信CSS模块化将变得更好，并且越来越多的人将意识到不管对小项目还是大项目来说，这都是一个很好的方法。
我认为CSS模块化背后的思想是正确的。当然，我不是说这个库就是最佳解决方案，但是，它确实包含了一些CSS应该采用的写法：模块化、作用域隔离、同时支持复用。
最后，我向大家推荐项目作者Glen Maddern的文章 this introduction to CSS Modules 。
