C#中部分操作为何用Get前缀方法而非属性Getter？

这问题问得特别戳中反射API设计的核心逻辑，咱们从几个角度拆解清楚：

• 语义匹配度：Type类本身是运行时类型信息的载体，咱们调用GetType().GetProperties()的目的是主动查询该类型所暴露的属性元数据，这是一个“获取动作”；而如果做成Type.Properties属性，语义会变成“Type这个类自己的Properties成员”，和我们实际要访问的目标类型属性集合完全不是一回事，方法名的语义更精准。

• 灵活性需求：反射经常需要筛选不同范围的属性——比如要获取私有实例属性、静态公共属性，这时候GetProperties()可以接收BindingFlags参数（比如GetProperties(BindingFlags.NonPublic | BindingFlags.Instance)），实现精准过滤。但C#的属性是不能带参数的，如果用属性的话，要么得新增一堆诸如PublicInstanceProperties、PrivateStaticProperties这类细分属性，要么没法满足灵活筛选的需求，显然方法形式更合适。

• 性能提示作用：反射操作本身是有开销的，需要遍历程序集的元数据。用GetProperties()这种方法名，能直观提醒开发者“这是一个需要计算的操作，不是直接拿现成值”；如果做成属性，按照C#开发者的常规认知，会默认这是轻量、即时的状态访问，容易忽略反射的性能成本，甚至滥用。

• API设计一致性：整个.NET反射体系的风格都是用GetXxx()命名的方法，比如GetMethods()、GetFields()、GetConstructors()，保持统一的命名规则能降低开发者的学习成本，不用去记忆哪些信息用属性拿、哪些用方法拿。

简单总结：普通属性是用来访问对象自身的状态数据，而反射的GetProperties()是用来查询类型的元数据信息，两者的定位和场景完全不同，所以用方法而非属性才是更合理的设计。

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