导入bootstrap.scss至styles.scss vs .angular-cli.json样式块：优势与选型分析

Great question! 这确实是Angular搭配Bootstrap开发时很容易混淆的点，咱们把差异、优势和取舍讲清楚：

一、将bootstrap.scss导入到styles.scss的核心优势 #

• 定制主题更灵活：你可以在导入Bootstrap之前定义Sass变量（比如$primary: #2c3e50;），直接覆盖Bootstrap的默认值，不用修改Bootstrap源码或者额外新建自定义文件。这对贴合项目品牌风格来说太方便了。
• 样式层级更清晰：你可以在同一个文件里，把自己的全局自定义样式写在Bootstrap导入语句之后，这样你的样式天然拥有更高优先级，不用搞复杂的特异性 hack，全局样式逻辑也能集中管理。
• Sass特性无缝集成：因为是在Sass文件里导入，你可以直接复用Bootstrap内置的混合宏、函数和嵌套规则。比如用@include btn-variant()来生成和Bootstrap风格一致的自定义按钮样式。
• 模块化导入的可能性：不用引入整个Bootstrap库，你可以只导入需要的模块（比如@import "bootstrap/scss/buttons";或者@import "bootstrap/scss/grid";）。这在CLI配置里做不到，因为它只能添加完整的文件。

二、哪种方案更优？ #

对于90%的Angular项目，把bootstrap.scss导入到styles.scss是更优选择，原因如下：

• 定制化几乎是刚需——很少有项目会完全用原生Bootstrap不做任何调整。@import方式让定制变得轻而易举，而CLI配置没有内置的变量覆盖能力。
• Angular CLI底层的Webpack对Sass导入的处理更智能。用模块化导入时，它能有效Tree Shaking掉未使用的Bootstrap代码，减少冗余。
• 维护更简单：所有全局样式相关的配置都在一个地方，不用在angular.json和样式文件之间来回切换。

唯一可能考虑CLI配置的场景是：你用的是原生Bootstrap CSS（而非Sass源码），且完全没有定制需求。但就算这种情况，@import方式依然留足了未来扩展的灵活性。

三、构建体积、加载效率、包体积缩减的差异 #

构建体积 #

• 如果是完整导入Bootstrap，两种方式最终的CSS包体积几乎一致——都会把全套Bootstrap样式打包进去。
• 但用模块化导入时差异就大了：只导入需要的模块到styles.scss，构建体积会大幅减少（根据你用到的功能，往往能减50%以上）。CLI配置做不到这点，因为它只能加载完整的CSS/Sass文件。

页面样式加载效率 #

• 完整导入的情况下，两种方式都会把样式打包到主全局CSS文件（或按需加载的chunk），首屏加载性能差别不大。
• 模块化导入时，更小的包体积意味着更快的样式加载速度——这是@import方式独有的优势。

包体积缩减 #

• 搭配styles.scss的模块化导入能让Tree Shaking生效，剔除未使用的Bootstrap代码。CLI配置因为是一次性加载整个库，没法做到这种精细化优化。
• 另外，如果你用PurgeCSS（Angular CLI可配置）清除未使用样式，基于模块化的基础体积去优化，效果会比从完整库开始优化更好。

给新版本Angular用户的小提醒 #

注意：Angular 6+已经把.angular-cli.json改名为angular.json了，添加样式的配置逻辑没变——你只需要在angular.json的build区块里编辑styles数组就行。

内容的提问来源于stack exchange，提问作者rijin