“文件风格迁移”在c#中实为按.editorconfig配置格式化代码并人工对齐命名：dotnet-format可统一缩进、语法偏好等机械风格，但不改标识符名称；命名需手动或ast脚本处理，且须确保.editorconfig作用域正确、sdk版本兼容。
什么是“文件风格迁移”在 C# 语境下
它不是编译器或 ide 自带的功能，也不是 .NET SDK 提供的 API。所谓“把一个 C# 文件的写作风格迁移到另一个”，实际是指：统一代码格式（缩进、空格、换行）、命名习惯（camelCase vs PascalCase）、语法偏好（var 使用、表达式体成员、using 声明位置）等主观风格项。这些没有标准定义，全靠人约定或工具约束。
用 dotnet-format 统一基础格式最可靠
这是微软官方维护的 CLI 工具，能基于项目配置（.editorconfig）批量重写文件结构，覆盖 90% 的机械性风格问题。
- 必须先在项目根目录放一个有效的
.editorconfig，否则dotnet-format只按默认规则跑，和你的“源文件风格”无关 - 运行命令：
dotnet format --include Program.cs --include OtherFile.cs，指定要“被迁移”的目标文件 - 如果源文件里用了
async void、dynamic或自定义命名（如m_field），dotnet-format不会模仿——它只响应配置项，不分析语义 - 注意版本：
dotnet-format8+ 支持.NET 8新语法；旧项目用 7.x 版本更稳
命名风格不能靠格式化工具自动“学”出来
dotnet-format 和 visual studio 的“重新格式化文档”都**不改变量名、方法名、类名**。比如源文件用 GetUserInfoAsync，目标文件写了 get_user_info，工具不会把它改成 PascalCase。
- 真要对齐命名，得手动查替换，或写脚本解析 AST（例如用
microsoft.CodeAnalysis库遍历SyntaxTree，匹配标识符节点再重写） - 轻量替代：用 Rider 的
Refactor → Rename批量改一个命名模式，但需人工确认上下文是否安全 - 容易踩坑：盲目全局替换
int→var可能导致类型推导错误，尤其在var x = M();中M()返回Object时
别忽略 IDE 缓存和 editorconfig 作用域
Visual Studio 和 VS Code 的 C# 插件常缓存格式规则，改了 .editorconfig 后可能不立即生效。
- VS 中必须关闭再重开解决方案，或执行
Tools → Options → Text Editor → C# → Code Style → General → Reset all settings -
.editorconfig的规则只对它所在目录及子目录生效；若目标文件在src/legacy/，而配置在src/上层，它就“看不见” - 检查是否被
global.json锁定 SDK 版本——低版本 SDK 可能无视新版.editorconfig语法（如csharp_style_prefer_switch_expression）
C# 没有“风格迁移”这个操作概念，只有“按配置格式化”和“人工对齐命名”。真正难的是让团队在 .editorconfig 里写清楚每条规则的意图，而不是靠某个人的某个文件当模板。