不严重。我从来没有在桌面开发中遇到过问题，除非，正如Martin所说，你在一个愚蠢的位置使用它。我听说很多人对它在桌面开发中的表现有完全不合理的担忧。

然而，在紧凑框架(我经常参与)中，它几乎是一种诅咒，在大多数情况下应该像瘟疫一样避免。我仍然可以不经常使用它，但我必须非常小心地使用它，这就不那么有趣了。：(

反射不会大幅降低应用程序的性能。不使用反射可能会更快地完成某些事情，但如果反射是实现某些功能的最简单方法，那么就使用它。如果反射成为一个性能问题，你总是可以重构你的代码。

您甚至不得不担心. net库内部为性能关键型代码所做的反射，这已经够糟糕的了。

下面的例子在当时(2008年)是过时的，但在最近的CLR版本中早就修复了。不过，总的来说，反思仍然是一件有点昂贵的事情!

举个例子:在高性能代码中，永远不要在lock (c#) / SyncLock (VB.NET)语句中使用声明为“Object”的成员。为什么?因为CLR不能锁定值类型，这意味着它必须执行运行时反射类型检查，以查看您的对象是否实际上是值类型而不是引用类型。

我想你会发现答案是，这要看情况。如果您想把它放在任务列表应用程序中，这不是什么大问题。如果你想把它放在Facebook的持久性库中，这是一件大事。

如果你不是在循环中，也不用担心。

As with all things in programming you have to balance performance cost with with any benefit gained. Reflection is an invaluable tool when used with care. I created a O/R mapping library in C# which used reflection to do the bindings. This worked fantastically well. Most of the reflection code was only executed once, so any performance hit was quite small, but the benefits were great. If I were writing a new fandangled sorting algorithm, I would probably not use reflection, since it would probably scale poorly.

很抱歉，我还没有完全回答你的问题。我的观点是，这并不重要。在适当的地方使用反射。它只是你需要学习如何以及何时使用的另一种语言功能。