dotnet format 验证通过仍报 IDE0055：检查其他目标框架的条件代码

dotnet format whitespace --verify-no-changes 退出成功，构建却在另一个目标框架下继续报 IDE0055: Fix formatting。若项目声明多个 TargetFrameworks，且违规代码位于 #if NET10_0_OR_GREATER 等条件分支，应检查格式化实际加载了哪个框架。

SDK 10.0.401 的具体问题中，net8.0;net10.0 的空白格式化只处理首个框架能看到的代码。交换框架顺序会改变遗漏分支。验证模式只检查这次加载到的代码，并不能证明所有目标框架下的条件代码都符合格式要求。

按单个目标框架加载项目

对同时支持这些框架的单个项目，可以给每次格式化进程设置 TargetFramework 环境变量，让 MSBuild 按对应的内部构建加载。Unix shell 示例：

TargetFramework=net8.0 dotnet format whitespace Example.csproj
TargetFramework=net10.0 dotnet format whitespace Example.csproj

Example.csproj 是项目路径占位值，框架也必须来自该项目真实的目标列表。命令会改写源码，执行前保留版本控制差异，并审查修改内容。这里采用针对 SDK 10.0.401 的环境变量绕行。.NET 11 文档已列出内建 --framework；采用时仍需依实际 SDK 帮助与项目结构评估，不能将该入口的支持情况套用于所有版本。

Windows 终端的环境变量写法不同，应保存原值，在调用完成后恢复，避免后续构建意外继续只使用一个框架。不要直接对整个解决方案强设某个框架：引用项目可能根本不支持它，需按项目依赖关系选择范围。

验证既要格式检查，也要构建检查

逐框架运行相同的 --verify-no-changes 检查，再构建项目实际支持的全部框架。构建侧需要项目启用了相应代码风格检查，例如 EnforceCodeStyleInBuild 与 IDE0055 的有效严重级别；未启用时没有警告，不能反证格式已经正确。

dotnet format style --diagnostics IDE0055 --severity warn 在小型场景可能触及另一分支，但多目标链接文件还存在合并冲突的边界。不要为了少跑一次命令就对大型工程盲目改用这条路径；若使用，必须检查源码是否出现冲突标记以及其他意外改动。

验收时明确列出各框架条件分支中应被处理的代码，并检查实际差异。只移动 TargetFrameworks 顺序，会换一个被遗漏的分支，不是完整解决。需要撤回时恢复本次格式化产生的受控差异，保留其他人的源码修改。