DEX475

课程介绍

好，同学们，咱们来看这一页幻灯片。 你可能在开发 Lightning Web 组件的时候，会遇到一个问题：自己做出来的组件，怎么才能跟 Salesforce 标准界面——也就是 Lightning Experience——看起来完全一样，风格统一，不突兀呢？ 答案就在这句话里：要让组件拥有 Lightning Experience 的外观和感觉，就得依赖两个东西——，Lightning 设计系统（SLDS）， 和 ，Lightning 基础组件，。 先说基础组件。当你去用 `lightning` 命名空间下那些现成的基础组件，比如 `<lightning-button>` 、 `<lightning-input>` ，只要你一引用，它们自动就带上了 SLDS 的样式，颜色、字体、间距全都有，你完全不用自己写一行 CSS。这就是“自动获得 SLDS 样式”的好处。 但有时候，你需要在这个基础样式上做点小调整，比如换个品牌的字体或主色调，这时候就可以用到 ，样式挂钩（Styling Hooks）， 。它是一种 CSS 自定义属性，Lightning 基础组件预留了很多这样的挂钩，你只需要在组件里重新定义这些变量，就能轻松改变外观，而不需要重写整个样式。 再来说说 ，蓝图（Blueprints）， 。SLDS 其实提供了一整套设计蓝图，就像搭建积木的图纸一样。比如你想做一个卡片布局或者数据表格，照着蓝图的标记结构和样式去拼，出来的组件自然就和标准界面融为一体了。所以“根据蓝图创建组件”意思就是，按照 SLDS 的规则去搭你的 UI，保证设计的一致性。 还有一个很关键的技术点：Lightning Web 组件默认使用了 ，Shadow DOM，，它会把每个组件的样式封装起来，里面的样式不会跑出去，外面的也不会干扰里面。但这也会带来一个小麻烦：如果多个组件都想用同一套 SLDS 样式，难道每个都单独拷贝一份吗？当然不用。我们可以把 CSS 写成单独的样式表，然后通过 ，`@import`， 来共享。比如在一个 CSS 文件里用 `@import 'c/sharedStyles';` 这样就能把公共的 SLDS 样式或你自定义的样式引入到组件里，既保持了 shadow DOM 的隔离性，又复用了代码。 总结一下这张幻灯片：想让你的组件长得像 Salesforce “亲生的”，就用它提供的 SLDS 和基础组件；基础组件自带样式，用样式挂钩微调，有蓝图可照着设计，在 shadow 隔离下通过 `@import` 共享 CSS。这样你的组件就能既美观又高效。 好了，这一页的内容就是这样，听明白了吗？咱们可以接着看下一页。

课程章节

本课程共有 9 个章节

• 1

  SLDS 1 vs SLDS 2 — Comparison

  第 54 页

  好，咱们今天来看一个新的内容，就是Salesforce即将在25年春季推出的SDS 2，主题叫做Salesforce Cosmos。这个东西听起来可能有点陌生，我来慢慢给你讲清楚。 首先你得知道，SDS是Salesforce Design System的缩写，说白了就是一套统一设计风格的工具箱，让我们写的Lightning组件能有一致的视觉体验，比如按钮颜色、字体大小、间距这些。之前我们用的是SDS 1，它提供了一些“设计标记”，你可以理解为一个个设计变量，比如品牌色、边框圆角。而且SDS 1还支持一种叫“组件样式挂钩”的东西，写法就是 `--slds-c-按钮背景色` 这种，c代表component，也就是组件级别的自定义，你可以通过它很方便地调整某个组件内部的样式。 现在SDS 2有了一个新变化：它不再用那些设计标记了，而是换成了全局的样式挂钩，写法是 `--slds-g-*` ，g就是global。这样你能在整个应用层面统一控制样式，更灵活。但是要注意，目前SDS 2还没支持组件级的挂钩，也就是说，如果你现在的组件代码里用了 `--slds-c-*` 这种写法，升级到SDS 2就会出问题。所以官方建议，如果你自己写的组件还依赖这些组件挂钩，暂时先别迁移，留在SDS 1上会更稳妥。 那如果想迁移怎么办？别担心，官方提供了两个新工具来帮忙。一个叫SDDS Linter（新出的），它会扫描你的代码，提示你哪些地方需要从设计标记迁移到全局样式挂钩。另一个是SDDS Veritas，这是一个VS Code扩展，会自动安装，帮你更平滑地完成迁移。这两个小助手能省下不少手动改代码的时间。 最后还有一个关键点：虽然SDS 2在底层机制上有变化，但组件本身的蓝图（也就是结构和各种变体）和SDS 1是一样的。只不过现在这些组件蓝图文档还只在SDS 1的网站上能找到，以后可能会逐步更新。 简单总结一下：SDS 2带来全局样式挂钩，更强大，但暂时不兼容组件挂钩。有工具帮你迁移，暂时不建议带c挂钩的老代码升级。蓝图没变，只是文档还没搬到新站。 这样说是不是就清晰多了？好，我们接着看下一部分。

  ▶ 播放视频 查看详情
