作为 Salesforce 开发者，我们经常面临一个挑战：如何在保证数据安全的前提下，灵活地满足复杂的业务共享需求？虽然 Salesforce 提供了强大的标准功能，如组织范围默认（OWD）、角色层级和共享规则，但在处理特定、动态的业务逻辑时，这些声明性工具可能会显得力不从心。这时，我们就需要深入探讨 Apex 共享 这一强大的后端能力。
在本文中，我们将深入探讨 Apex 共享的核心概念、底层机制、实际应用场景以及 2026 年视角下的最佳实践。我们将不仅学习“怎么做”，更重要的是理解“为什么这么做”，以及如何在保证系统性能和可维护性的前提下，通过编程方式精细控制记录的访问权限。
目录
核心概念：什么是 Apex 共享？
简单来说，Apex 共享 是指我们利用 Apex 代码以编程方式在 Salesforce 中创建、修改或删除记录共享关系的能力。这通常是通过直接操作与对象关联的“共享对象”来完成的。
为什么我们需要它？
想象一下，你有一个私有的“项目”对象。通常情况下，只有项目经理和其上级能看到该项目。但现在有一个需求：当项目状态变为“紧急”时，需要自动让“客户支持团队”的特定队列拥有只读权限，以便他们能及时响应。这种基于动态状态的共享逻辑，标准的共享规则难以直接实现（因为规则通常基于记录所有者或特定的条件判断，而不是动态的工作流触发）。这时，Apex 共享就成为了我们的救星。
核心特性解析
在我们开始编码之前，有几个关键特性需要牢记于心：
- 记录级权限控制：Apex 共享仅作用于记录级别。它无法赋予对象级（CRUD）或字段级（FLS）的权限。这意味着，如果用户根本没有读取“项目”对象的权限，无论我们怎么在 Apex 中共享记录，用户依然无法访问。
- 与 OWD 的关系：Apex 共享只能“扩展”权限，不能“收缩”权限。如果对象的 OWD 设置为“公共读写”，那么通过 Apex 共享设置为“只读”是没有意义的，因为用户已经拥有了编辑权。通常，Apex 共享最常用于 OWD 为“私有”或“公共只读”的场景。
- Governor Limits（ governor 限制）：操作共享对象时，我们需要特别注意 DML 操作的限制。在处理批量数据时，直接在循环中插入共享记录很容易触发限制。
理解共享对象
在 Salesforce 中，每个支持共享的自定义对象（以及部分标准对象）都会自动生成一个与之对应的“共享对象”。这个对象专门用于存储该对象的访问权限矩阵。
命名规则
- 自定义对象：如果你的对象 API 名称是 INLINECODE2a7bb2ef，那么它的共享对象名称就是 INLINECODEfc6944c0。
- 标准对象：通常为 INLINECODE6a0eea55（例如 INLINECODEd025c795）。
共享对象的关键字段
当我们通过 Apex 创建共享记录时，实际上就是在填充以下字段：
ParentId*：这是被共享的记录的 ID。例如，我们要共享哪个项目？
UserOrGroupId*：这是被授予访问权限的用户 ID 或 组/队列 ID。
AccessLevel*：这是最关键的属性。对于自定义对象，通常是 INLINECODEaca0dc82 或 INLINECODE5343db89。某些标准对象可能还有其他级别。
RowCause*：指定共享的原因。这是一个只读字段，由系统根据我们创建记录的方式自动填充。常见的值包括：
* Manual：手动共享，通常通过 Apex 或 UI 手动添加。
* Owner：基于记录所有者的权限（系统自动）。
* Rule：基于共享规则（系统自动）。
* Implicit：基于角色层级（系统自动）。
2026 现代开发范式：从 CRUD 到“重建即代码”
在 2026 年的今天，仅仅“写对”代码已经不够了。我们面临着更复杂的系统架构和更严格的合规要求。在我们的最新实践中，我们采用了 “重建即代码” 的理念来处理 Apex 共享。
摒弃“增量式”共享，拥抱“状态重建”
早期的 Apex 共享逻辑往往陷入“增删改查”的陷阱：当状态改变时增加权限，当状态回退时删除权限。这种方式非常脆弱，一旦中间步骤出错，数据就会变得不一致（即“脏数据”）。
现代解决方案：我们将共享逻辑视为 状态的确定性重建。每次业务逻辑触发时，我们不再是去“修改”权限，而是先 清空 该逻辑产生的所有历史共享痕迹，然后根据当前最新的业务数据 完全重建 权限。这种“幂等性”设计是现代 Salesforce 开发中保证数据一致性的关键。
实战案例：构建企业级 Project 共享逻辑
让我们通过一个完整的场景来演练。假设 INLINECODE3e59093e 的 OWD 为 INLINECODEf67ce1c9。需求是：当项目优先级为 INLINECODEb0e805b5 且部门为 INLINECODEa54ff929 时，共享给销售总监组。
示例 1：生产级的批量共享处理
在 2026 年，我们绝不会把 DML 写在循环里。下面的代码展示了如何利用 Database.SaveResult 进行批量处理和错误分析，这是企业级代码的标配。
public inherited sharing class ProjectSharingService {
// 定义共享原因常量，便于维护和复用
private static final String REASON_HIGH_PRIORITY = ‘High_Priority_Alert__c‘;
/**
* 核心服务方法：批量重建项目共享权限
* 采用“先删后建”的策略确保状态一致性
*/
public static void recalculateProjectSharing(List projects) {
if (projects.isEmpty()) return;
Set projectIds = new Map(projects).keySet();
// 第一步：清理旧权限 (防止权限残留)
cleanupOldShares(projectIds);
// 第二步：筛选需要共享的记录
List newShares = new List();
// 假设我们有一个配置对象或自定义元数据来存储“销售总监组”的ID
Group salesDirectors = [SELECT Id FROM Group WHERE DeveloperName = ‘Sales_Directors‘ LIMIT 1];
for(Project__c proj : projects) {
// 业务逻辑：仅处理高优先级项目
if (proj.Priority__c == ‘High‘) {
Project__Share share = new Project__Share();
share.ParentId = proj.Id;
share.UserOrGroupId = salesDirectors.Id;
share.AccessLevel = ‘Read‘;
// 使用 Apex Managed Sharing Reason 便于审计
share.RowCause = Schema.Project__Share.RowCause.High_Priority_Alert__c;
newShares.add(share);
}
}
// 第三步：批量插入，并允许部分成功
if (!newShares.isEmpty()) {
Database.insert(newShares, false);
}
}
/**
* 清理指定项目的特定原因共享记录
* 注意：我们只删除由 Apex Managed Share Reason 创建的记录，
* 不会影响手动共享或基于规则的共享。
*/
private static void cleanupOldShares(Set projectIds) {
List oldShares = [
SELECT Id
FROM Project__Share
WHERE ParentId IN :projectIds
AND RowCause = :Schema.Project__Share.RowCause.High_Priority_Alert__c
];
if (!oldShares.isEmpty()) {
// 异步删除以避免主事务可能的锁定问题，或者同步删除视业务需求而定
// 这里演示同步删除，配合 AllOrNone=false 保证鲁棒性
Database.delete(oldShares, false);
}
}
}
代码解析：请注意这里的“清理”步骤。这是很多初级开发者容易忽略的。如果不清理，当项目从“高优先级”降级时，之前的共享权限依然存在，造成数据泄露。
示例 2：异步处理与可观测性
在大型数据迁移或批量更新时，共享计算可能会非常耗时。现代架构（2026 Style）要求我们将重计算逻辑移出同步事务。
public class ProjectSharingHandler {
/**
* 触发器入口点
* 我们仅仅是将计算任务分发给异步队列，保证用户界面响应迅速
*/
public static void handleAfterUpdate(List newList, Map oldMap) {
Set idsToProcess = new Set();
for(Project__c proj : newList) {
Project__c old = oldMap.get(proj.Id);
// 仅当优先级字段发生变化时才触发重计算
if (proj.Priority__c != old.Priority__c) {
idsToProcess.add(proj.Id);
}
}
if (!idsToProcess.isEmpty()) {
// 2026 年最佳实践：使用 Queueable 而非 @Future，支持链式调用和更复杂的监控
System.enqueueJob(new ProjectSharingQueueable(idsToProcess));
}
}
// Queueable 类实现
public class ProjectSharingQueueable implements Queueable, Database.AllowsCallouts {
private Set projectIds;
public ProjectSharingQueueable(Set ids) {
this.projectIds = ids;
}
public void execute(QueueableContext context) {
// 在这里调用我们的核心服务
ProjectSharingService.recalculateProjectSharing(
[SELECT Id, Priority__c FROM Project__c WHERE Id IN :projectIds]
);
// 现代化应用实践：记录自定义日志用于监控
// LogSharingEvent(projectIds); // 假设我们有一个事件发布机制
}
}
}
深入探讨：常见陷阱与 2026 最佳实践
在我们最近的一个大型项目中，我们遇到了一些非直觉的行为。让我们来复盘一下这些经验。
1. “幽灵”共享与行锁
你可能会遇到 UNABLE_TO_LOCK_ROW 错误。这通常发生在父子记录同时被修改时。
解决方案：使用 INLINECODEb899e3ad 锁定父记录，或者如上所述，将共享逻辑放入 INLINECODE8391d4f5 或 Queueable 中，在原始事务提交后执行，从而减少锁竞争时间。
2. 测试的陷阱
默认情况下，测试用户拥有“修改所有数据”权限。这会导致你的测试用例通过，但在实际运行中失败。
解决方案：始终使用 System.runAs(user) 来模拟非特权用户的视角。
@isTest
private class ProjectSharingTest {
@testSetup
static void setup() {
// 创建测试用户和项目数据
}
@isTest
static void testVisibility() {
User standardUser = [SELECT Id FROM User WHERE Alias = ‘stdusr‘];
Project__c proj = [SELECT Id FROM Project__c LIMIT 1];
Test.startTest();
System.runAs(standardUser) {
// 在共享之前，用户应该看不到记录
List before = [SELECT Id FROM Project__c WHERE Id = :proj.Id];
System.assertEquals(0, before.size(), ‘OWD应为私有，用户不应可见‘);
// 执行共享逻辑
ProjectSharingService.recalculateProjectSharing(new List{proj});
}
// 再次切换上下文验证（因为 runAs 内的 DML 可能需要提交才能在特定场景生效，
// 但通常在同一个测试方法中 runAs 结束后权限已更新，视具体情况而定，
// 这里推荐在 runAs 内部再次查询以验证）
System.runAs(standardUser) {
List after = [SELECT Id FROM Project__c WHERE Id = :proj.Id];
System.assertEquals(1, after.size(), ‘Apex共享后，用户应可见‘);
}
Test.stopTest();
}
}
3. 未来的替代方案：Dynamic Forms 与 LWC
随着 Salesforce Dynamic Forms 和 Lightning Web Components (LWC) 的发展，有些开发者可能会问：“我们还需要后端共享吗？”
答案是肯定的。虽然 UI 可以隐藏字段，但后端 API（如 REST API 或 SOQL）依然可以直接访问数据。Apex 共享是最后一道防线，确保数据安全性在 API 层面也是严密的。
总结
Apex 共享是 Salesforce 平台中处理复杂、细粒度数据安全需求的利器。通过直接操作 Share 对象，我们可以突破标准功能的限制，实现真正以业务逻辑驱动的权限管理。
回顾一下，我们今天深入探讨了：
- 核心理念：理解 Apex 共享作为 OWD 扩展的定位，以及“扩展而非收缩”的原则。
- 现代架构：采用“重建”策略而非增量修改，保证数据的一致性和幂等性。
- 性能优化：通过
Database类的方法进行批量处理和部分成功控制，并结合异步处理机制应对高负载场景。 - 实战经验：如何编写健壮的测试用例，以及如何处理生产环境中的锁定问题。
在你的下一个项目中，如果遇到声明性权限无法解决的难题，不妨尝试使用 Apex 共享，并遵循我们今天讨论的 2026 年最佳实践，这将为你的架构设计带来极大的灵活性和安全性。