在.NET Framework 4.8中用PolySharp实现C#8-11模式匹配是否可靠？

核心结论 #

PolySharp在VSTO场景下是相对靠谱的方案，但得留意几个关键限制和风险点，配置到位的话，不会搞出大面积不稳定的问题。

具体风险与规避方式 #

• 模式匹配的polyfill兼容性：PolySharp对C#8+模式匹配（比如switch表达式、属性模式、元组模式这些）的polyfill是编译时代码替换，不是运行时注入。说白了就是把高版本语法转译成.NET Framework 4.8能懂的C#7.3代码，不存在运行时缺API的问题，但要注意：

  • 像C#11的列表模式这类极新语法的polyfill，成熟度可能不如基础模式，建议先在测试项目跑通再拿到生产代码里用。
  • 别在性能敏感的VSTO代码路径（比如频繁触发的Office事件处理）里过度用复杂模式匹配——虽然polyfill是编译期完成的，但转译后的代码可能比手写条件判断啰嗦点，不过绝大多数场景下性能差异可以忽略。

• VSTO项目的编译特殊性：Visual Studio 2022对VSTO项目的编译逻辑和普通.NET Framework项目一样，只要正确装PolySharp的NuGet包，编译时会自动触发语法转译。要注意：

  • 必须把项目语言版本设为C#8+（右键项目→属性→生成→高级→语言版本），PolySharp靠这个识别要转译的语法。
  • 别手动改PolySharp生成的代码文件，这些是自动生成的，改了会导致编译冲突或者后续更新失效。

• Office对象模型的兼容性：VSTO代码大多依赖Office COM对象，用模式匹配时要注意：

  • 对COM对象做模式匹配（比如判断是不是Excel.Worksheet类型），PolySharp的polyfill和原生C#语法行为一致，不会出现类型识别错的情况，但要确保Office互操作程序集引用正确。
  • 别对dynamic类型用复杂模式匹配，虽然PolySharp支持，但dynamic在VSTO里本身就容易出异常，尽量用强类型。

验证步骤 #

1. 建个空白VSTO测试项目，装最新版的PolySharp NuGet包。
2. 写点带C#8+模式匹配的测试代码，比如：

// C#8 switch表达式示例
var cellType = obj switch
{
    Excel.Range r when r.Value2 is int => "数字单元格",
    Excel.Range r when r.Value2 is string => "文本单元格",
    _ => "未知类型"
};

// C#9 属性模式示例
var isNamedSheet = sheet switch
{
    { Name: "Sheet1" } => true,
    _ => false
};

3. 编译运行测试项目，检查和Office交互是否正常，有没有异常抛出。
4. 用ILSpy这类工具看编译后的IL代码，确认PolySharp转译后的逻辑符合预期。

总结 #

只要跟着官方配置指南来，PolySharp在VSTO项目里用C#8+模式匹配是安全的。唯一要警惕的就是极端场景下的语法兼容性和性能影响，但这些都能通过前期测试规避。

内容的提问来源于stack exchange，提问作者DotNET Afficionado