• 2

  Lightning Base Components — Styling Priority

  第 55 页

  同学们，我们来看一下怎么给基础组件做样式。在Lightning Web Components里，有三种方法，而且还分了优先顺序，用起来特别清晰。 首先，最优先的是用组件自带的变体属性，比如你看到 button 组件有 `variant` 属性，可以选品牌色 `brand`，中性色 `neutral`，还有破坏性的 `destructive` 这些。直接用属性来切换设计变体最安全、最省事。 第二优先级，是使用 SLDS 的工具类，这些类专门管间距啊、排版啊这类布局上的事情。你直接在组件上添加 `slds-m-top_medium` 这样的类名就行，不需要自己写 CSS，而且也不会干扰组件内部的样式。 第三个方法，是更深度定制会用到的样式挂钩。你可以通过 CSS 自定义属性，也就是 `--` 开头的变量，去调整组件的某些具体部分的样式。比如按钮的背景色挂钩可能叫 `--slds-c-button-color-background`，覆盖它就行。但是有一个铁律：永远不要直接覆盖 SLDS 自己的类名。要自定义，就自己创建一个 CSS 类，然后在这类里用样式挂钩。 在用自定义属性的时候，一定要提供后备值。写法就像这样：`var(--slds-g-spacing-4, var(--lwc-spacingMedium, 1rem))`。意思是先去读 `--slds-g-spacing-4`，如果它没定义，再去看 `--lwc-spacingMedium`，如果还没有，最后就用后面的 `1rem`。这样不管在什么环境里，都不会出现样式丢失。 再提醒一点：不要依赖基础组件内部的 DOM 结构，因为它随时可能被升级改掉。你要是靠着某个内部类名写样式，将来版本一更新可能就坏了。 最后，想要查每个组件到底提供了哪些样式挂钩，直接去“组件参考”文档里找，那里会列得清清楚楚。 掌握这三个方法，你就能安全又灵活地定制组件外观了，而且还不会因为未来更新而崩掉。

  ▶ 播放视频 查看详情
• 3

  SLDS Styling Hooks — Component Level

  第 56 页

  我们来聊聊Salesforce组件样式里的一个特殊功能，就是组件样式挂钩，英文是Component Style Hooks，写法是以 --slds-c- 开头。 你可以把它想象成每个标准组件预留出来的调色板插口。它的作用就是让你可以很方便地修改组件的外观，比如按钮的颜色、背景等等，还不用担心把组件内部的结构弄乱。 不过有个前提要记住，这套挂钩只在SDDS 1样式体系下才能用。如果你用的是更新的样式版本，可能就用不了。 具体怎么用呢？很简单，你打开组件的CSS文件，然后针对 :host 这个选择器来设置这些变量。:host 就代表这个组件本身，比如你给一个按钮组件设样式，就可以这样写： :host { --slds-c-button-brand-color-background: var(--lwc-brandPrimary); --slds-c-button-brand-color-border: var(--lwc-brandPrimary); } 这里我们用到了全局的颜色挂钩，比如 --lwc-brandPrimary 这个变量，它里面存的就是你整套品牌色中的主色调。这样一设，按钮的背景色和边框色就都变成你的品牌颜色了，非常省事。 最重要的是，不要直接去覆盖SLDS的底层CSS类名，比如硬写成 .slds-button_brand 然后覆盖它的样式。那样做很危险，因为Salesforce更新样式库的时候，内部类名可能被修改，你的样式就会突然失效。用样式挂钩就安全多了，因为挂钩是Salesforce承诺维护的公开接口。 每个基础组件都或多或少公开了一些这样的自定义属性，具体有哪些你可以去查Lightning Design System网站上的组件蓝图页面，里面每个组件旁边都会列出可用的样式挂钩。 不过也要注意，并不是所有元素都支持这种自定义属性。目前有几个例外：Toast通知、工具提示、链接，还有表单元素是不支持的。也就是说，你没法用同样的方式去改这些组件的样式。另外，在事件通知方面，现在推荐用 lightning/toast 这个模块，而不是以前老的 platformShowToastEvents，这算是个关联的小提示。 好了，这就是组件样式挂钩的基本用法，记住它可以让你安全、规范地定制组件外观，用了它就不用担心升级问题，而且写法也很简单直观。

  ▶ 播放视频 查看详情
