我在中使用反射API，如GetType（）和GetTypes（）。NET/C#。
- 就性能而言，这些API的好坏如何？我的意思是，这些API是否花费了很多时间，可能会导致性能下降，或者这些API是否设计得很好，可以忽略性能问题
- 通常情况下，人们在使用反射API时会缓存结果吗
我们不知道"好"one_answers"坏"对您意味着什么。
我们不知道您是否在关键性能代码中使用这些代码，这可能会成为应用程序的瓶颈。
只有您知道在使用Object.GetType和Assembly.GetTypes时代码将采用的确切路径。
因此，只有您才能准确地描述这些方法的使用对应用程序性能的意义，以及尝试通过缓存提高性能的好处。
我可以告诉你：我从未让Type.GetType和Assembly.GetTypes成为我的应用程序中的瓶颈，我也不缓存结果（然而，我需要缓存MemberInfo.GetCustomAttributes，但我是在一个探查器告诉我这是我的应用软件中的一个重要瓶颈，缓存将大大提高性能后才得出这个结论的）。
回复您的编辑：
我的意思是，这些API是否花费了很多时间，可能会导致性能下降，或者这些API是否设计得很好，可以忽略性能问题？
你有什么选择？如果您需要对给定对象的Type的引用，或者您需要给定程序集中的所有类型，我向您保证Object.GetType和Assembly.GetTypes是您的最佳选择。问题是，你是如何使用它们的？同样，我们不知道，因此无法告诉您该怎么做。您必须了解这些功能在现实世界中的使用情况，并查明它们是否会导致应用程序出现瓶颈。
他们都表现得非常好，也表现得非常差。这完全取决于你的观点和比较。
反射API服务于一个目的，在这些API的大多数使用中，它们不会造成瓶颈。使用它们。
如果在大量使用它们之后，它们确实产生了通过分析显示的瓶颈，那么可以选择提高性能。您可以自己实现缓存，也可以使用运行时或编译时代码生成。
大多数ORM使用反射来填充实体对象，由于这是在非常高的容量中重复进行的事情，因此可能会成为性能瓶颈。一些较新的微表单使用运行时生成的类，这些类可以在没有反射的情况下构建实体（使用reflection.Emit）。在我们的项目中，我们使用编译时生成的类来为每个实体创建生成器。编译时生成更容易，如果它适用于您的情况，则具有最佳性能。