本文为中英文双语，需要英文博客可以滑动到下面查看哦 | This is a bilingual article. Scroll down for the English version.
小伙伴们！今天我在本地调试项目的过程中，想记录一下错误信息，结果程序就"啪"地一下报出 "Maximum call stack size exceeded" 错误，然后项目直接就crash了。但是我看我用的这个开源项目，官方的代码里好多地方就是这么用的呀？我很纳闷，这是为什么呢？
报错信息
[LOGGER PARSING ERROR] Maximum call stack size exceeded
2025-10-13T17:06:59.643Z debug: Error code: 400 - {'error': {'message': 'Budget has been exceeded! Current cost: 28.097367900000002, Max budget: 0.0', 'type': 'budget_exceeded', 'par... [truncated]
{
unknown: [object Object],
}
2025-10-13T17:06:59.643Z debug: [api/server/middleware/abortMiddleware.js] respondWithError called
2025-10-13T17:06:59.644Z error: There was an uncaught error: Cannot read properties of undefined (reading 'emit')
2025-10-13T17:06:59.645Z debug: [indexSync] Clearing sync timeouts before exiting...
[nodemon] app crashed - waiting for file changes before starting...
报错截图
错误分析
晚上下班以后，晚上躺在床上，我翻来覆去睡不着，干脆打开电脑一番探究，想要知道 ，这个错误到底为何触发，实质原因是什么，以及如何解决它。让我们一起把这个小调皮鬼揪出来看看它到底在搞什么鬼吧！👻
场景复现
想象一下这个场景，你正在开心地写着代码：
app.get('/api/data', async (req, res) => {
try {
// 一些可能会出小差错的业务逻辑
const data = await fetchDataFromAPI();
res.json(data);
} catch (error) {
// 记录错误信息
logger.debug('获取数据时出错啦～', error); // 哎呀！这一行可能会让我们的程序崩溃哦！
res.status(500).json({ error: '内部服务器出错啦～' });
}
});
看起来是不是很正常呢？但是当你运行这段代码的时候，突然就出现了这样的错误：
[LOGGER PARSING ERROR] Maximum call stack size exceeded
更神奇的是，如果你把代码改成这样：
console.log(error); // 这一行却不会让程序崩溃哦,但是上prod的系统，不要这么用哦
它就能正常工作啦！这是为什么呢？🤔
小秘密大揭秘！🔍
console.log虽好，但请勿用它来记录PROD错误！
console.log 是 Node.js 原生提供的函数，它就像一个经验超级丰富的大叔，知道怎么处理各种"调皮"的对象。当 console.log 遇到包含循环引用的对象时，它会聪明地检测这些循环引用，并用 [Circular] 标记来代替实际的循环部分，这样就不会无限递归啦！
简单来说，Node.js 的 console.log 就像一个超级厉害的武林高手，知道如何闪转腾挪，避开各种陷阱！🥋
日志库的"小烦恼"
但是我们自己封装的日志系统（比如项目中使用的 Winston）就不一样啦！为了实现各种炫酷的功能（比如格式化、过滤敏感信息等），日志库通常会使用一些第三方库来处理传入的对象。
在我们的案例中，日志系统使用了 [traverse] 库来遍历对象。这个库在大多数情况下工作得都很好，但当它遇到某些复杂的 Error 对象时，就可能会迷路啦！
Error 对象可不是普通对象那么简单哦！它们可能包含各种隐藏的属性、getter 方法，甚至在某些情况下会动态生成属性。当 [traverse] 库尝试遍历这些复杂结构时，就可能陷入无限递归的迷宫，最终导致调用栈溢出。
什么是循环引用？🌀
在深入了解这个问题之前，我们先来了解一下什么是循环引用。循环引用指的是对象之间相互引用，形成一个闭环。比如说：
const objA = { name: '小A' };
const objB = { name: '小B' };
objA.ref = objB;
objB.ref = objA; // 哎呀！形成循环引用啦！
当尝试序列化这样的对象时（比如用 JSON.stringify），就会出现问题，因为序列化过程会无限递归下去，就像两只小仓鼠在滚轮里永远跑不完一样！🐹
Error 对象虽然看起来简单，但内部结构可能非常复杂，特别是在一些框架或库中创建的 Error 对象，它们可能包含对 request、response 等对象的引用，而这些对象又可能包含对 Error 对象的引用，从而形成复杂的循环引用网络，就像一张大蜘蛛网一样！🕷️
怎样才能让我们的日志系统乖乖听话呢？✨
1. 只记录我们需要的信息
最简单直接的方法就是不要把整个 Error 对象传递给日志函数，而是只传递我们需要的具体属性：
// ❌ 不推荐的做法 - 会让日志系统"生气"
logger.debug('获取数据时出错啦～', error);
// ✅ 推荐的做法 - 让日志系统开心地工作
logger.debug('获取数据时出错啦～', {
message: error.message,
stack: error.stack,
code: error.code
});
2. 使用专门的错误序列化函数
你可以创建一个专门用于序列化 Error 对象的函数，就像给 Error 对象穿上一件"安全外套"：
function serializeError(error) {
return {
name: error.name,
message: error.message,
stack: error.stack,
code: error.code,
// 添加其他你需要的属性
};
}
// 使用方式
logger.debug('获取数据时出错啦～', serializeError(error));
3. 使用成熟的错误处理库
有些库专门为处理这类问题而设计，比如 serialize-error，它们就像专业的保姆一样，会把 Error 对象照顾得好好的：
const { serializeError } = require('serialize-error');
logger.debug('获取数据时出错啦～', serializeError(error));
4. 配置日志库的防护机制
如果你使用的是 Winston，可以配置一些防护机制，给它穿上"防弹衣"：
const winston = require('winston');
const logger = winston.createLogger({
format: winston.format.combine(
winston.format.errors({ stack: true }),
winston.format.json()
),
// ... 其他配置
});
最佳实践小贴士 🌟
-
永远不要直接记录原始的 Error 对象：它们可能包含复杂的循环引用结构，就像一个调皮的小恶魔。
-
提取关键信息：只记录我们需要的错误信息，比如 message、stack 等，就像挑选糖果一样只拿最喜欢的。
-
使用安全的序列化方法：确保我们的日志系统能够处理各种边界情况，做一个贴心的小棉袄。
-
添加防护措施：在日志处理逻辑中添加 try-catch 块，防止日志系统本身成为故障点，就像给程序戴上安全帽。
-
测试边界情况：在测试中模拟各种错误场景，确保日志系统在极端情况下也能正常工作，做一个负责任的好孩子。
Terrifying! My Node.js System Crashed Because of Logging an Error Object 😱
Fellow developers! Today, while debugging a project locally, I wanted to log some error information, but suddenly the program threw a "Maximum call stack size exceeded" error and crashed the entire project. But when I look at the open-source project I'm using, I see that the official code does this in many places. I was puzzled, why is this happening?
Error Message
[LOGGER PARSING ERROR] Maximum call stack size exceeded
2025-10-13T17:06:59.643Z debug: Error code: 400 - {'error': {'message': 'Budget has been exceeded! Current cost: 28.097367900000002, Max budget: 0.0', 'type': 'budget_exceeded', 'par... [truncated]
{
unknown: [object Object],
}
2025-10-13T17:06:59.643Z debug: [api/server/middleware/abortMiddleware.js] respondWithError called
2025-10-13T17:06:59.644Z error: There was an uncaught error: Cannot read properties of undefined (reading 'emit')
2025-10-13T17:06:59.645Z debug: [indexSync] Clearing sync timeouts before exiting...
[nodemon] app crashed - waiting for file changes before starting...
Error Screenshot
Error Analysis
After work, I couldn't resist investigating why this error was triggered, what the root cause was, and how to solve it. Let's together catch this little troublemaker and see what it's up to! 👻
Reproducing the Scenario
Imagine this scenario, you're happily coding:
app.get('/api/data', async (req, res) => {
try {
// Some business logic that might go wrong
const data = await fetchDataFromAPI();
res.json(data);
} catch (error) {
// Log the error
logger.debug('Error fetching data~', error); // Oops! This line might crash our program!
res.status(500).json({ error: 'Internal server error~' });
}
});
Doesn't this look normal? But when you run this code, suddenly this error appears:
[LOGGER PARSING ERROR] Maximum call stack size exceeded
What's even more神奇 is, if you change the code to this:
console.log(error); // This line won't crash the program, but don't use this in production systems
It works fine! Why is that? 🤔
The Big Reveal of Little Secrets! 🔍
console.log is Good, But Don't Use It to Log PROD Errors!
console.log is a native Node.js function. It's like an extremely experienced uncle who knows how to handle all kinds of "naughty" objects. When console.log encounters objects with circular references, it cleverly detects these circular references and replaces the actual circular parts with [Circular] markers, so it won't recurse infinitely!
Simply put, Node.js's console.log is like a super skilled martial arts master who knows how to dodge and avoid all kinds of traps! 🥋
The "Little Troubles" of Logging Libraries
But our custom logging systems (like Winston used in the project) are different! To implement various cool features (like formatting, filtering sensitive information, etc.), logging libraries often use third-party libraries to process incoming objects.
In our case, the logging system uses the [traverse] library to traverse objects. This library works well in most cases, but when it encounters certain complex Error objects, it might get lost!
Error objects are not as simple as ordinary objects! They may contain various hidden properties, getter methods, and in some cases, dynamically generated properties. When the [traverse] library tries to traverse these complex structures, it may fall into an infinite recursion maze, ultimately causing a stack overflow.
What Are Circular References? 🌀
Before diving deeper into this issue, let's first understand what circular references are. Circular references refer to objects that reference each other, forming a closed loop. For example:
const objA = { name: 'A' };
const objB = { name: 'B' };
objA.ref = objB;
objB.ref = objA; // Oops! Circular reference formed!
When trying to serialize such objects (like with JSON.stringify), problems arise because the serialization process will recurse infinitely, like two hamsters running forever in a wheel! 🐹
Although Error objects look simple, their internal structure can be very complex, especially Error objects created in some frameworks or libraries. They may contain references to request, response, and other objects, and these objects may in turn contain references to the Error object, forming a complex circular reference network, like a giant spider web! 🕷️
How to Make Our Logging System Behave? ✨
1. Only Log the Information We Need
The simplest and most direct method is not to pass the entire Error object to the logging function, but to pass only the specific properties we need:
// ❌ Not recommended - will make the logging system "angry"
logger.debug('Error fetching data~', error);
// ✅ Recommended - makes the logging system work happily
logger.debug('Error fetching data~', {
message: error.message,
stack: error.stack,
code: error.code
});
2. Use a Dedicated Error Serialization Function
You can create a dedicated function for serializing Error objects, like putting a "safety coat" on the Error object:
function serializeError(error) {
return {
name: error.name,
message: error.message,
stack: error.stack,
code: error.code,
// Add other properties you need
};
}
// Usage
logger.debug('Error fetching data~', serializeError(error));
3. Use Mature Error Handling Libraries
Some libraries are specifically designed to handle these kinds of issues, such as serialize-error. They're like professional nannies who will take good care of Error objects:
const { serializeError } = require('serialize-error');
logger.debug('Error fetching data~', serializeError(error));
4. Configure Protective Mechanisms for Logging Libraries
If you're using Winston, you can configure some protective mechanisms to give it "bulletproof armor":
const winston = require('winston');
const logger = winston.createLogger({
format: winston.format.combine(
winston.format.errors({ stack: true }),
winston.format.json()
),
// ... other configurations
});
Best Practice Tips 🌟
-
Never log raw Error objects directly: They may contain complex circular reference structures, like a mischievous little devil.
-
Extract key information: Only log the error information we need, such as message, stack, etc., like picking candy - only take your favorites.
-
Use safe serialization methods: Ensure our logging system can handle various edge cases, be a thoughtful companion.
-
Add protective measures: Add try-catch blocks in the logging logic to prevent the logging system itself from becoming a failure point, like giving the program a safety helmet.
-
Test edge cases: Simulate various error scenarios in testing to ensure the logging system works properly under extreme conditions, be a responsible good child.
Conclusion | 结语
-
That's all for today~ - | 今天就写到这里啦~
-
Guys, (￣ω￣(￣ω￣〃 (￣ω￣〃)ゝ See you tomorrow~ | 小伙伴们，(￣ω￣(￣ω￣〃 (￣ω￣〃)ゝ我们明天再见啦~~
-
Everyone, be happy every day! 大家要天天开心哦
-
Welcome everyone to point out any mistakes in the article~ | 欢迎大家指出文章需要改正之处~
-
Learning has no end; win-win cooperation | 学无止境，合作共赢
-
Welcome all the passers-by, boys and girls, to offer better suggestions! ~ | 欢迎路过的小哥哥小姐姐们提出更好的意见哇~~
登录
