技能介绍

为什么 Apex 代码会悄悄出问题

Salesforce 的执行限制（governor limits）是平台安全模型的核心，但错误往往来自代码里不起眼的位置：一个 for 循环里嵌了 SOQL 或 DML，单次事务的记录数一旦超过 50 或 150，整段代码就会在运行时意外失败。更隐蔽的是共享声明缺失——类不写明 with sharing，就会继承调用者的共享上下文，同一个类在不同的入口下行为完全不同。另外，Apex 不会自动执行 CRUD/FLS 检查，用户通过 UI、REST 或 @InvocableMethod 触达的代码如果没有手动校验权限，就等于绕过了平台的安全模型。

这个技能检查什么

它是一套编写与审查 Apex 时的硬性检查清单，每一步都有明确的判定规则：

Governor Limit 安全检查：发现循环体内的 SOQL/DML 直接判定失败，要求先查询再循环，或收集变更后统一提交。
共享声明校验：每个类必须显式声明 with sharing、without sharing（需注释理由）或 inherited sharing，否则不能继续。
CRUD/FLS 强制：外部可达的方法必须验证对象和字段权限，内部可信上下文的方法可退而使用 with sharing。
SOQL 注入防护：字符串拼接用户输入的查询必须替换为绑定变量或白名单校验。
现代写法替换：鼓励使用 API 62.0+ 的写法，如 ?.、??、Assert.areEqual，以及 WITH USER_MODE 保证查询上下文一致。
测试覆盖清单（PNB）：每个功能必须覆盖正向、负向、批量（200–251 条）三条路径，且断言具体字段值或异常类型。
触发器架构规范：一个对象一个触发器，触发器体内只保留上下文检查与路由，业务逻辑全部下沉到 handler。

适用边界与注意点

这套规则适用于所有 Apex 类、触发器和测试文件的编写与审查场景，尤其适合需要长期维护的生产代码。需要注意：without sharing 不是禁忌，但必须写清使用场景（如系统级日志）；如果项目已经用了 ff-apex-common 之类的触发器框架，应该扩展它而不是另起炉灶；测试中的异步操作要用 Test.startTest() / Test.stopTest() 隔离限制计数。