4. 邀请与接受共享
Azure 数据共享的跨租户协作，本质上不是“把数据复制给对方”，而是把一份受控的、只读的数据集访问权授予对方租户中的某个主体。理解这一点，是理解邀请与接受流程的关键。整个链路可以拆成四个连续动作：共享方创建共享并发出邀请、受邀方在自身租户中接受邀请、接受后共享在目标侧映射为一个可访问的存储入口、最后通过实际读取验证权限与网络路径是否真正打通。下面按这条链路展开。
一、邀请：共享方在源租户中发起
共享方在源存储账户（或源 Azure Data Share 资源）中创建共享，添加数据集，然后添加接收方。这里有一个容易被忽略的细节：邀请的接收对象是“接收方的 Azure 登录身份”，而不是某个存储账户。常见做法是填写接收方的用户 UPN（如 analyst@contoso.com）或服务主体/托管标识的标识符。填写错误会导致对方在“收到的共享”列表中看不到邀请。
创建共享时通常需要设置共享名称、描述、数据集列表以及可选的快照计划。若采用“基于快照”的共享模式，数据按计划或手动触发复制到接收方侧；若采用“就地共享”（in-place），则接收方直接读取源存储，不产生副本。两种模式对后续“映射到目标存储”的影响完全不同，这一点在下一节会体现。
邀请发出后，共享方可以在共享资源的“已发送的共享”中看到状态：Pending（待接受）、Accepted（已接受）或 Rejected（已拒绝）。状态是判断流程是否推进的第一手依据。
二、接受：受邀方在目标租户中确认
受邀方登录 Azure 门户，进入“Azure Data Share”服务的“收到的共享”页面。若邀请已正确送达，会看到一条待处理记录。接受操作本身很简单，但有两个前提必须满足：
- 受邀身份必须对该订阅或资源组具有创建 Data Share 资源的权限；
- 若采用快照模式，目标区域需要有可用的存储账户作为落地位置。
接受后，系统会在受邀方租户中生成一个“已接受的共享”资源。此时共享关系建立，但数据尚未真正可读——还需要完成存储映射。
三、映射到目标存储：把共享数据集落到可访问位置
映射是整条链路中最容易出错的一步。对于快照模式，受邀方需要为每个数据集指定目标存储账户、容器/文件系统以及可选的文件夹路径。映射完成后，数据才会按快照计划或手动触发写入该位置。对于就地共享模式，受邀方不需要指定目标存储，而是直接获得对源存储的只读访问入口，此时“映射”更多体现为权限与网络路径的配置。
映射时建议遵循以下原则：目标容器与源数据集保持清晰的命名对应关系，例如源数据集为 sales/2024，目标可映射为 shared-sales/2024；避免多个数据集映射到同一路径造成覆盖；对 Parquet/CSV 等格式，确认目标存储的层级结构与读取工具的预期一致。
四、验证数据可访问性：从“看到”到“读到”
验证不能只看门户状态，必须实际读取。推荐按以下顺序检查：
- 权限验证：确认受邀身份对目标存储容器具有读取权限（快照模式）或对源存储具有共享授予的读取权限（就地模式）。
- 路径验证：在目标存储中确认数据文件已出现，且目录结构与映射一致。
- 内容验证：用 Azure Storage Explorer、azcopy 或 SDK 实际读取一个文件，确认内容非空且格式可解析。
- 网络验证：若源或目标存储启用了防火墙或私有终结点，确认调用方所在网络能够到达对应终结点。
下面这张图把“邀请—接受—映射—验证”四个阶段的对象、状态变化和判断点放在同一条链路上，便于对照排查。
五、把流程串起来：一个可复用的检查顺序
实际排障时，建议严格按“状态—映射—权限—网络—内容”的顺序推进，不要跳步。因为后一步的失败往往由前一步的遗留问题引起。例如，映射显示成功但读取为空，通常不是权限问题，而是快照尚未触发或目标路径写入了空分区；此时应先检查快照执行记录，而不是反复调整防火墙。
另外，跨租户场景下要特别注意两点：一是邀请与接受必须使用正确的租户上下文，在门户右上角确认当前目录是源租户还是目标租户；二是就地共享与快照共享的验证方式不同，前者验证的是对源存储的读取链路，后者验证的是目标存储中的副本。把这两点区分清楚，绝大多数“看不到数据”的问题都能快速定位到具体环节。
完成上述四步后，建议在团队内保留一份简短的共享记录：共享名称、数据集、模式（快照/就地）、目标存储路径、验证时间与验证人。这份记录在后续权限变更、存储迁移或故障复盘时，能显著降低沟通成本。