为什么要使用指令删除不必要的C＃？
例如，我很少需要：
using System.Text;
但默认情况下它始终存在。我假设如果代码包含不必要的using指令，则应用程序将使用更多的内存。但是我还有什么要注意的吗？
另外，如果仅在一个文件中对大多数文件/所有文件使用相同的using指令，是否有任何区别？
编辑：请注意，此问题与称为using语句的无关概念无关，该语句旨在确保一个对象超出范围时可以调用其IDisposable.Dispose方法来帮助管理资源。请参见C＃中"使用"的用法。
解决方案
当程序运行时，它不会改变任何东西。所需的所有内容均按需加载。因此，即使我们具有using语句，除非我们实际上在该名称空间/程序集中使用了类型，否则将不会加载using语句所关联的程序集。
主要是为了个人喜好进行清理。
应用程序将不使用更多的内存。它供编译器查找我们在代码文件中使用的类。除了不干净外，它真的没有任何伤害。
" using"语句不会影响性能，因为它只是限定标识符名称的辅助工具。因此，如果我们必须使用System.IO，则不必键入System.IO.Path.Combine(...)，而只需键入Path.Combine(...)。
不要忘记，在构建项目时，编译器会做很多工作来优化所有内容。使用它在很多地方使用或者一旦编译就不应做其他事情。
其个人喜好为主。我自己清理它们(Resharper很好地告诉我什么时候不需要使用语句)。
可以说这可能会减少编译时间，但是由于计算机和编译器的速度越来越快，它不会产生任何明显的影响。
它们只是用作快捷方式。例如，我们必须编写：
每次使用System.Int32(如果我们没有使用System的话)；在上面。
删除未使用的代码只会使代码看起来更干净。
没有与" using"相对应的IL构造。因此，" using"语句不会增加应用程序内存，因为没有为其生成任何代码或者数据。
"使用"仅在编译时用于将短类型名称解析为标准类型名称的目的。因此，不必要的"使用"可能带来的唯一负面影响是稍微降低了编译时间，并在编译过程中占用了更多的内存。我不会担心的。
因此，不需要的" using"语句唯一真正的负面影响是对智能感知，因为键入时需要完成的潜在匹配项列表会增加。
如果像命名空间中的(未使用的)类那样调用类，则名称可能会冲突。对于System.Text，如果定义一个名为" Encoder"的类，则会遇到问题。
无论如何，这通常是一个小问题，并且由编译器检测到。
留下额外的" using"指令就可以了。删除它们有一点价值，但没有太大价值。例如，它使我的IntelliSense完成列表更短，因此更易于浏览。
编译的程序集不受无关的using指令的影响。
有时，我将它们放在" #region"中，然后将其折叠起来；这使得查看文件更加整洁。 IMO，这是#region的少数几种很好的用法之一。
using语句仅使我们无法限定使用的类型。我个人喜欢清理它们。真的取决于位置指标的使用方式
代码清洁度很重要。
当人们看到多余的用法时，人们开始感到代码可能无法维护，并且会出现在眉毛上。本质上，当我看到一些未使用的using语句时，我的大脑后面会升起一个黄色的小旗，告诉我"谨慎行事"。阅读生产代码绝对不会给我们那种感觉。
因此，清理用法。不要马虎。激发信心。使代码漂亮。给另一个开发人员一种温暖的感觉。
除了编码首选项外，还有几个原因可以删除未使用的使用/命名空间：
- 删除项目中未使用的using子句，可以使编译速度更快，因为编译器具有较少的名称空间来查找要解析的类型。 (由于扩展方法，对于C＃3.0尤其如此，编译器必须在所有命名空间中搜索扩展方法以寻找可能的更好匹配，泛型类型推断和涉及泛型类型的lambda表达式)
- 当将新类型添加到未使用的命名空间中且名称与使用的命名空间中的某些类型相同时，可以潜在地避免将来版本中的名称冲突。
- 会减少编码时编辑器自动完成列表中的项目数量，有可能导致更快的键入速度(在C＃3.0中，这也可以减少所示的扩展方法列表)
删除未使用的名称空间将无法执行以下操作：
- 以任何方式更改编译器的输出。
- 以任何方式改变编译程序的执行(更快的加载或者更好的性能)。
删除或者不删除未使用的组件时，所得的组件相同。
