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

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

我最相关的经验是编写代码来比较大型对象模型中相同类型的任何两个数据实体的属性。把它修好，试了试，显然跑得像条狗。

我很沮丧，然后在一夜之间意识到，在不改变逻辑的情况下，我可以使用相同的算法自动生成方法来进行比较，但静态地访问属性。为了这个目的调整代码完全不花时间，而且我有能力对实体与静态代码进行深入的属性比较，每当对象模型发生变化时，只要单击按钮就可以更新静态代码。

我的观点是:在与同事的对话中，因为我已经多次指出他们使用反射可以自动生成代码来编译，而不是执行运行时操作，这通常值得考虑。

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

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

和所有事情一样，这都是关于评估形势。在DotNetNuke中，有一个相当核心的组件叫做FillObject，它使用反射从数据箭头填充对象。

这是一个相当常见的场景，在MSDN上有一篇文章，使用反射将业务对象绑定到ASP。NET表单控件，涵盖了性能问题。

除了性能之外，我不喜欢在这种特定情况下使用反射的一件事是，它往往会降低快速理解代码的能力，对我来说，当你考虑到与强类型数据集或类似LINQ to SQL的数据集相比，你还失去了编译时的安全性，这似乎不值得付出努力。

它是。但这取决于你要做什么。

我使用反射动态加载程序集(插件)，它的性能“惩罚”不是问题，因为操作是我在应用程序启动期间所做的事情。

然而，如果你在一系列嵌套循环中反射，每个循环都有反射调用，我想说你应该重新审视你的代码:)

对于“几次”操作，反射是完全可以接受的，您不会注意到任何延迟或问题。它是一种非常强大的机制，甚至被。net使用，所以我不明白为什么你不应该尝试一下。