DefaultAzureCredential可自动适配本地开发与云环境，无需手动判断托管标识；本地依赖az login或VS登录，上云自动使用系统/用户分配MI，需确保RBAC权限配置正确且URI格式规范。
Managed Identity在C#中怎么初始化DefaultAzureCredential
直接用 DefaultAzureCredential 是最简路径，它会按顺序尝试多种凭据（包括托管标识），不用手动判断当前环境是否启用了托管标识。
常见错误是硬编码 ClientSecretCredential 或 EnvironmentCredential，导致部署到Azure VM/Function/App Service时失败——因为这些环境根本没提供 client secret 或环境变量。
- 开发时本地运行：自动 fallback 到
VisualStudioCredential或AzureCliCredential（需提前az login） - Azure App Service / Function / VM：自动使用系统分配或用户分配的托管标识，无需额外配置
- 必须确保 Azure 资源已启用托管标识，并且该标识已被授予目标资源（如 Key Vault、Storage Account）的 RBAC 权限（例如
Key Vault Reader）
C#调用Azure Key Vault时如何传入托管标识凭据
用 DefaultAzureCredential 初始化 SecretClient 即可，不需要改业务逻辑代码，和本地调试保持一致。
示例：
var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri("https://myvault.vault.azure.net/"), credential);
var secret = await client.GetSecretAsync("MyConnectionString");
注意点：
- URI 必须是完整 HTTPS 地址，结尾不加
/secrets/xxx——那是 REST API 路径，SDK 自动拼接 - 如果报错
Forbidden或Access denied，不是代码问题，而是托管标识缺少 RBAC 权限（进 Azure Portal → Key Vault → Access control (IAM) → Add role assignment） - App Service 启用托管标识后，可能需要重启应用才能生效
用户分配托管标识（User-Assigned MI）在C#里怎么指定
当一个应用要使用多个托管标识，或需要跨资源复用时，得用用户分配的托管标识，并显式告诉 DefaultAzureCredential 用哪一个。
关键参数是 managedIdentityClientId，值为用户分配 MI 的 Client ID（不是对象ID，也不是资源ID）。
- 在 Azure Portal 查用户分配 MI 的 Client ID：进入该 MI 资源页 → Properties → Client ID
- 构造凭证时传入：
new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = "xxxxx-xxxx-xxxx-xxxx-xxxxxxxx" }) - 若不指定，
DefaultAzureCredential默认只尝试系统分配的托管标识；指定后就跳过系统分配，直连用户分配的 - 用户分配 MI 的权限也必须单独授予目标 Azure 资源，不能复用系统分配 MI 的权限
为什么DefaultAzureCredential在本地跑不通但上云就正常
这不是 bug，是设计行为。本地没有托管标识上下文，DefaultAzureCredential 会继续尝试后续凭据方式（如 CLI、VS 登录），但如果都没配，就会抛出 CredentialUnavailableException。
典型表现：
- 异常消息含
ManagedIdentityCredential authentication failed，但后面紧跟EnvironmentCredential authentication failed等 —— 说明它试了所有方式都失败 - 解决方法不是“禁用托管标识”，而是本地配好开发凭据：运行
az login，或设置AZURE_CLIENT_ID+AZURE_TENANT_ID+AZURE_CLIENT_SECRET（仅测试用） - 不要在代码里写 if-else 切换凭据类型，那会让环境耦合变重，违背托管标识的设计初衷
真正容易被忽略的是：托管标识本身不提供“连接字符串”或“密钥”，它只提供访问令牌；所有权限控制、审计日志、轮换都落在 Azure IAM 和目标服务的访问策略上，而不是你的 C# 代码里。
