为了应对项目开发中不断增长的复杂度和整体规模，开发者有必要使用恰当的逻辑，规划 Sass 文件的结构层次。遵循公认的编程规范，有助于开发者快速融入大型项目或团队的开发流程。下面就详细解析流行框架的结构层次。

Bootstrap-sass

Bootstrap 的目标是成为 Web 开发者的 UI 库，实现前端的快速开发，摆脱重复的基础性工作。其背后的逻辑是，在单一文件中聚合所有变量，而隐藏具体的混合宏等实现细节。它们的 Sass 体系结构就与此相似。每一个组件拥有独立的 Sass 文件，同时还存在一个 ./_variables.scss 文件——便于开发者控制项目中的所有变量。

Bootstrap 中 Sass 体系结构的独特之处，就在于它引用混合宏的方式。根目录下有一个 ./_mixins.scss 文件，该文件导入 mixins 文件夹的所有文件——该文件夹存放着每个混合宏的文件。举例来说，虽然是在 ./_buttons.scss 定义了按钮样式，但使用到的混合宏却是通过 ./_mixins.scss 导入的。如果继续追踪下去，会发现按钮的混合宏来自 mixins/_buttons.scss。Yo~Yo~~切克闹!

除了组件化的混合宏，该混合宏文件夹还包含了一些全局混合宏，比如 mixins/_border-radius.scss 和 mixins/_responsive-visibility.scss。虽然 Bootstrap 的混合宏并不复杂，但是这种体系结构更适用于那些混合宏非常复杂的项目，或者是混合宏需要独立为较小模块的项目。如果你想分离组件视觉风格和逻辑处理，那么使用这种体系结构也是合适的。简而言之，该体系结构适合于 Bootstrap 却不一定适合你。

目录结构如下：

bootstrap/
|– bootstrap.scss   # Manifest file 
|– _alerts.scss     # Component file 
|– _buttons.scss    # Component file 
|– _mixins.scss     # Mixin file – imports all files from mixins folder
|–  ...             # Etc..
|– mixins/
|  |–  _alerts.scss # Alert mixin
|  |– _buttons.scss # Button mixin
|  |– ...           # Etc..

Zurb Foundation

Foundation 中的 Sass 体系结构思虑周到，非常适合用来自定义样式——这也是它的强大之处。在根目录下有一个 settings.scss，该文件允许开发者重写构建组件的所有变量。不过，每一个组件文件包含的变量都是针对该组件的。

此外，Foundation 在 functions.scss 文件中抽象出了项目中的函数。这种方式很棒，一方面这些函数是框架特有的，另一方面开发者也不用改写该文件。

边框圆角和过渡效果等全局混合宏都被引入到了 components/_global.scss。其逻辑结构如下：

- Import - global mixins
- Component specific variables (`$button-tny`, `$button-margin-bottom`) 
- Component specific mixins
- Extends - (not the @extend but actual style definitions, where mixins are called) 

所有特定组件的变量都会被定义为 !default，因此就可以在 _settings.scss 中重写这些变量了。如果你喜欢保持目录简洁，那么也可以直接修改 _settings.scss 中的变量。如果你喜欢折腾，完全可以修改特定组件的变量，此外修改组件的样式也很简单。

由于所有的组件是由混合宏和变量构建的，所以它具有最佳的灵活性。虽然有大量的网站在使用 Foundation，却不会千篇一律。

你可以借鉴 Foundation 的 Sass 体系结构，开发中小型站点。使用 Foundation，可以轻松使用任意组件，并且将所需要的变量、混合宏及其他扩展包含在同一文件中。

目录结构如下：

foundation/
|– foundation.scss           # Manifest file 
|– foundation 
|  |– _functions.scss        # Library specific functions 
|  |– _settings.scss         # Change variables for the entire project
|  |– components
|  |  |– _buttons.scss       # Component file (will import _globals.scss)
|  |  |– _globals.scss       # Global mixins
|  |  |– _alerts.scss        # Component file (will import _globals.scss)

Dale Sande 的体系结构

Dale Sande，在他的演讲 “Clean out your Sass Junk-Drawer” 中，建议使用模块化的方法组织 Sass 文件。这对于企业级项目大有用处，因为此类项目往往具有大量高复杂度的模块。该方法还可以保留模块和所在文件夹的所有逻辑，这种逻辑允许子模块在作用域内继续扩展和重用样式。此外，如果你愿意将表现效果从 Sass 逻辑结构中分离，那么这也适合中小型项目。

