本文作者：IMWeb 结一 原文出处：IMWeb社区 未经同意，禁止转载
首先，这里说的迁移并不代表这两个技术的优劣，其次也不代表它们是矛盾不相容的，相反它们搭配使用是很棒的。
迁移前提
如果你打算把 Sass 迁移到 PostCSS，那么在迁移之前有些事是必须要考虑的：
- 首先，先问下自己为什么要迁移？值不值这么做很重要。
- 其次，你对 PostCSS 的插件机制一定要深入了解，因为整个迁移过程肯定会出现问题。
- 然后如果决定迁移，先调查下自己或团队的 Sass 使用习惯，然后对比 PostCSS 的实现。一种是平稳迁移，保持 Sass 的风格不变（如变量、mixin等）；另一种就是全部换成 PostCSS 格式。相对来说老的大项目建议使用平稳迁移，不然时间成本太大。而对于有些 PostCSS 实现不了，就要重新考虑方案了。
- 如果这些都想好了，最后还需要考虑的是哪些项目需要迁移，哪些不需要，再来个试水的看看效果，毕竟跑起来才是最重要的。
迁移步骤
1、确定使用什么构建
- webpack：postcss-loader(推荐使用)
- gulp：gulp-postcss
2、挑选 PostCSS 插件
首先统计常用 Sass 功能，查找对应的 PostCSS 插件
一般来说，我们常用的 sass 功能如下：
- import 导入
- 变量
- 嵌套格式
- mixin & include、% & extend
- color 颜色函数
- 运算
- if、for、each
在查找相应功能插件的时候可以参考precss，同时 PostCSS 插件 版块中也有一个 Sass 的，也可以拿来参考看看。
挑选未来语法的插件： postcss-preset-env (cssnext已经不再维护了，所以不推荐)
以下是我挑选的一些插件，挑选的原则是：优先 CSS 新标准，兼容 Sass 语法，插件之间不冲突。
3、相关配置
- 配置 webpack 的 postcss-loader
- 配置
postcss.config.js文件 - 给编辑器添加语法高亮
- 配置 stylelint 验证
4、迁移
将以前的 .scss 后缀改成 .css 后缀，这个过程一般都会遇到一些报错，所以前期建议一个个改，等对报错有了一定程度了解，就可以批量修改试试。
如果你有使用一个基础的 Sass 库（如 sandal），那么首先得迁移这个基础的库，我们的基础库是 sandal，所以搞了一个 sandal-for-postcss。
如果你的目的是平稳过度，且以后使用未来标准语法，那么对于一些基础的变量得使用新的标准语法重新定义一份。
下面是一些我迁移过程中遇到的部分不支持问题：
除此之外，所有的运算都需要使用 calc 来计算，变量默认值的处理可参考 sandal-for-postcss。
总结
最后迁移有风险，中间也会遇到一些坑或坎，请谨慎评估。
