之间是否存在任何差异（例如性能方面）
<cfif not x EQ y>
和
<cfif x NEQ y>？
答案 0 :(得分：11)
如果有任何差异，我怀疑你会注意到它，除非你运行了很多次，或者除非x和y在某种程度上是处理器密集型的。自从MX 7以来，我从来没有看到这被标记为Coldfusion可能出现的性能问题。
我建议使用最易读的格式。通过使代码难以阅读而将错误添加到代码中将比这两种格式的性能差异更具影响力。
就个人而言，我更喜欢看NEQ版本，因为它读得更好，在CF中更常见。
<cfif x NEQ y>
在我的脑海中写道：“如果x不等于y ......”，而......
<cfif NOT x EQ y>
读取“如果不是x等于y ......”在英语中没有意义。
答案 1 :(得分：2)
如果你真的担心这些情况下的性能，那么你可以使用Compare或CompareNoCase来表现更高的EQ效果。
但请记住，这些建议是从5年前开始的，并且没有更多证据证明此页面是真的。
答案 2 :(得分：1)
这实际上取决于：使用的ColdFusion版本和数据类型。在某些情况下，当您知道要比较这些特定数据类型时，最好使用特定的比较运算符。
几年前，在一篇早已不复存在的ColdFusion开发者杂志上发表了一篇文章，测量了各种运营商在这些情景中的表现（也使用了Terry指出的一些功能）。如果我没记错，那就是CF 6或6.1，并且表现出非常显着的性能差异。但是请记住，他们已经通过在大量迭代中包含操作符来测试它，以便首先获得一些可测量的数据。
答案 3 :(得分：0)
正如Sorensen所说，很少或根本没有可辨别的性能差异。从逻辑上思考这个问题，我们可以确定一些小事情。在一种情况下，您要求比较器检查是否相等，那么您正在否定结果。在另一种情况下，您要求比较器检查不等式。从逻辑上讲，只是执行不平等就是更少的步骤。但是，我们的好朋友热点编译器可能会在后台为我们改变它们，使两个语句都相同。
答案 4 :(得分：0)
NOT运算符是一个布尔运算符，而neq是一个布尔比较器。 not x eq y在逻辑上等同于x neq y，读起来更好。但是，当它变得更复杂not (x eq y or a eq b)时，基于上下文可能比x neq y and a neq b更容易理解，更不用说当你开始进入逻辑比较器（not (x eq y or a gt b)）时