C#调用PowerShell执行ExchangeOnline命令 部分Cmdlet无法识别

• 独立运行空间的完全隔离机制：PowerShell.Create()默认生成全新的无上下文运行空间，该运行空间不会继承本地交互式PowerShell窗口的模块加载状态、认证会话上下文，也不会跨空间共享同进程其他代码段完成的云服务认证连接。哪怕你在代码其他位置执行过Connect-AzureAD的认证操作，只要连接绑定在其他运行空间实例上，当前新建的运行空间既没有对应认证令牌，也没有导入Exchange Online、AzureAD的功能模块，自然会抛出Cmdlet不存在的错误。
• 新旧EXO模块的命令加载规则差异：独立交互PowerShell窗口中命令可正常运行，本质是窗口加载了匹配本地配置的Exchange Online模块版本——V1旧版模块会自动注册Get-Mailbox、Get-DistributionGroup这类无前缀命令，V3新版模块默认仅开放带EXO前缀的命令。这类命令注册逻辑完全绑定在运行空间初始化阶段，不会实现全局生效。
• 现有代码的逻辑缺口：贴出的核心业务脚本片段中，完全缺失Exchange Online连接、模块导入的执行逻辑，直接在空运行空间中调用云服务专属Cmdlet，本身就不具备命令可执行的基础条件。

• 统一全流程的运行空间绑定：不要拆分创建多个PowerShell运行空间分别执行认证操作和业务操作，需要将模块导入、云服务连接、业务逻辑执行全部放到同一个PowerShell实例中按顺序运行，保证会话上下文、模块加载状态能够被后续业务命令直接调用。
• 对齐交互窗口的模块加载配置：如果需要兼容旧的无前缀EXO命令，在执行Connect-ExchangeOnline时添加-UseRPSSession参数，显式开启兼容模式加载完整的传统命令集，和本地独立PowerShell窗口的命令可用范围保持一致，避免出现部分命令无法识别的问题。
• 增加前置校验拦截异常：在业务代码运行前，对需要调用的Cmdlet做存在性校验，比如执行Get-Command Get-EXOMailbox, Get-DistributionGroup -ErrorAction SilentlyContinue，如果校验返回结果为空，先手动执行模块导入操作，不要等业务代码运行时才抛出命令不存在的错误。
• 放弃对模块自动加载的依赖：在混合PowerShell脚本的开头，显式声明需要导入的模块，比如执行Import-Module ExchangeOnlineManagement, AzureAD -ErrorAction Stop，避免因为运行空间的权限、搜索路径配置问题，导致模块无法被自动发现和加载。

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