Base Components — Naming, Namespaces & API Modules

好，我们来看一下Lightning Web Components里面引用组件和模块的一些命名习惯。你在HTML模板里直接用标签的时候，像按钮组，就写`lightning-button-group`，中间是连字符，这叫破折号分隔的名称。但是如果要在JavaScript文件里导入这个模块，就需要用斜线分隔的写法，比如`lightning/buttonGroup`，这代表一个模块路径。记着：模板里用标签名，JS里用模块路径，这两种写法对应不同的使用场景。 接下来说几个重要的最佳实践，帮你少踩坑。第一，只使用文档上公开记录过的属性。那些看起来能用、但实际上属于内部或保留的属性，随时可能被Salesforce悄悄改掉，你的代码就崩了，所以要管住手。第二，关于样式，尽量多用组件自带的一些变体，还有Salesforce设计系统提供的工具类，比如用`variant`属性或者直接套SDS的类名，而不是自己写一堆自定义样式去强行覆盖，这样维护成本更低，也符合平台规范。第三，当你需要拿到模板里某个元素的引用时，推荐用`lwc:ref`指令标记它，然后在JavaScript里通过`this.refs.xxx`去访问。这样做要比传统的`id`加`querySelector`高效得多，因为`this.refs`是直接引用，不需要让引擎在整个DOM里扫描查找，性能更好。 最后，我们看一下这些API模块大概怎么分类。它们可以分成三类，这样你找起来也更方便。第一类是跟界面直接相关的UI模块，用来创建用户看得见的交互元素，比如toast消息、提示框、警告框、确认对话框，这些通常都是调用`.open()`方法就直接弹出来。第二类是服务或工具模块，提供平台层面的能力，比如导航到别的页面，或者使用消息服务在组件间通信。第三类是数据访问模块，封装了Lightning Data Service的线适配器，还有一些专门处理Salesforce数据的函数，让你读写数据更简单。搞清楚这几类的区别，以后要用什么功能，直接去对应类别里找就好了。