为啥 + 仅在客户端是 NaN？为啥不在 Node.js 中？

Posted 2023-03-07

【中文标题】为啥 + 仅在客户端是 NaN？为啥不在 Node.js 中？

【英文标题】：Why + is NaN only on the client side? Why not in Node.js?为什么 + 仅在客户端是 NaN？为什么不在 Node.js 中？

【发布时间】：2013-06-20 13:06:35

【问题描述】：

虽然[] + [] 是一个空字符串，但[] + 是"[object Object]"，而 + [] 是0。为什么 + NaN？

>  + 
  NaN

我的问题不是为什么( + ).toString() 是"[object Object][object Object]" 而NaN.toString() 是"NaN"、this part has an answer here already。

我的问题是为什么这只发生在客户端？在服务器端（Node.js） + 是"[object Object][object Object]"。

>  + 
'[object Object][object Object]'

---

总结：

在客户端：

 [] + []              // Returns ""
 [] +               // Returns "[object Object]"
  + []              // Returns 0
  +               // Returns NaN

 NaN.toString()       // Returns "NaN"
 ( + ).toString() // Returns "[object Object][object Object]"
 var a =  + ;     // 'a' will be "[object Object][object Object]"

在 Node.js 中：

 [] + []   // Returns "" (like on the client)
 [] +    // Returns "[object Object]" (like on the client)
  + []   // Returns "[object Object]" (not like on the client)
  +    // Returns "[object Object][object Object]" (not like on the client)

【问题讨论】：

这只是浏览器控制台。尝试将 记录到 控制台，这与在 NodeJS 中的相同。 jsbin.com/oveyuj/1/edit

不是真正的重复，我要求 NodeJS 回答。投票重新开放...

嗯...对不起。但是，***.com/questions/9032856/… 仍然相关并回答了前半部分

不要忘记 可以被解释为表达式或对象原语，具体取决于上下文。也许客户端和服务器上的代码相同，但由于输入代码的上下文不同，它对 的解释不同。

请重新打开，然后一次又一次地停止关闭这个问题，因为这个问题真的不是重复的。

【参考方案1】：

更新说明：this has been fixed in Chrome 49。

非常有趣的问题！让我们深入研究。

根本原因

区别的根源在于 Node.js 评估这些语句的方式与 Chrome 开发工具的方式。

Node.js 的作用

Node.js 为此使用 repl 模块。

来自 Node.js REPL source code：

self.eval(
    '(' + evalCmd + ')',
    self.context,
    'repl',
    function (e, ret) 
        if (e && !isSyntaxError(e))
            return finish(e);
        if (typeof ret === 'function' && /^[\r\n\s]*function/.test(evalCmd) || e) 
            // Now as statement without parens.
            self.eval(evalCmd, self.context, 'repl', finish);
        
        else 
            finish(null, ret);
        
    
);

这就像在 Chrome 开发者工具中运行 (+) 一样，它也会如您所期望的那样生成 "[object Object][object Object]"。

chrome 开发者工具的作用

另一方面Chrome dveloper tools does the following:

try 
    if (injectCommandLineAPI && inspectedWindow.console) 
        inspectedWindow.console._commandLineAPI = new CommandLineAPI(this._commandLineAPIImpl, isEvalOnCallFrame ? object : null);
        expression = "with ((window && window.console && window.console._commandLineAPI) || ) \n" + expression + "\n";
    
    var result = evalFunction.call(object, expression);
    if (objectGroup === "console")
        this._lastResult = result;
    return result;

finally 
    if (injectCommandLineAPI && inspectedWindow.console)
        delete inspectedWindow.console._commandLineAPI;

所以基本上，它对带有表达式的对象执行call。表达式为：

with ((window && window.console && window.console._commandLineAPI) || ) 
    +;// <-- This is your code

因此，如您所见，表达式是直接计算的，没有括号。

为什么 Node.js 的行为不同

Node.js 的源代码证明了这一点：

// This catches 'a : 1' properly.

节点并不总是这样。这里是the actual commit that changed it。 Ryan 对更改留下了以下评论：“改进 REPL 命令的评估方式”，并举例说明了不同之处。

---

犀牛

更新 - OP 对 Rhino 的行为方式很感兴趣（以及为什么它的行为方式类似于 Chrome devtools 而与 nodejs 不同）。

Rhino 使用完全不同的 JS 引擎，这与 Chrome 开发工具和 Node.js 的 REPL 都使用 V8 不同。

这是在 Rhino shell 中使用 Rhino 评估 javascript 命令时发生的基本管道。

shell 运行org.mozilla.javascript.tools.shell.main。

反过来，它会调用this new IProxy(IProxy.EVAL_INLINE_SCRIPT);，例如，如果代码直接使用内联开关 -e 传递。

这会命中 IProxy 的 run 方法。

它调用evalInlineScript (src)。这只是编译字符串并对其进行评估。

基本上：

Script script = cx.compileString(scriptText, "<command>", 1, null);
if (script != null) 
    script.exec(cx, getShellScope()); // <- just an eval

在这三个中，Rhino 的外壳是最接近实际 eval 的外壳，没有任何包装。 Rhino 最接近实际的 eval() 语句，您可以期望它的行为与 eval 完全一样。

【讨论】：

（不是答案的一部分，但值得一提的是，nodejs 在使用 REPL 时默认使用 vm module 进行评估，而不仅仅是 JavaScript eval）

你能解释一下为什么 rhino 会在终端（不仅仅是 Chrome 控制台）中做同样的事情吗？

+10 如果可能的话！哇，伙计，...你真的没有生命，或者你真的比我聪明，知道这样的事情。请告诉我，您搜索了一下才找到这个答案:)

@Samuel 只需要阅读源代码——我发誓！在 Chrome 中，如果您输入“调试器；” , 你得到了整个管道 - 它会将你 直接 扔到 'with' 上面只有一个函数到evaluateOn。在 node 中，一切都有很好的记录——他们有一个专用的 REPL 模块，在 git 上的所有历史都很好，很舒服，以前在我自己的程序中使用过 REPL，我知道去哪里看 :) 我很高兴你喜欢它并找到它很有帮助，但我应该归功于我对这些代码库（dev-tools 和 nodejs）的熟悉，而不是我的才智。直奔源头通常总是最容易的。

更新 - Chrome 中的控制台 API 已经更新了一些，所以虽然这里的总体思路是正确的，但发布的代码对于最新版本的 Chrome 并不准确。见chromium.googlesource.com/chromium/blink.git/+/master/Source/…