能否用Dictionary替代方法参数（类似Main方法args）？优劣及优化建议

从技术实现上你完全可以这么做，只要在字典里塞入对应键值对、方法内部按key取值后强转，代码确实能正常运行，但这种设计在绝大多数业务场景下都不合理，核心问题主要集中在这几点：

• 彻底丢失编译期的类型校验保护：不管是key名拼写错误、取出来的对象类型和实际预期不匹配，所有错误都只能等到运行时才会暴露。后续重构的时候只要改了字典里的key名，所有调用这个方法的位置都要逐个人工排查修改，漏改一处就可能引发线上故障。
• 方法签名完全丧失可读性：其他开发者看到AddOrUpdateRecord(Dictionary<string, object> args)的签名，根本没法快速知道这个方法需要哪些必传参数、参数是什么类型、有什么约束，必须钻进方法内部逐行看取值逻辑才能搞明白，长期维护成本极高。
• 没有强制的参数约束：你没法在编译阶段就要求调用方必须传齐必要参数，漏传key的问题只能在方法内部运行时判空才能发现，调试排查效率很低。
• 存在不必要的性能损耗：字典本身的内存分配开销、每次取值的哈希查找成本，相比直接传递强类型参数，在高频调用路径上是完全可以避免的额外消耗。

更优的实现方案 #

• 强类型参数对象封装：把方法需要的所有参数封装成专用的参数类，比如定义AddOrUpdateRecordRequest，明确标注每个字段的类型、含义和必选/可选规则，方法签名直接接收这个对象作为参数。这种方式既保留了“多个参数打包传递”的便利性，又能拿到全链路的编译校验支持，IDE还能自动补全、提示参数信息，是最通用的解决方案。
• 常规强类型参数+命名参数：如果方法参数数量不多，直接在方法签名上定义独立参数，对可选参数设置默认值，调用时配合命名参数传值，体验远好于无约束的字典传参，从根本上避免key拼写错误的问题。
• 动态逻辑封在系统边界层：如果真的遇到完全动态的传参场景（比如写通用反射框架、序列化中间件），也建议把动态字典的逻辑封在系统的入口/出口边界层，不要把无类型的Dictionary<string, object>直接透传到核心业务方法内部，避免无类型字典的问题污染业务代码。

回到你给出的示例代码，当前方法逻辑里实际只从字典中读取了record这一个键值对，这种场景下直接把RecordDto作为独立入参传递，比套一层无类型字典要清晰、可靠得多。

内容的提问来源于stack exchange，提问作者Tech with Thiru