Visual Studio 对 .NET 项目代码维护依赖可配置、可触发、可集成生成流程的机制：启用 CA1502 等分析器检测圈复杂度（需在 .editorconfig 中设 severity 并用 CodeMetricsConfig.txt 配阈值且标记为 AdditionalFiles），使用 Ctrl+. 调用安全重构（如删死代码、加 null 检查），并通过 .editorconfig 统一命名格式规则以确保团队与 CI 一致生效。
Visual Studio 对 .NET 项目的代码维护不是靠“手动修修补补”，而是有一套可配置、可触发、可集成到生成流程中的机制。核心方法就三条：用代码分析器自动发现问题、用重构工具安全调整结构、用 EditorConfig 统一风格并强制执行。
启用 CA1502 等代码指标规则来识别高复杂度方法
CA1502 是最常被启用的可维护性规则之一，它检测方法的圈复杂度（cyclomatic complexity）。默认不触发，必须显式启用并配阈值，否则等于没开。
- 在
.editorconfig中添加：dotnet_diagnostic.CA1502.severity = warning - 单独配置阈值需新建文本文件（如
CodeMetricsConfig.txt），内容为：CA1502: 10，表示圈复杂度超过 10 就报警告 - 该文件必须标记为
AdditionalFiles，即在项目文件中加入：<AdditionalFiles Include="CodeMetricsConfig.txt" /> - 仅靠 IDE 界面启用（比如在解决方案资源管理器里右键规则）不会影响命令行构建或 CI 流程，必须靠配置文件
用 Ctrl+. 快速调用“删除无法访问的代码”和“为所有参数添加 null 检查”
这类重构不是锦上添花的功能，而是能直接消除运行时隐患的实操手段。它们只作用于当前光标所在上下文，不跨文件、不猜意图，所以安全可控。
Visual Studio Professional 18.8.1
下载
Visual Studio 18.8.1 官方固定版本安装引导程序，当前条目使用微软发布历史中的 Professional Web Installer，适合旧项目兼容、环境回退、复现特定构建链和排查版本差异等场景。
- “删除无法访问的代码”会识别
throw后的死代码、return后的语句块，但不会动#if DEBUG这类预处理器分支里的内容 - “为所有参数添加 null 检查”只对可为 null 的引用类型参数生成
if (param is null) throw ...，值类型参数（如int）不会处理 - 这两项重构在 SDK 风格项目中效果最稳定；老式
.csproj（含<TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>）可能部分失效 - 重构后务必检查是否引入了新警告，比如未使用的局部变量 —— 它们常被编译器标记为
CS0219，但不会自动删除
通过 .editorconfig 强制统一命名和格式，而非依赖个人设置
团队协作中最容易被忽略的一点是：你在“工具 > 选项”里调好的 C# 格式设置，只对你本机有效。别人拉代码、CI 跑构建、PR 检查，全都不认这个。
- 必须把规则写进项目根目录的
.editorconfig，例如：csharp_style_var_for_built_in_types = true:suggestion - 严重性级别要用
suggestion/warning/error，而不是旧版的refactoring或silent，后者在 .NET 8+ 已不生效 - 命名规则（如接口必须以
I开头）需配合dotnet_naming_rule块定义，单写dotnet_naming_symbols不会起作用 - VS Code 用户必须装好
EditorConfig for VS Code插件，否则编辑器根本读不到这些规则
真正难的不是知道有这些功能，而是让它们在每次保存、每次生成、每次 PR 提交时都稳定触发 —— 这取决于配置文件是否在正确路径、是否被正确加载、是否与目标框架版本兼容。漏掉任意一个环节，维护动作就只停留在“看起来很美”的阶段。
