用途：当 MSBuild 的 Target Performance Summary 中 ResolveProjectReferences 显示为最昂贵目标时，本指南帮助判断该指标是否具有误导性，避免直接优化它。
何时使用：ResolveProjectReferences 出现在目标性能摘要的最贵目标；有人试图直接优化它；构建分析显示单个目标占用总构建时间 50% 至 80%。
何时不用：一般构建性能优化应改用 build-perf-diagnostics；瓶颈明显是其他目标（如 Csc、ResolveAssemblyReference）；尚未捕获 binlog 或性能摘要。
输入：需要包含 Target Performance Summary 的诊断构建日志或 binlog。
工作流：第一步确认该误导症状，即它是否为目标性能摘要的首位目标；第二步解释其耗时包含等待依赖项目构建时让出 MSBuild 节点的墙钟时间（参考 dotnet/msbuild#3135），等待期间节点可能在做其他项目的有用工作，该目标本身工作量很小；第三步转向任务自耗时，通过 Task Performance Summary 找真正瓶颈，优先用 binlog MCP 的 expensive_tasks 工具直接获取任务自耗时排名。MCP 不可用时回退到文本日志重放：dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log;performancesummary"，然后 grep "Task Performance Summary" -A 50 full.log。关注实际任务自耗时，如 Csc、ResolveAssemblyReference、Copy，序列化瓶颈可参考 build-parallelism。
验证：使用 Task Performance Summary 而非 Target Performance Summary；未将 ResolveProjectReferences 设为优化目标；确认真实瓶颈为具体任务。限制：仅适用于 MSBuild 构建性能分析，需已有日志或 binlog，未提供安装或收费信息。