console.log() 对 Error 对象有特殊处理逻辑，会优先输出可读的错误摘要（如 ReferenceError: xxx is not defined），而非默认展开其所有属性和方法；这是浏览器与 Node.js 等运行时为提升调试效率而设计的统一行为。
`console.log()` 对 `error` 对象有特殊处理逻辑，会优先输出可读的错误摘要（如 `referenceerror: xxx is not defined`），而非默认展开其所有属性和方法；这是浏览器与 node.js 等运行时为提升调试效率而设计的统一行为。
在 JavaScript 开发中，我们常观察到一个看似矛盾的现象：普通对象调用 console.log(obj) 时，控制台会以可交互、可折叠的方式展示其全部自有属性、原型链方法及嵌套结构；但当传入一个 Error 实例（例如 catch(err) { console.log(err); }）时，却只看到一行紧凑的错误摘要信息，如：
ReferenceError: variable is not defined
at script.js:5:3这并非 Error 对象“没有属性”，而是 console.log() 的底层实现对特定类型对象做了语义化格式化优化。
浏览器与 Node.js 的差异化处理机制
在浏览器环境中，console.log 是开发者工具（DevTools）的一部分，其渲染逻辑由 Chromium/Firefox/Safari 等引擎定制。它们将 Error 对象识别为“诊断关键对象”，默认优先展示 message、name 和堆栈 stack 字段，并以高亮、带源码定位的形式呈现，便于快速定位问题。此时，err.name、err.message、err.stack 等核心字段被提升为视觉焦点，而 err.toString() 的结果（即 name + ': ' + message）常作为默认显示文本。
在 Node.js 中，console.log() 底层依赖 util.inspect()，该函数对 Error 类型有显式分支处理：它会忽略 util.inspect() 对普通对象的深度遍历规则，转而调用 error.toString() 并附加格式化的 stack，且默认不展开 prototype 或不可枚举属性（如 __proto__）。你可通过显式配置强制展开：
const util = require('util');
try {
nonExistentVariable;
} catch (err) {
// 默认行为：精简摘要
console.log(err); // → ReferenceError: nonExistentVariable is not defined
// 强制完整 inspect：显示所有属性（包括 stack、fileName、lineNumber 等）
console.log(util.inspect(err, { showHidden: true, depth: null, colors: true }));
}如何查看 Error 对象的全部属性？
若需调试 Error 实例的完整结构（例如检查自定义属性、V8 特有字段或 polyfill 行为），推荐以下方式：
✅ 使用 console.dir()（推荐）
它绕过特殊格式化，以标准对象视图展开所有可枚举/不可枚举属性（取决于环境支持）：
catch (err) {
console.dir(err, { depth: null }); // 显示 name, message, stack, fileName, lineNumber...
}✅ 手动提取关键字段
明确访问常用属性，避免依赖 console.log 的隐式行为：
catch (err) {
console.log({
name: err.name,
message: err.message,
stack: err.stack,
cause: err.cause, // ES2022+
});
}✅ 创建标准化错误日志
在生产环境或日志系统中，应主动序列化关键字段，而非依赖 console.log 的运行时行为：
function logError(err) {
const safeError = {
name: err.name,
message: err.message,
stack: err.stack?.split('\n').slice(0, 5).join('\n'), // 截断长 stack
timestamp: new Date().toISOString(),
};
console.error('[ERROR]', JSON.stringify(safeError, null, 2));
}注意事项与最佳实践
- ❗ console.log(error) 的输出不是规范强制行为，ECMAScript 标准未规定 console API，因此不同环境（旧版 IE、某些嵌入式 JS 引擎）可能表现不一致；
- ❗ Error 对象的 stack 属性是非标准但广泛支持的字段，其格式（如 at ... 行）因引擎而异，不应正则硬解析；
- ✅ 在调试阶段，优先使用 console.dir(err) 获取完整结构；在线上监控中，应主动提取并上报结构化字段；
- ✅ 自定义错误类（如 class ApiError extends Error）需确保 super(message) 被正确调用，否则 name 和 message 可能丢失。
归根结底，console.log(err) 的“简洁输出”是一种以开发者为中心的设计权衡：它牺牲了对象的完整性展示，换取了错误上下文的即时可读性。理解这一机制，能帮助你更精准地选择调试工具，写出更健壮的日志与错误处理逻辑。