• 4

  SLDS Global Styling Hooks & Design Tokens

  第 57 页

  同学们，我们来看看这一页幻灯片的内容，主要讲的是全局样式挂钩，还有一些相关的使用建议。 首先，“全局样式挂钩”的前缀是 `--slds-g-*`，它已经替代了以前SDDS 1和SDDS 2中那些废弃的设计令牌和样式工件。简单来说，如果你之前用过旧版的设计变量，现在记得换成这种新的形式。 另外，在Salesforce Design System 2里，还为组织级主题增加了“语义UI颜色挂钩”。这样，像背景色、文字色这些语义化的颜色，就可以直接跟着你设定的主题变化，改一个地方，所有用到的地方就都统一了。 另一个要注意的点是，带有 `--lwc-` 前缀的设计标记，是会在编译时被转换成实际值的。这意味着你不能在JavaScript里动态去读取或修改它们，它们只存在于编译后的静态样式里。而且，在Lightning Web Components中，你只能使用全局可访问的样式令牌，不能使用其他受限范围的令牌。 如果你想把旧代码里的废弃令牌替换掉，推荐使用SDS Linter或者Validator工具。它们可以自动扫描你的代码，找出那些老旧的设计令牌，然后帮你直接替换成对应的全局样式挂钩。 最后，关于自定义Aura令牌，在LWC的CSS里，以前你可以用 `--c-` 前缀来引用。不过，为了保证你的应用满足WCAG 2.1颜色对比度等无障碍标准，现在更推荐直接使用这些全局样式挂钩，因为它们是经过对比度验证的，用起来更放心。 总结一下，就是尽量用 `--slds-g-*` 这种新式的全局样式挂钩，不仅能跟上最新的设计规范，也能让你的组件在颜色和无障碍方面更可靠。

  ▶ 播放视频 查看详情
• 5

  Create a Component from an SLDS Blueprint

  第 58 页

  同学们，今天我们来聊一个很实用的技巧——当你需要的界面元件在Lightning基本组件库里找不到现成的，该怎么办？别慌，我们可以从SLDS蓝图一步步构建出来。下面我把这个过程拆成五个清晰的步骤，保证你听完就能上手。 首先第一步，，复制基础变体的标记，。打开SLDS网站，找到你需要的组件蓝图，它通常会提供几种样式变体。选一个最接近你需求的变体，直接把它的HTML代码复制到你的LWC模板里。这一步就是先让界面能显示出来。 接着第二步，，尽可能用Lightning基本组件替换标准HTML，。看看你复制过来的标记，里面有没有直接用`<button>`、`<a>`、`<svg>`这些原生标签的地方。如果对应功能有现成的基本组件，比如`lightning-button`、`lightning-icon`，那就换成它们。基本组件的好处是自动处理了可访问性、交互行为，还能跟随Salesforce的更新自动升级样式，一劳永逸。 然后是第三步，，把内容移到JavaScript，并用`@api`属性暴露出来，。蓝图里的文本、数据都是写死的，而你的组件肯定是动态的。所以把那些可变的文字、配置项提取到JS里，定义成`@api`属性，然后在模板里用花括号绑定。这样外界就能通过属性来控制组件显示什么内容。 第四步有点巧妙，，用getter函数生成动态类名，实现主题变体，。蓝图可能给了好几种颜色方案或尺寸，这些通常通过CSS类来切换。你可以在JS里写一个getter，根据某个属性值自动计算出应该拼接哪些类名，比如`get computedClass() { return 'slds-button_' + this.variant; }`，然后在模板上绑定这个getter。这样切换变体就像改个属性值一样简单。 最后第五步，，把其他动态属性也绑定好，。比如按钮是否需要禁用、输入框的占位符这些，都应基于JS里的属性动态输出，保证组件是完全可配置的。 这里有一个关键提醒——，蓝图标记一旦被你复制过来，就成了你自己代码的一部分，未来SLDS官网更新了样式，你的组件可不会自动跟进，。这和基本组件完全不同，基本组件是Salesforce官方维护的，底层样式更新后你自动受益。所以构建前，记得去蓝图页面看一看那个，“Lightning Components”按钮，，如果它亮着，说明这个组件已经有官方基本组件了，直接用它就好，别自己重复造轮子了。 以上就是从SLDS蓝图构建LWC组件的五步法，你学“废”了吗？动手的时候按这个顺序来，思路会非常清晰。好，这节课就到这里，咱们下次见！

  ▶ 播放视频 查看详情
