CSS 模块化重要的是要解决好两个问题：CSS 样式的导入和导出。灵活按需导入以便复用代码；导出时要能够隐藏内部作用域，以免造成全局污染。Sass/Less/PostCSS 等前仆后继试图解决 CSS 编程能力弱的问题，结果它们做的也确实优秀，但这并没有解决模块化最重要的问题。Facebook 工程师 Vjeux 首先抛出了 React 开发中遇到的一系列 CSS 相关问题。加上我个人的看法，总结如下：
全局污染
CSS 使用全局选择器机制来设置样式，优点是方便重写样式。缺点是所有的样式都是全局生效，样式可能被错误覆盖，因此产生了非常丑陋的 !important，甚至 inline !important 和复杂的选择器权重计数表，提高犯错概率和使用成本。Web Components 标准中的 Shadow DOM 能彻底解决这个问题，但它的做法有点极端，样式彻底局部化，造成外部无法重写样式，损失了灵活性。
命名混乱
由于全局污染的问题，多人协同开发时为了避免样式冲突，选择器越来越复杂，容易形成不同的命名风格，很难统一。样式变多后，命名将更加混乱。
依赖管理不彻底
组件应该相互独立，引入一个组件时，应该只引入它所需要的 CSS 样式。但现在的做法是除了要引入 JS，还要再引入它的 CSS，而且 Saas/Less 很难实现对每个组件都编译出单独的 CSS，引入所有模块的 CSS 又造成浪费。JS 的模块化已经非常成熟，如果能让 JS 来管理 CSS 依赖是很好的解决办法。Webpack 的 css-loader 提供了这种能力。
无法共享变量
复杂组件要使用 JS 和 CSS 来共同处理样式，就会造成有些变量在 JS 和 CSS 中冗余，Sass/PostCSS/CSS 等都不提供跨 JS 和 CSS 共享变量这种能力。
代码压缩不彻底
由于移动端网络的不确定性，现在对 CSS 压缩已经到了变态的程度。很多压缩工具为了节省一个字节会把 '16px' 转成 '1pc'。但对非常长的 class 名却无能为力，力没有用到刀刃上。
上面的问题如果只凭 CSS 自身是无法解决的，如果是通过 JS 来管理 CSS 就很好解决，因此 Vjuex 给出的解决方案是完全的 CSS in JS，但这相当于完全抛弃 CSS，在 JS 中以 Object 语法来写 CSS，估计刚看到的小伙伴都受惊了。直到出现了 CSS Modules。
由于CSS的规则是全局性的，添加任何一个样式，在全局都有效，优点是方便复用，缺点是会根据 权重的计算 造成样式冲突,非常难以管理。
有了钉子，自然就会有锤子。随着前端的发展出现了各种CSS模块解决方案，主要分两种：
一类是采用JS或者JSON 的方式写CSS，比如 jsxstyle , react-style ，虽然可以采用JS成熟方案来管理css, 但是它无法使用postcss ,sass等css预处理器，并且衍生了大批的api, 使用的代价较大。
另一类还是采用css 来写样式, 不过是通过工具生成CSS作用域的方式实现模块化，比如CSS module。常用的BEM命名技巧或者团队中约定的方案来实现命名空间从而实现模块化，不过约定总会出现问题，于是就出现了通过工具，比如webpack的css-loader根据算法，实现css 模块化。
webpack 内置的 css-loader 自带了CSS modoule, 配置如下:
create-react-app 2.0以上的版本中内置启动了CSS module, 如果需要特殊配置，则需要eject操作, 在webpack.config.js 中:
CSS module 默认采用局部样式，即给每个css 名添加上了“:local”, 对应的全局性的写法：
compose 组合样式：
对于样式复用，CSS module提供了唯一的方式 "compose":
多CSS class 的写法：
Sass 变量与JS共享
Css module 作者建议：
1.不使用选择器，只使用 class 名来定义样式
2.不层叠多个 class，只使用一个 class 把所有样式定义好
3.不嵌套
4.使用 composes 组合来实现复用
采用 classnames 来增强CSS module 在react 中的使用，类似Angular 中的样式指令：
参考链接： https://zhuanlan.zhihu.com/p/20495964
