虽然阿里的答案肯定是解决这个问题的最结构化和最强大的方法，但我想指出一个似乎对我也有好处的工作。
我创建了第二个策略（相同的声明、相同的API连接器部署、相同的秘密等）。在那里，我只是在页面布局中标记电子邮件地址不需要验证。
但是，我创建了两种API连接器类型。指向相同的API部署，但向连接器传递查询参数（&emailVerified=true或&emailVerified=false）。在连接器逻辑中，我执行特定的验证，并将标记与我的用户概要文件一起持久化，这样我就可以在将来知道概要文件是否已被验证。
一旦用户注册，我就可以轻松地利用与以前相同的登录策略，只需知道在声明中，有一个不同的tfp声明也可以用于验证。

是的，这是可能的，也是直接的。您可以首先收集电子邮件地址只从用户使用self-asserted technical profile。然后调用REST API endpoint来检查这个用户是否应该通过验证。以下是仅收集电子邮件并做出有条件决定的示例代码：
https://github.com/azure-ad-b2c/samples/tree/master/policies/dynamic-sign-up-sign-in
您的第一个编排步骤是：

<OrchestrationStep Order="1" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="CheckIfVerificationNeeded-Exchange"
          TechnicalProfileReferenceId="CheckIfVerificationNeeded" />
      </ClaimsExchanges>
    </OrchestrationStep>

您应该设置一个名为IsVerificationRequired的claim。该值应该由您的API响应设置为OutputClaim。
您需要自声明的技术配置文件来收集电子邮件。该技术配置文件应该将您的REST API技术配置文件称为validation technical profile。
稍后在您的用户旅程中，您仅在IsVerificationRequired = true时显示验证。
它看起来像这样：

<OrchestrationStep Order="X" Type="ClaimsExchange">
          <Preconditions>
           <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
              <Value>IsVerificationRequired</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="EmailVerification-Exchange"
              TechnicalProfileReferenceId="EmailVerification" />
          </ClaimsExchanges>
        </OrchestrationStep>

您可以使用SubJourneys使其更简洁、更复杂，我强烈推荐使用SubJourneys。然而，我一直保持这一简单的传达概念。
如果你能选择这个答案，如果它解决了你的问题，我将不胜感激。谢谢你，谢谢