先看一组核心判断：具名函数表达式本身不会自动增强堆栈信息，但配合正确的定义方式、调用上下文和错误捕获机制，能显著提升日志中报错堆栈的可读性与定位精度。关键在于让函数名真实出现在 stack 字符串里，而不是被显示为 anonymous。
确保函数名进入堆栈：拒绝 anonymous
整个事情的前提是函数名能进入堆栈。浏览器的错误堆栈机制依赖函数的 name 属性，这点可以算是运行时的“基本功”。如果函数没有名字，堆栈里出现的要么是 anonymous，要么就是一行冰冷的
- 正确写法应该是这样的：
const fetchData = function fetchFromAPI() { throw new Error('timeout'); };。这样一来，堆栈中会清晰显示fetchFromAPI，而不是一团迷雾。 - 容易踩坑的地方在于：
const fetchData = function() { ... };或者箭头函数const fetchData = () => { ... };，这两种写法都会导致堆栈变成anonymous，等于把排查线索给掐断了。 - 值得一提的是，函数名不必和变量名保持一致，只要函数内部有名字就行。V8 和 SpiderMonkey 都支持这种语法，主流 Node.js 版本（≥12）和现代浏览器也能完美兼容。
保留原始堆栈上下文：别让错误被“切掉”
确定了函数名怎么进堆栈之后，下一步就是怎么把堆栈完整记录下来。现实中很多错误被截断，都是因为在 Promise 链、异步回调或过度嵌套的 try/catch 里丢失了上下文。
- 记录日志时，务必使用
error.stack而不是只记error.message，这样才包含了完整的调用路径，后面即使要分析也能看清全貌。 - 在 Promise 中间出现异常时，优先用
reject(new Error(...))而非throw，而且要确保 .catch 没有被轻易吞掉原始 error 对象，否则堆栈链真的会断掉。 - 如果运行在 Node.js 环境下，可以考虑启用
--async-stack-traces（v12.15+ 默认开启），它能让 async/await 的堆栈连贯性明显提升，排查问题时会省很多心。
借助 source map 做符号化还原：从混淆到可见
生产环境下的代码通常会被压缩和混淆，堆栈里的函数名很可能变成了 t、e 这样的单字母。这时候，具名函数表达式的作用就更关键了，因为一旦函数在混淆前有明确的名字，source map 工具映射回源码时会更精准。
- 构建阶段需要做两件事：一是禁止 webpack 的
optimization.concatenateModules: true，二是在 terser 配置中把keep_fnames设为true。这样才能确保函数名在压缩过程中不被抹掉。 - 把生成的 source map 上传到 Sentry、Datadog 或者自建的 ELK 平台上，同时确保日志上报时附带
error.stack的原始字符串。后面解析时，这些信息就能派上大用场。 - 总体而言，具名函数表达式相比箭头函数或纯粹的匿名函数，在被 source map 工具还原时胜算要大很多，这也意味着更容易追到源码的具体位置。
主动注入上下文：堆栈只是路径，业务线索才是根因
堆栈反映的是代码执行路径，但真正定位问题的根源，往往需要结合业务上下文。比如 traceId、用户 ID、关键参数等，把这些信息附加到 error 对象上，排查效率会大幅提升。
- 可以在函数入口处记录这些信息，并绑定到 error 实例上，例如：
err.context = { traceId, userId, input: redact(params) };。注意对敏感参数做脱敏处理。 - 在 Node.js 环境下，可以利用
Error.captureStackTrace?.(err, fetchFromAPI)来定制 stack 的起始点，过滤掉无关的中间层，让堆栈更干净。 - 更系统化的做法是统一错误构造器，强制所有业务函数使用具名表达式，同时搭配标准化的 error 类型，比如
class ApiTimeoutError extends Error。这样无论是记录还是解析，都不会乱。
记好函数名、留住 stack、配好 source map、注入业务 id——这几步到位了，堆栈的精准还原才算真正落地。
