StyleCop 是什么，它和 Roslyn 分析器有什么区别
StyleCop 不是编译器插件，而是一套独立的静态分析工具，早期基于 MSBuild 任务运行，现在主流用法是通过
StyleCop.AnalyzersNuGet 包接入 Roslyn 编译管道。这意味着它能在 IDE 实时提示、CI 构建阶段报错，但它的规则粒度比编译器警告更细（比如要求 XML 注释必须存在、方法参数命名必须用
camelCase），且不参与语义检查。
关键区别在于：Roslyn 自带的
CSharpCompiler负责语法/语义正确性；
StyleCop.Analyzers只管“写法是否符合风格约定”，哪怕代码能跑通，它也能标红。
如何在项目中启用 StyleCop 并让违规变成编译错误
默认安装
StyleCop.Analyzers后，违规只是 Warning 级别，不会中断构建。要强制执行，必须显式升级严重性。 在项目文件（
.csproj）中添加
<analysismode>AllEnabledByDefault</analysismode>或手动配置规则集 推荐方式：添加
stylecop.json配置文件到项目根目录，并确保其
Build Action设为
AdditionalFiles在
stylecop.json中设置
"severity": "error"对应具体规则，例如：
{
"$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json",
"rules": {
"SA1600": {
"severity": "error"
}
}
}
若使用旧版 .ruleset 文件，需在项目文件中显式引用：<codeanalysisruleset>StyleCop.ruleset</codeanalysisruleset>
常见误配导致规则不生效的几个坑
很多团队配完发现没反应，大概率卡在这几个点上：
stylecop.json文件未设为
AdditionalFiles—— 在解决方案资源管理器中右键该文件 → 属性 → “生成操作” 必须选此项 项目 SDK 类型不兼容：.NET Core 3.0+ / .NET 5+ 项目需用
StyleCop.Analyzers1.2.0-beta.419 或更高版本；老式
packages.config项目可能需额外加
<restoreprojectstyle>PackageReference</restoreprojectstyle>VS 缓存未刷新：关闭 VS → 删除
obj/和
bin/目录 → 重启 VS 再加载项目 规则名拼写错误或大小写不符，例如写成
sa1600（应为
SA1600）
CI 环境下如何确保所有提交都过 StyleCop 检查
本地有效不等于 CI 有效。Azure DevOps / GitHub Actions 默认不加载 IDE 特定分析器上下文，需显式启用：
确保构建命令包含/p:AnalysisMode=AllEnabledByDefault参数，例如：
dotnet build /p:AnalysisMode=AllEnabledByDefault若用
stylecop.json，确认它被签入仓库且路径在项目目录下（MSBuild 会自动识别同级
stylecop.json） 避免在 CI 中使用
dotnet restore --no-cache后遗漏
dotnet build的分析器加载步骤 ——
restore不触发分析器注册，只有
build才真正加载 GitHub Actions 示例片段：
dotnet build --configuration Release /p:AnalysisMode=AllEnabledByDefault
最常被忽略的是：开发者本地开了实时分析，但 CI 用的是最小化构建参数，结果规则形同虚设。强制统一构建参数才是落地关键。