• 6

  CSS Stylesheets — Shadow DOM Encapsulation

  第 59 页

  同学们，今天我们来讲一下 Lightning Web Components 里一个非常重要的概念——，影子 DOM 对 CSS 的封装，。这能让你写的组件样式不会被外部轻易干扰，同时也不会意外地去影响其他组件。 首先，我们要明白，在 LWC 里，每个组件都有一个属于自己的“影子 DOM”，它就像给组件套上了一个保护罩。你在，组件自己的样式表，里定义的 CSS，，只对这个组件内部生效，。组件的父组件，可以把子组件当作一个整体来看，但它没办法直接伸手进去修改子组件的内部样式。比如说，你没办法在父组件里写一条 CSS 规则去改变子组件内部某个 `<div>` 的背景色。 那如果你想让组件自己的根元素有一个样式，该怎么做呢？可以用 ，`:host` 选择器，。`:host` 指的就是组件自己那个最外层标签。你可以直接写 `:host { display: block; }`，这就给组件的根元素加上了块级显示。甚至还能结合类名来用，比如 `:host(.active)`，意思是只有当这个组件自身带有 `active` 这个 class 时，样式才会生效。 在影子 DOM 内部，标准的 ，CSS 级联和特异性规则，依然有效，也就是说，你仍然可以用更具体的选择器去覆盖前面的样式。但是要注意，LWC 里，不支持 ID 选择器，。如果你在组件里写 `#my-id`，它在运行时会被转换成一个唯一的随机值，所以用 ID 选择器的样式其实是不会生效的。 接下来要讲一个比较反直觉的点——，样式属性的继承，。有一部分 CSS 属性，比如，颜色、字体，，它们是可继承的。这些属性会强势地穿透影子 DOM 边界，从父组件传到子组件。但像，边框，这种不可继承的属性，就不会穿透。所以你会发现，父组件设个 `color: red`，子组件里的文字也变红了，但父组件设的 `border` 就不会跑进子组件。 还有一种东西，叫 ，CSS 自定义属性，，也就是我们常说的 CSS 变量。自定义属性有一个特点：，它总是能穿透影子 DOM，。无论你在父组件里定义了什么 CSS 变量，子组件都能读取到，这是有意设计用于跨组件样式定制的安全方式。 最后，有两个选择器是，不支持，的：一个是 `::host-context()`，另一个是 `::part`。这两个在 LWC 里暂时还用不了，所以写样式时别去依赖它们。 还有一个重要的提醒：影子 DOM 带来的 CSS 隔离会增加一些页面渲染的开销，因为浏览器要管理这些独立的样式作用域。所以我们在设计组件样式的时候要小心，避免过度使用复杂的样式，以减少性能影响。 好了，这就是关于 LWC 中影子 DOM 封装的要点。记住：组件样式是私有的，`:host` 控制根元素，继承穿透有规律，自定义属性随便穿，ID 选择器别用，性能方面多留心。下一个话题我们继续深入。

  ▶ 播放视频 查看详情
