我非常理解你遇到的这个痛点——自定义Enable规则里调用Xrm API就触发命令栏刷新，导致函数执行两次，而且按钮状态还依赖第二次的返回值，常规的标记变量方案根本行不通，临时hack又总让人心里不踏实。

先给你拆解下问题根源：当你在Enable规则的JS函数中调用Xrm的工具函数时，Dynamics 365会默认认为表单的状态可能发生了变化，从而触发命令栏的重新评估流程，这就是第二次调用的由来。而因为命令栏最终会用最后一次评估的结果来设置按钮状态，所以你没法简单跳过第二次调用。

下面是几个更合理的解决方案，按推荐程度排序：

方案一：提前缓存数据，彻底避免在规则函数中调用Xrm API #

这是最符合平台设计逻辑的方案——把需要的数据获取逻辑从Enable规则中剥离，放到表单的初始化或字段变更事件里提前缓存，规则函数只负责读取缓存值判断状态，完全不碰Xrm API，自然不会触发刷新。

实现步骤： #

1. 先在表单的OnLoad事件中添加数据缓存逻辑，同时监听字段变化更新缓存：

function preCacheButtonData(executionContext) {
  const formContext = executionContext.getFormContext();
  const targetField = formContext.getAttribute("your_target_field");
  
  // 初始化缓存字段值
  formContext.context.sharedVariables.set("buttonCachedValue", targetField.getValue());
  
  // 监听字段变化，实时更新缓存
  targetField.addOnChange(function() {
    formContext.context.sharedVariables.set("buttonCachedValue", targetField.getValue());
  });
}

2. 然后修改你的Enable规则函数，直接读取缓存判断：

function myButtonFunc(executionContext) {
  const formContext = executionContext.getFormContext();
  const cachedValue = formContext.context.sharedVariables.get("buttonCachedValue");
  
  // 这里写你的按钮显隐逻辑
  return cachedValue === "expected_value";
}

这个方案从根源上消除了二次调用的触发条件，逻辑清晰，也没有任何hack成分，是首选方案。

方案二：用闭包/共享变量区分调用阶段，缓存Xrm API结果 #

如果因为某些原因没法提前缓存数据，你可以通过标记调用阶段的方式，在第一次调用时获取并缓存Xrm数据，第二次调用时直接用缓存值处理逻辑，同时确保第二次返回的是最终状态。

闭包实现（适合单按钮场景）： #

const myButtonFunc = (function() {
  let cachedData = null;
  let isFirstInvocation = true;

  return function(executionContext) {
    if (isFirstInvocation) {
      // 第一次调用：获取Xrm数据并缓存，返回临时值（避免按钮闪烁）
      const formContext = executionContext.getFormContext();
      cachedData = formContext.getAttribute("your_target_field").getValue();
      isFirstInvocation = false;
      return true; // 临时返回true，让按钮先保持可见
    } else {
      // 第二次调用：用缓存数据处理逻辑，返回最终状态
      const shouldEnable = cachedData === "expected_value";
      // 重置标记，确保下次触发规则时能重新执行
      isFirstInvocation = true;
      cachedData = null;
      return shouldEnable;
    }
  };
})();

共享变量实现（适合多按钮或表单刷新场景）： #

闭包可能在表单刷新时失效，用表单的sharedVariables更可靠：

function myButtonFunc(executionContext) {
  const formContext = executionContext.getFormContext();
  const sharedVars = formContext.context.sharedVariables;
  
  const isFirstCall = sharedVars.get("myButtonFirstCall") !== false;
  
  if (isFirstCall) {
    // 第一次调用：缓存数据，标记阶段
    const fieldValue = formContext.getAttribute("your_target_field").getValue();
    sharedVars.set("myButtonCachedValue", fieldValue);
    sharedVars.set("myButtonFirstCall", false);
    return true;
  } else {
    // 第二次调用：处理逻辑，返回最终状态
    const cachedValue = sharedVars.get("myButtonCachedValue");
    const shouldEnable = cachedValue === "expected_value";
    // 重置标记
    sharedVars.set("myButtonFirstCall", true);
    sharedVars.set("myButtonCachedValue", null);
    return shouldEnable;
  }
}

这个方案本质是顺应了平台的二次调用机制，把两次调用的职责拆分，避免了逻辑冲突。

为什么之前的标记变量方案失效？ #

你提到的社区标记变量方案，通常是尝试跳过第二次调用，但问题在于命令栏最终会采用最后一次评估的返回值来设置按钮状态——如果跳过第二次调用返回默认值，就会覆盖第一次的正确结果；如果强行在第一次返回最终结果，又会因为调用Xrm API触发第二次调用，导致状态被覆盖。所以必须把两次调用的逻辑串联起来，而不是跳过。

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