为什么在frebug中Nodejs代码能够显示出来，但是源码中不显示呢？

为什么在frebug中Nodejs代码能够显示出来，但是源码中不显示呢？

如图： QQ图片20141101162705.png

有没有办法获得他们的value呢？ 请大神指点下。谢谢

3 回复

在调试Node.js应用时，经常会遇到一种情况：在调试器（如node inspect或IDE中的内置调试工具）中可以查看到变量的值，但在实际的源码文件中却看不到这些值。这种情况通常是由几个原因造成的：

原因分析

  1. 作用域问题：在某些情况下，你可能试图访问一个在当前作用域中不可见的变量。
  2. 编译/压缩问题：如果你使用了诸如Webpack、Babel等工具进行代码编译或压缩，那么在最终生成的代码中，变量名可能会被混淆或删除。
  3. 调试配置问题：你的调试器配置可能没有正确地映射源码文件。

示例代码

假设我们有以下简单的Node.js应用：

// app.js
const myVar = "Hello, World!";
console.log(myVar);

function testFunction() {
    const innerVar = "This is an inner variable.";
    console.log(innerVar);
}

testFunction();

如果我们直接运行这段代码（例如通过node app.js），在控制台中只能看到输出结果，而无法直接查看myVar和innerVar的值。

调试模式下的查看

当使用调试器时，你可以更方便地查看变量值。例如，使用Node.js的内置调试器node inspect：

$ node inspect app.js
< Debugger listening on ws://127.0.0.1:9229/9c7e6d4a-9b0d-42f5-a904-9e51f9a9224f
< For help, see: https://nodejs.org/en/docs/inspector
Break on start in app.js:1
> 1 (function (exports, require, module, __filename, __dirname) { const myVar = "Hello, World!";
  2 console.log(myVar);
  3 
debug> cont
< Hello, World!
break in [eval] at evalmachine.<anonymous>:1
   1 (function (exports, require, module, __filename, __dirname) { const innerVar = "This is an inner variable.";
   2 console.log(innerVar);
   3 });

debug> print innerVar
this.innerVar = 'This is an inner variable.'

解决方法

  1. 检查作用域：确保你在正确的上下文中查看变量。
  2. 检查编译配置：如果使用了代码压缩或混淆工具，确保它们不会影响调试体验。
  3. 调试器配置：确保你的调试器配置正确，并且能够映射到源码文件。

通过以上方法，你应该能够在调试过程中更好地查看和理解变量值。


好新手的问题。。。

说下吧，这样的代码是JS动态创建的。

根据你提供的描述和问题背景，我猜测这可能是因为代码经过了压缩或混淆处理，导致在源码文件中无法直接看到原始代码，但在调试器（如frebug）中可以正常查看。

为了更好地说明这个问题，假设我们有一段简单的JavaScript代码，这段代码在未经压缩的情况下，其结构是清晰的：

// 原始代码
function add(a, b) {
    return a + b;
}
console.log(add(1, 2));

然而，当我们使用一些工具（例如terser或uglify-js）对这段代码进行压缩时，它可能会变成以下形式：

// 压缩后的代码
!function(e){function t(r){if(n[r])return n[r].exports;var o=n[r]={i:r,l:!1,exports:{}};return e[r].call(o.exports,o,o.exports,t),o.l=!0,o.exports}var n={};t.m=e,t.c=n,t.d=function(e,t,n){t in n||Object.defineProperty(n,t,{enumerable:!0,get:n})},t.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},t.t=function(e,n){if(1&t(n)){if("string"==typeof e)return e;var r=Object.create(null);t.r(r);var o=Object.defineProperty(r,"default",{enumerable:!0,value:e});return o.t=n,r}return"6"&n?e:t.o(e,n)?e:new Proxy(e,{get:function(e,r){return t.t(t.d(e,r,e[r]),n)}})},t.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return t.t=6,t},t.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},t.p="",t(t.s=1)}([function(e,t){function n(e,t){return e+t}console.log(n(1,2))},]);

在上述压缩后的代码中，原始的函数定义和调用已经被转换成了难以阅读的形式，因此在普通的源码查看器中不容易找到具体的代码逻辑。然而，在调试器中，这些变量和函数名会被还原成它们的原始名称，使得开发人员能够更容易地进行调试。

解决方法：

  • 确保在生产环境中不要使用未压缩的源代码。
  • 在需要调试的时候，可以使用专门的调试版本或者对生产代码进行反向工程来获取可读性更好的代码。
  • 如果你的目标是在客户端上进行调试，那么考虑将开发环境中的源代码也保持为未压缩状态，并确保部署到生产环境之前进行正确的压缩处理。
回到顶部