• 7

  Stylesheets Property & Styling Hooks Creation

  第 60 页

  同学们，今天我们来聊聊 Lightning Web Components 里一个非常实用的知识点 —— `static stylesheets` 属性，以及怎么用它配合 CSS 自定义属性，来做组件级的主题化。 好，先看第一句：“`static stylesheets` 属性接受一个导入的 CSS 文件数组，在组件自己的 CSS 之后加载。” 这怎么理解呢？就是我们可以在组件里，通过一个静态属性来引入额外的样式表。它是静态的，意味着属于这个组件类本身，所有实例共享。你给它传一个数组，数组里放的是你从别的 `.css` 文件导入的样式。这些样式会在组件自己直接写的那个 CSS 之后加载，也就是说它们的优先级会稍微高一点点，可以用来覆盖默认样式，但又不是粗暴地硬覆盖，是有序地叠加。 接着讲“数组在应用生命周期内被缓存”。这什么意思？就是说你只要把一组样式表通过这个静态属性定义好，LWC 框架会把它存起来，在应用的整个运行过程中反复使用，不会每次渲染组件都重新解析一遍，性能上就很友好。 那么如果需要继承呢？注意，“子类必须通过 `super.stylesheets` 手动合并。” 如果你写了一个父组件，又在子组件里覆盖了 `static stylesheets`，子组件不会自动拥有父组件的样式表。你必须显式地用 `super.stylesheets` 把父级的样式拿过来，然后跟自己的样式数组合并，比如用展开运算符。这样一来，你既能继承父组件外观，又能加上子组件自己的定制，这样代码才可控，不会莫名其妙丢失样式。 好，掌握了 `static stylesheets` 的基本用法，我们接下来看看它真正威力体现在哪里——自定义样式钩子，用到的就是 CSS 自定义属性，也就是我们常说的 CSS 变量。 创建自定义样式钩子非常简单，变量名以 `--` 开头，然后用 `var()` 函数去调用它。比如我们想给组件的背景色留一个可配置的口子，就定义一个 `--my-bg`。那么如何把它暴露给使用者呢？在 `:host` 伪类上定义这些钩子。“为组件级主题化定义 hooks 在 `:host` 上。” `:host` 代表组件的根元素，你在这上面声明的 CSS 变量，就相当于告诉外界：“我这些属性是用来定制外观的，你可以从外面传值进来。” 这样做还有个很大的好处，就是你可以提供一个回退值。在 `var()` 的第二个参数里写上默认值，比如 `var(--my-bg, #fff)`。这样如果使用者没有指定这个变量，组件会自动使用白色背景，保证在任何环境都能有合理的外观。 那为什么它能做到组件主题化呢？因为“CSS 自定义属性是继承的并穿透 Shadow DOM”。我们知道 LWC 组件基于 Shadow DOM，样式通常是封装的。但自定义属性是个例外，它会从父级 DOM 一直向下穿透到 shadow 树里面。这么一来，消费者（也就是用你组件的人）完全可以在更高的 DOM 级别设置这些变量的值，比如在最外层容器或者页面上，覆盖掉组件内的变量，而完全不用了解组件内部的 DOM 结构或样式怎么写。这就是所谓的“无需了解实现细节”。 所以我们要养成一个好习惯：“文档化这些钩子，把它们作为组件公共 API 的一部分。” 你定义了哪些 `--` 开头的自定义属性、各自是什么作用、默认值是什么，都要写清楚，就像给方法写注释一样。这样你的组件就变成了一个可配置、可主题化的健康组件，别人用起来会非常顺手。 简单来说，今天的重点可以总结成： 1. 用 `static stylesheets` 管理额外的样式，注意加载顺序和子类合并。 2. 在 `:host` 上用 CSS 自定义属性定义钩子，为组件提供主题化能力。 3. 使用 `var()` 并给出回退值，保证稳健。 4. 利用自定义属性穿透 Shadow DOM 的特性，让消费者简单设值即可定制外观。 5. 最后记得文档化这些钩子。 这样一套组合拳下来，你的 LWC 组件就会变得又灵活又好维护。好，大家可以在自己的开发环境里照着试一下，下课～

  ▶ 播放视频 查看详情
