为什么编译器用于sass文件，而它们可以通过终端运行

谁能帮我解释一下吗？我对使用Sass是个新手。但我不明白为什么人们在可以通过终端运行的情况下使用sass文件的编译器。

不久前我在学习sass时也遇到了同样的问题

我一直在想，为什么大多数教程都涉及使用GRUNT/GULP或某种任务运行程序，而sass专有命令甚至用于使用以下命令实时查看您的文件：

sass --watch app/sass:public/stylesheets

我将在这里引用我自己的话（没有人回答），只是为了分享我在SASS编译方面的经验：

Grunt：使用Grunt contrib sass-一切都很顺利；我之所以选择这个而不是grunt sass，并没有什么特别的原因，但我已经读到后者使用libsass（c++），它比传统的ruby sass更快

Gulp：使用Gulp:sass-我在观看时经常遇到错误 文件，它找不到某些部分，但如果再次保存， 一切都很好（这在他们的共同问题中得到了解决-这 这个解决方案对我不起作用），而且它也不会产生sass 默认情况下，您必须在顶部使用gulp sourcemaps

直接从控制台开始：没有任务运行程序-到目前为止工作正常，生成 sourcemaps，并让您知道哪里有错误，就像 咕噜咕噜

因此，在使用SASS完成不同的项目后，我想说的原因是：

• 在早期使用SASS时，教程普及了任务运行程序的使用
• 在项目中，您很少单独使用SASS，您很可能希望运行其他任务，因此将您的SASS任务添加到流中是有意义的，这既节省了时间又有意义
• 运行一个简单的命令（例如

  gulp sass

  或只运行

  gulp

  来运行默认的gulp任务（应该包括sass任务）要比记住一个长命令（其中必须反复放置路径）容易得多

过了一会儿，我意识到您可以在

package.json

中使用NPM脚本来运行SASS命令行工具，如下所示：

"scripts": {
    "sass": "sass --watch app/sass:public/stylesheets --style compressed"
  },

然后从命令行运行它：

npm run sass

以上内容不需要配置，您也不必记住整个命令

总之，在没有其他编译器/任务运行程序的情况下使用CMD SASS没有什么错，只要使用您觉得最合适的语言即可。

您指的是为浏览器编译为CSS的语言吗？