C#开发EVE Online应用：从类型提取API路径的最优方案

针对你开发EVE Online应用时遇到的泛型API请求问题，我们来逐一分析三种实现的执行效率，以及各自的优缺点：

1. 字典映射方案：执行效率最高 #

毫无疑问，字典映射是三者里执行效率最高的。字典的Type到string的查找是基于哈希表的O(1)操作，几乎没有额外性能开销——每次调用Get<T>时，只是简单地从字典中取出对应的API路径，直接传入Send<T>方法即可。

如果是多线程环境，还可以改用ConcurrentDictionary来保证线程安全，性能损耗也微乎其微。不过要注意，这个方案需要你手动维护字典的映射关系，新增DTO类型时别忘了同步更新字典，否则会抛出KeyNotFoundException。

2. 实例化方案：效率次之，维护性较好 #

实例化方案的效率比字典映射稍低，因为每次调用Get<T>都需要通过new T()创建一个DTO实例。如果你的DTO都是简单的数据传输对象（没有复杂的构造逻辑），这个对象创建的开销其实非常小，在大多数场景下可以忽略不计。

但从性能角度看，它毕竟多了对象实例化、GC回收的潜在成本，高频调用下会比字典映射慢一点。不过这个方案的优势在于维护性更好：每个DTO自己实现Path()方法，符合单一职责原则，新增类型时只需要在类里写路径，不需要额外维护外部字典。

3. 反射方案：效率最低，不推荐高频场景 #

反射方案的执行效率是三者里最差的。调用typeof(T).GetMethod("Path").Invoke(null,null)时，CLR需要做类型成员查找、方法绑定、权限检查等一系列操作，这些步骤的开销远高于直接调用方法或者字典查找。如果Get<T>被频繁调用，反射的性能损耗会被放大，甚至成为性能瓶颈。

虽然这个方案不需要手动维护映射关系，但反射的代码可读性差，调试也更麻烦，除非是极端特殊的场景，否则不推荐在高频调用的API请求逻辑里使用。

总结 #

如果你的核心诉求是最高执行效率，优先选择字典映射方案；如果更看重代码的可维护性、不想手动维护外部映射，且API调用频率不是极高，那么实例化方案是不错的折中选择；反射方案只建议在调用频率极低、或者动态性要求极高的场景下考虑。

内容的提问来源于stack exchange，提问作者禅グル