• 8

  Anti-Patterns — What NOT to Do

  第 61 页

  同学们，今天我们来聊聊Lightning Web Components里的五个关键反模式。什么是反模式呢？就是那些看起来好用、但长期会给你惹麻烦的写法。掌握这些，能让你少踩很多坑，代码也更稳定。好，我们一个一个来看。 第一个反模式，是别去样式化基本组件渲染出的HTML。举个例子，你用了Lightning的基本组件，比如按钮，然后你写CSS直接修改它内部生成的div或span标签。这很危险，因为Salesforce可能会随时更新这些内部结构，而且不会提前通知你。就像你照着别人的房子装修，但主人随时可能把墙敲掉，你的工作就全白费了。所以，别碰你不拥有的内部标记。 第二个反模式，是直接重写SLDS类。SLDS是Salesforce的设计系统，它定义了很多样式类。你可能会想覆盖这些类来定制外观，但直接改会引起冲突，未来升级时也可能失效。正确做法是用样式挂钩或自定义类。样式挂钩就像是预留的接口，让你安全地调整样式，而不会破坏底层结构。 第三个反模式，会有点技术细节，但很实用：别用querySelector去做精确的属性字符串匹配。你知道，在模板渲染时，浏览器可能会折叠空白，或者删除空的属性，导致你的选择器匹配不上。比如，你写`div[title="my title"]`，但渲染出可能变成`div[title="my title"]`无空格，或者缺了属性，你的代码就静默失败了。所以，避免这种脆弱的查找方式。 第四个反模式，是依赖CSS范围标记。在LWC里，每个组件样式会自动加上范围属性，比如`data-lwc`。但在API 59.0及以上版本，这些标记会模糊化成lwc-hash这种不可读的字符串。如果你在CSS里硬编码这些标记来写样式，一升级就全乱套了。别指望它们会保持不变。 第五个，是使用重载或!important选择器。我知道，调试时!important看起来能快速解决样式优先问题，但它会制造雪崩效应。一旦用了，后面想覆盖它就得用更多!important，样式表就变成了蜘蛛网，很难维护。所以，谨慎使用，尽量靠规范的结构来管理优先级。 好了，说了这么多不该做的，那该怎么做呢？我们有一组支持的方法：第一种，用设计变体，就是通过组件的属性来切换内置样式。第二种，实用程序类，比如SLDS自带的间距、对齐工具类，它们经过测试很可靠。第三种，样式挂钩，也就是CSS自定义属性，你可以安全地改变组件的颜色、尺寸等。第四种，自定义CSS类，结合SLDS类一起用，这样你既利用了基础设计，又有自己的特色。还有，用:Host伪类来样式化组件根元素，以及通过@import或类似方式导入共享样式。核心原则是，永远别依赖你不拥有的组件的内部属性或类，那些是Salesforce的地盘。 记住这些，你的代码就会更健壮，升级也不怕。好了，今天就讲到这里，希望大家在接下来动手时，能避开这些陷阱，写出漂亮的组件。

  ▶ 播放视频 查看详情
• 9

  Share CSS Style Rules

  第 62 页

  同学们，今天我们来聊聊一个在Lightning Web Components里非常实用的小技巧——怎么通过一个纯CSS的模块，来共享样式。 想象一下，你有很多组件，都需要用到同一套颜色、字体或者间距。要是每个组件都把样式复制一份，不仅麻烦，以后想改一个颜色，还得满世界去找，容易出错。这时候，我们就可以创建一个“样式库”组件。这个组件很特别，它里面只有一个CSS文件，还有一个配置文件，也就是我们常说的 `.js-meta.xml`，完全不需要HTML或者JavaScript文件。这样，它本身就是个轻量级的样式包，专门用来给别人提供样式。 那么别的组件怎么用它的样式呢？很简单，在你自己组件的CSS文件里，用一句 `@import 'namespace/moduleName'` 就可以导入。这里的 `namespace` 是命名空间，比如我们自定义组件常用的 `c`，而 `moduleName` 就是你给那个样式库组件起的名字。好比我们有一个组件叫 `c/sharedStyles`，那在你的CSS里就这么写：`@import 'c/sharedStyles';` 一下子，那个样式库里的所有样式就都进来了。 这里要注意一个限制：在标准的Lightning平台环境里，你只能在 `c` 和 `lightning` 这两个命名空间里去找样式模块。`c` 是咱们自己开发的命名空间，`lightning` 是系统自带的标准组件命名空间。但是，如果你使用了Lightning Web Security，也就是LWS，那么这个限制就放开了，你可以导入任何命名空间下的CSS模块，更灵活了。 还有一个小细节要记住，这个 `@import` 不支持媒体查询。也就是说你不能写 `@import 'c/sharedStyles' screen and (max-width: 600px);` 这种条件导入，它就是一个简单、直接的样式引入。导入进来的样式，和你在当前组件里亲手写的样式完全一样，会按照同样的优先级去级联、覆盖，就像它们本来就写在那里一样。 这么做的好处就非常明显了。第一，你所有用这个样式库的组件，看上去都是统一的，不会出现东一个按钮圆角、西一个直角的情况。第二，整个团队共享的是同一份样式源，这就是所谓的“单一事实来源”，改一个地方，所有地方都自动更新，省时省力。第三，它还能很好地和SLDS（Salesforce Lightning Design System）的styling hooks搭配使用。你可以利用这些钩子做集中的主题定制，比如把品牌色定义在共享样式模块里，一旦品牌换色，只需要改这个模块，所有组件就跟着焕然一新，相当方便。 好了，利用纯CSS模块组件来共享样式，就是这么简单又强大。大家可以自己动手试一下，建一个只有CSS和配置文件的组件，体验一把“一站式”换肤的乐趣。

  ▶ 播放视频 查看详情