我来结合你的场景和错误细节，一步步拆解你的疑问：

1. 为什么之前几个月正常运行，现在突然失败？ #

核心问题出在PackageSourceMapping 启用后，私有包源的认证上下文没有被正确传递给dotnet restore，导致这些源被NuGet判定为“不可用/未通过认证”，进而在解析私有包时直接跳过（对应错误里的“the following source(s) were not considered”）。

之前能正常工作，是因为早期的工具链存在“隐式兼容”：

• 旧版本的DotNetCoreCLI@2任务在执行restore命令时，会自动帮你从Azure DevOps服务连接中注入私有源的认证信息；
• 或者旧版本NuGet对PackageSourceMapping的逻辑更宽松，即使源的认证存在小问题，也会尝试 fallback 查找，不会直接跳过源。

突然失败的触发点，大概率是你流水线依赖的工具版本发生了变化：比如NuGetToolInstaller@1默认安装了最新的NuGet版本，或者DotNetCoreCLI@2升级到2.266.0后，取消了之前的隐式认证逻辑，直接打破了原有平衡。

2. 是不是DotNetCoreCLI@2或NuGet的更新导致的？ #

是的，这两者的更新都可能是直接诱因：

• DotNetCoreCLI@2任务的变化：2.266.0版本的任务对restore预设命令的处理逻辑做了调整，当使用feedsToUse: config时，不再自动注入私有源的认证信息，尤其是启用PackageSourceMapping后，认证上下文的传递被完全打断；
• NuGet版本的严格化：如果你的流水线自动升级到了NuGet 6.8+，这个版本对PackageSourceMapping的校验逻辑变得更严格——它会强制验证每个包对应的源是否有有效凭据，若源未通过认证，就会直接跳过该源，而不是像旧版本那样忽略认证问题继续查找。你的错误信息完全符合这个行为特征。

3. 为什么新配置现在能正常工作？ #

你的新配置正好补上了两个核心缺失环节：

• NuGetAuthenticate@1的作用：这个任务会主动将你指定的Azure DevOps服务连接（Uno）的认证凭据注入到你的nuget.config中，确保私有源的认证信息是有效的、能被NuGet识别的；
• 改用custom命令执行restore：之前用DotNetCoreCLI的restore预设命令时，任务会对feedsToUse: config场景做额外的参数封装，反而干扰了PackageSourceMapping和认证信息的结合；而用custom: restore直接调用原生dotnet restore命令，会完全使用经过NuGetAuthenticate处理后的nuget.config，此时所有私有源都带有有效凭据，PackageSourceMapping能正确识别并使用这些源解析私有包，自然就解决了NU1100错误。

补充个小建议：如果想验证工具版本的影响，可以暂时在NuGetToolInstaller@1中指定旧版本的NuGet（比如6.7.x），看是否能复现之前的正常状态，但长期来看，显式添加NuGetAuthenticate+使用custom restore的配置更可靠，完全符合NuGet新版本的最佳实践，也能避免后续工具更新带来的隐式兼容问题。