合规优化：在Salesforce包提交中优先处理SFDX Scanner检测结果

是否必须修复所有问题？ #

不是所有检测项都强制要求修复，核心分两类：

• 强制修复项：这类是包提交的硬门槛，必须修复才能通过。包括：
  • 违反Salesforce安全合规的高危问题（比如SOQL注入、未做CRUD/FLS检查）
  • 语法/编译错误（直接导致包无法构建上传）
  • AppExchange提交要求的强制规则（如果是上架应用，官方明确要求的合规项）
• 可选优化项：这类不影响包提交，但属于代码质量/最佳实践范畴，比如命名不规范、冗余代码、注释缺失等，可根据团队资源安排后续迭代修复。

问题优先级排序建议 #

按影响程度从高到低排序：

• 第一优先级（立即修复）：安全高危问题、编译/语法错误、Salesforce强制合规规则违反项——这些直接阻碍包提交或带来严重安全风险
• 第二优先级（迭代内修复）：性能类问题（未批量DML、未优化的SOQL查询、递归触发器）——会影响应用运行效率与用户体验
• 第三优先级（后续批量修复）：代码规范/最佳实践类问题（命名不规范、冗余代码、注释缺失）——属于技术债务，可在迭代间隙集中处理
• 第四优先级（按需评估）：潜在风险类问题（未处理的异常、空指针隐患）——如果当前业务逻辑未触发，可先记录，后续版本修复

流程优化建议 #

• 提前集成扫描到开发流程：不要等到提交前才跑扫描，把sf scanner run命令加到本地开发的编译脚本，或者用Git Hooks在代码提交到远程仓库前自动触发扫描，提前发现问题
• 自定义扫描规则集：修改scanner-config.json，只启用与团队规范、Salesforce提交要求匹配的规则，关闭无关的最佳实践规则，减少无效告警
• 建立技术债务清单：把低优先级问题统一记录，安排专门的迭代或开发间隙批量修复，避免占用核心业务开发时间
• 团队统一规范：组织内部培训，明确哪些是必须遵守的编码规则（比如CRUD/FLS检查、批量DML），从源头减少问题产生
• 处理误报：对于确定是误报的规则，在配置文件里排除对应的类、方法或代码块，避免重复干扰

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