使用 Dale Sande 的方法，最大的优势就是，可以轻易地为特定模块编写独立的样式。在项目内部，可以加载包含全局样式的基础样式，同时还可以加载针对特定模块的样式。这有助于移除代码中大量的膨化元素，改善性能和加载速度。

目录结构如下：

sass/
|– style.scss                        # Manifest
|– modules/ 
|  |– registration/                  # Sub Module
|  |  |–  _extends.scss              # Functional 
|  |  |–  _functions.scss            # Functional 
|  |  |–  _mixin.scss                # Functional  
|  |  |–  _module_registration.scss  # Imports functional partials and contains presentational 
|  |  |–  _module_personalInfo.scss  # Imports functional partials 

Style Prototypes

Style Prototypes，出自 Sam Richard 之手，是一款优秀的工具，并包含了一系列在浏览器中使用 Sass 和 Compass 的设计规范。在此体系结构中，组件按逻辑分组为特定的文件夹，比如 base, components, layouts (SMACSS) 或者 atoms, molecules, components (atomic design)。

此外，每个组件拥有独自的部分： _variables.scss, _mixins.scss, _extends.scss 和清单文件 (_buttons.scss, _alerts.scss 等等)。

不过，这种方法有两个缺点：

• 编译时间——文件越多，编译所需的文件也就会越多
• 最初构建组件时，可能会在大量文件间进行切换。但是一旦完成，就可以轻而易举地维护和更改了。

这种方式的好处是，可以致力于单个模块的单一部分。它清晰地界定了设计一个组件所需的配置（变量）、功能（混合宏、扩展）和表现部分。全局配置则脱离组件-模块及的配置，独立设置。

在具有多个开发团队的大中型项目，这种分离有助于理清模块的层次结构。当需要时，也可以轻松常见特定模块的样式。

目录结构如下：

scss/
|– style.scss    # Manifest
|– partials/
|  |– base/
|  |  |– _content.scss
|  |  |– content
|  |  |  |– _variables.scss    # Component specific variables  
|  |  |  |– _extends.scss      # Component specific extends
|  |  |  |– _mixins.scss       # Component specific mixins
|  |– components/
|  |  |– _message.scss
|  |  |– message
|  |  |  |– _variables.scss
|  |  |  |– _extends.scss
|  |  |  |– _mixins.scss
|  |– global/
|  |  |– _variables.scss
|  |  |– _extends.scss
|  |  |– _mixins.scss
|  |  |– _functions.scss
|  |– layouts/
|  |  |– _article.scss
|  |  |– article
|  |  |  |– _variables.scss
|  |  |  |– _extends.scss
|  |  |  |– _mixins.scss

SMACSS

个人认为，Hugo 基于 SMASS 的替代方法很棒，更多信息请参考 Sass architecture post。此外，也可以参考 SMACSS starter kit by Mina Markham。

结论

本文中，我们分析了组织 Sass 文件的不同方式。至于使用哪种方式，有必要考虑一下复杂性、编译时间，以及个人喜好。

应用于团队开发时，事情就有点复杂了。你需要确保团队中的每个人，都可以接受你的方法，并愿意做出一些改变，以适应具体情况。

我最喜欢 Style Prototypes 体系结构，原因是它适合我的思维方式。有必要提醒的是：嵌套越深，编译越久。

扩展阅读

• 组织Sass文件
• 如何组织一个Sass项目
• 管理Sass项目文件结构
• Sass Guidelines中文版本之四：项目文件管理

本文根据@Vinay Raghu的《A Look at Different Sass Architectures》所译，整个译文带有我们自己的理解与思想，如果译得不好或有不对之处还请同行朋友指点。如需转载此译文，需注明英文出处：http://www.sitepoint.com/look-different-sass-architectures/。

南北

在校学生，本科计算机专业。狂热地想当一名作家，为色彩和图形营造的视觉张力折服，喜欢调教各类JS库，钟爱CSS，希望未来加入一个社交性质的公司，内心极度肯定“情感”在社交中的决定性地位，立志于此改变社交关系的快速迭代。

如需转载，烦请注明出处：http://www.w3cplus.com/preprocessor/look-different-sass-architectures.htmlAir Jordan XIV High