dotnet test 相对目录被拼了两遍：在项目目录无参运行

执行 dotnet test .\test\Example.Tests\，错误中的项目路径却变成 ...\test\Example.Tests\test\Example.Tests\Example.Tests.csproj。相对目录片段重复出现时，先核对 SDK 和命令入口，不要真的再创建一层同名目录去迎合错误路径。

Windows 上 SDK 11.0.100-rc.2.26504.105 有这条具体表现；相同目录入口在对应项目的 .NET 10 构建中能够运行。这里针对 RC2 的路径处理，不代表所有 .NET 11 版本或所有测试失败都具有同一根因。

在真实项目目录运行无参命令

PowerShell 可以用下面的局部目录切换。Example.Tests 要替换为实际目录：

Push-Location .\test\Example.Tests -ErrorAction Stop
try {
    dotnet test
}
finally {
    Pop-Location
}

先确保目录切换成功，再执行测试。在自动化脚本中应让切换失败成为终止错误，不能在错误目录继续运行。finally 用于恢复原目录；调用脚本还应按 CI 约定保留并传递测试命令的退出码。

原来传入的配置、筛选器和日志参数应继续保留，仅移除这条相对目录参数。不要为了验证路径变动顺手升级测试框架或更换测试适配器，否则难以区分是哪项改动改变结果。

工作目录也会影响测试行为

查看当前目录下是否有 global.json，以及从仓库根到测试目录之间是否存在另一份 SDK 选择文件。切换目录可能改变 SDK 解析环境，必须确认实际仍使用准备验证的工具链，而不是偶然切回另一版。

测试若使用相对文件路径、读取外部资源或依赖当前目录，也需按项目原约定检查。进入项目目录是这条故障的绕行，不是宣称任意测试都可安全改变工作目录。

重新运行时确认错误不再包含重复目录，项目确实被加载，测试数量与筛选条件符合预期。命令不再报“项目文件不存在”只说明越过了加载阶段；零测试或测试初始化失败仍需单独处理。

暂时必须保留 RC 工具链时，可把这个入口调整限定在受影响作业中。后续更换 SDK，仍需使用原来的目录参数入口回归，确认路径处理和测试结果。