技能介绍

需要被规范的组件开发场景

在 Salesforce 开发里，LWC、Aura 和 Visualforce 组件各有各的写法，可实际写代码或 review 的时候，很容易忽略数据访问选错模式、安全规则没守住、样式硬编码破坏 SLDS、可访问性缺漏这些细节——不是不知道要规范，而是没有一份统一的检查清单把这些点串起来，导致不同人写的组件质量参差不齐。

技能如何拆解各组件的标准

这个技能把三类组件的关键要求拆成了可逐条对照的检查项：

LWC 部分：先明确不同数据访问场景的对应模式，比如用 @wire(getRecord) 做响应式单记录读取、复杂查询用 cacheable=true 的 @wire 方法，避免在 connectedCallback 写副作用；安全上禁止用 innerHTML 塞用户数据，必须用模板绑定 {expression}；样式不能硬编码颜色，得用 var(--slds-*) 语义 token，还要测深浅模式；可访问性要满足 WCAG 2.1 AA，比如图标按钮加 aria-label，模态框做好焦点管理；组件通信按方向选 @api、CustomEvent 或 LMS，别碰 document.querySelector；有交互或调 Apex 的组件得写 Jest 测试，用 @salesforce/sfdx-lwc-jest 做 mock。
Aura 部分：先划清和 LWC 的边界——新组件一律用 LWC，只有 Aura 专属场景（比如继承 force:appPage）才用 Aura；安全上 @AuraEnabled 方法必须显式加 with sharing 并手动做 CRUD/FLS 检查，不能用 {!v.something} 直接输出未转义的用户数据；事件设计优先组件事件，应用事件只在组件事件覆盖不到时用，混合栈用 LMS 解耦。
Visualforce 部分：XSS 防护上 escape="false" 对用户数据是禁区，富文本得服务端白名单过滤；CSRF 防护必须用 <apex:form>，别写裸 <form>；SOQL 注入要靠绑定变量，别拼 URL 参数；视图状态要控制在 135KB 内，计算用的字段设 transient，只读页加 readonly="true"；自定义控制器要手动做 FLS 检查，别依赖标准控制器的自动校验。

适用边界与注意点

这套标准不是万能的：如果是全新组件，优先走 LWC，Aura 只在对接老托管包、用 Aura 专属事件时才考虑；Visualforce 里的丰富文本渲染得服务端做白名单，不能图省事关掉转义。另外，规则里的“必须”“禁止”是硬约束，但像 Jest 测试，只针对有用户交互或调 Apex 的组件，别给纯展示组件硬加测试——核心是把“对的写法”和“容易踩的坑”都摆出来，让写代码或 review 的人能逐条对照，不用自己再翻零散的文档。