JavaScript 异步任务中的异常捕获：try-catch 为何无法捕获 setTimeout 内的错误

各位技术同仁，下午好！

今天，我们将深入探讨一个在JavaScript异步编程中，尤其是在初学者乃至经验丰富的开发者中都可能产生困惑的核心问题：为什么我们尝试用try-catch来捕获setTimeout回调函数内部的错误时，它往往会失灵？这是一个看似简单实则触及JavaScript运行时机制深层原理的问题。理解它，不仅能帮助我们写出更健壮的异步代码，更能深化我们对JavaScript执行模型，特别是事件循环（Event Loop）的认识。

我们将以一场讲座的形式，逐步揭开这个谜团，从基础概念讲起，通过丰富的代码示例，最终提供一系列有效的异步错误处理策略。

1. JavaScript的单线程本质与同步错误捕获

要理解try-catch为何在setTimeout中失效，我们必须首先回顾JavaScript的核心执行模型。JavaScript被设计为单线程语言，这意味着在任何给定的时刻，浏览器或Node.js的JavaScript引擎只能执行一个代码块。这个“单线程”并非指程序不能做多件事，而是指它在主线程上一次只能处理一个任务。

所有的JavaScript代码都在一个称为“调用栈”（Call Stack）的结构中执行。当一个函数被调用时，它被推入调用栈；当函数执行完毕返回时，它被从栈中弹出。

try-catch语句是JavaScript中用于同步错误处理的基石。它允许我们“尝试”执行一段可能出错的代码，并在错误发生时“捕获”它，从而防止程序崩溃。

让我们看一个简单的同步错误捕获示例：

console.log("--- 同步错误捕获示例开始 ---");

function riskySyncOperation() {
    console.log("执行同步风险操作...");
    // 故意抛出一个错误
    throw new Error("这是一个来自同步代码的错误！");
    console.log("这行代码永远不会执行到。"); // 死代码
}

try {
    riskySyncOperation();
    console.log("同步操作成功完成。"); // 这行不会执行
} catch (error) {
    console.error("捕获到同步错误:", error.message);
} finally {
    console.log("同步try-catch块执行完毕。");
}

console.log("--- 同步错误捕获示例结束 ---");

执行流程分析:

1. console.log("--- 同步错误捕获示例开始 ---"); 被推入调用栈并执行。
2. try 块开始执行。
3. riskySyncOperation() 被推入调用栈。
4. console.log("执行同步风险操作..."); 执行。
5. throw new Error(...) 被执行，一个错误被抛出。
6. JavaScript引擎检测到错误，并向上查找调用栈中最近的catch块。
7. riskySyncOperation() 从调用栈中弹出。
8. catch (error) 块被触发，错误对象被传递给它。
9. console.error("捕获到同步错误:", error.message); 执行。
10. finally 块执行。
11. console.log("同步try-catch块执行完毕。"); 执行。
12. console.log("--- 同步错误捕获示例结束 ---"); 执行。

在这个例子中，try-catch能够完美地捕获到riskySyncOperation函数内部抛出的错误，因为错误发生时，try-catch块仍然处于活跃的执行上下文中，错误在同一个调用栈中传播。

2. 深入理解异步：setTimeout与事件循环

现在，让我们将目光转向异步操作。JavaScript的单线程模型如何在不阻塞主线程的情况下处理耗时操作（如网络请求、定时器）呢？答案就是“事件循环”（Event Loop）。

事件循环是JavaScript运行时环境（无论是浏览器还是Node.js）的一个核心组成部分。它与调用栈、任务队列（或称为消息队列，Message Queue）协同工作，实现了非阻塞的异步编程。

核心概念:

• 调用栈 (Call Stack): 负责执行同步代码。
• Web APIs / Node.js APIs: 浏览器或Node.js提供的非JavaScript运行时环境功能，例如setTimeout、fetch、DOM事件等。当JavaScript代码调用这些API时，这些API会将任务委托给底层系统处理。
• 任务队列 (Task Queue / Callback Queue): 当Web API完成其委托的任务（例如定时器到期，网络请求返回数据）后，会将相应的回调函数放入任务队列。
• 事件循环 (Event Loop): 持续监控调用栈和任务队列。当调用栈为空时（即所有同步代码都已执行完毕），事件循环会从任务队列中取出一个回调函数，并将其推入调用栈执行。

setTimeout函数就是一个典型的异步Web API（或Node.js API）。当你调用setTimeout(callback, delay)时，它不会立即执行callback函数。相反，它会将callback函数和delay参数交给宿主环境（浏览器或Node.js）的定时器模块处理。定时器模块会在delay毫秒后，将callback函数放入任务队列。

让我们通过一个简单的setTimeout示例来观察其异步特性：

console.log("--- setTimeout 异步示例开始 ---");

setTimeout(() => {
    console.log("setTimeout 回调函数执行了！");
}, 0); // 延迟0毫秒，但这并不意味着立即执行

console.log("主线程代码继续执行。");

console.log("--- setTimeout 异步示例结束 ---");

执行流程分析:

1. console.log("--- setTimeout 异步示例开始 ---"); 被推入调用栈并执行。
2. setTimeout(() => {...}, 0); 被推入调用栈。
   • setTimeout本身是同步执行的，它将回调函数和延迟时间交给Web API（或Node.js API）。
   • setTimeout函数执行完毕，从调用栈弹出。
3. console.log("主线程代码继续执行。"); 被推入调用栈并执行。
4. console.log("--- setTimeout 异步示例结束 ---"); 被推入调用栈并执行。
5. 此时，调用栈变为空。
6. Web API的定时器模块在0毫秒后（实际上是尽快，但不是立即）将() => { console.log("setTimeout 回调函数执行了！"); } 这个回调函数放入任务队列。
7. 事件循环检测到调用栈为空，并且任务队列中有待处理的任务。
8. 事件循环将任务队列中的回调函数推入调用栈。
9. console.log("setTimeout 回调函数执行了！"); 被推入调用栈并执行。
10. 回调函数执行完毕，从调用栈弹出。

输出结果:

--- setTimeout 异步示例开始 ---
主线程代码继续执行。
--- setTimeout 异步示例结束 ---
setTimeout 回调函数执行了！

这清晰地表明，setTimeout的回调函数是在所有同步代码执行完毕，调用栈清空之后才被事件循环推入并执行的。

3. try-catch为何无法捕获setTimeout内的错误：异步边界

现在，我们终于来到了问题的核心。为什么try-catch无法捕获setTimeout回调函数内部的错误？

关键在于：try-catch是同步的。它只能捕获在当前执行上下文中、在它被执行的同一调用栈上发生的错误。

当你在一个try-catch块内部调用setTimeout时，try-catch块所能“看管”的范围，仅仅是setTimeout函数本身被调用时的那个同步执行过程。它无法“跨越”异步边界，去监听将来某个时刻，在另一个独立的调用栈上执行的setTimeout回调函数。

让我们通过一个失败的示例来证明这一点：

console.log("--- 失败的 setTimeout 错误捕获示例开始 ---");

try {
    console.log("尝试在 try 块内调用 setTimeout...");
    setTimeout(() => {
        console.log("setTimeout 回调函数开始执行...");
        // 故意在回调函数中抛出一个错误
        throw new Error("这是一个来自 setTimeout 回调函数的错误！");
        console.log("这行代码永远不会执行到 (在回调函数内)。");
    }, 1000); // 延迟1秒
    console.log("setTimeout 调用已安排，try 块即将结束。");
} catch (error) {
    // 理论上我们希望在这里捕获到错误，但实际上不会
    console.error("在外部 try-catch 块中捕获到错误:", error.message);
} finally {
    console.log("外部 try-catch 块执行完毕。");
}

console.log("--- 失败的 setTimeout 错误捕获示例结束 ---");

执行流程分析:

1. console.log("--- 失败的 setTimeout 错误捕获示例开始 ---"); 执行。
2. try 块开始执行。
3. console.log("尝试在 try 块内调用 setTimeout..."); 执行。
4. setTimeout(...) 被调用。
   • 这个setTimeout调用本身是同步的，它将回调函数交给宿主环境的定时器模块。
   • 在setTimeout函数执行期间，并没有发生任何错误。
   • setTimeout函数执行完毕，从调用栈弹出。
5. console.log("setTimeout 调用已安排，try 块即将结束。"); 执行。
6. try 块内的所有同步代码执行完毕，没有错误发生。因此，catch块不会被触发。
7. finally 块执行。
8. console.log("外部 try-catch 块执行完毕。"); 执行。
9. console.log("--- 失败的 setTimeout 错误捕获示例结束 ---"); 执行。
10. 此时，调用栈为空，事件循环开始工作。
11. 1秒后，宿主环境的定时器模块将() => {...}回调函数放入任务队列。
12. 事件循环将该回调函数推入调用栈。
13. console.log("setTimeout 回调函数开始执行..."); 执行。
14. throw new Error(...) 被执行，一个错误被抛出。
15. JavaScript引擎检测到错误。由于此时外部的try-catch块已经执行完毕并从调用栈中移除，当前调用栈上没有活动的catch块来捕获这个错误。
16. 这个错误向上冒泡，最终成为一个未捕获的全局错误。 在浏览器环境中，这通常会导致错误信息打印到控制台，并可能触发window.onerror事件；在Node.js环境中，则可能触发process.on('uncaughtException')事件，并默认导致进程崩溃。

输出结果:

--- 失败的 setTimeout 错误捕获示例开始 ---
尝试在 try 块内调用 setTimeout...
setTimeout 调用已安排，try 块即将结束。
外部 try-catch 块执行完毕。
--- 失败的 setTimeout 错误捕获示例结束 ---
setTimeout 回调函数开始执行...
// 1秒后，控制台会输出一个未捕获的错误信息，类似：
Uncaught Error: 这是一个来自 setTimeout 回调函数的错误！
    at <anonymous>:...

核心结论： try-catch块在setTimeout的回调函数执行之前就已经完成了它的工作。当回调函数最终执行时，它拥有自己的、独立的执行上下文，与最初的try-catch块所在的上下文是完全分离的。

特性	同步 try-catch	异步 setTimeout 内部错误
错误发生时机	在 try 块的当前执行上下文中立即发生。	在 setTimeout 回调函数被事件循环调度执行时发生。
调用栈状态	try-catch 块及其内部函数都在同一个调用栈上。	try-catch 块所在的调用栈已清空，回调函数在新的调用栈上执行。
捕获能力	可以捕获当前调用栈上的任何错误。	无法捕获在未来、独立调用栈上发生的错误。
错误传播	错误在当前调用栈中向上冒泡，直到被 catch 捕获。	错误成为一个未捕获的全局错误。

4. JavaScript的错误处理机制概览

为了有效地处理异步错误，我们需要了解JavaScript提供了哪些错误处理机制，以及它们分别适用于什么场景。

机制	类型	适用场景	备注
try-catch	同步	捕获同一执行上下文中发生的同步错误。	无法跨越异步边界。
window.onerror (浏览器)	全局/异步	捕获所有未被 try-catch 捕获的运行时错误。	只能获取错误信息，不能阻止错误发生。
process.on('uncaughtException') (Node.js)	全局/异步	捕获所有未被 try-catch 捕获的同步和异步错误。	捕获后应谨慎处理，通常建议重启应用。
Promise.prototype.catch()	异步	捕获 Promise 链中的拒绝（rejection）。	Promise 链中任何一个 Promise 拒绝，都会被最近的 .catch() 捕获。
window.addEventListener('unhandledrejection') (浏览器)	全局/异步	捕获未被 .catch() 处理的 Promise 拒绝。	用于处理 Promise 链末端没有 .catch() 的情况。
process.on('unhandledRejection') (Node.js)	全局/异步	捕获未被 .catch() 处理的 Promise 拒绝。	Node.js 中类似 unhandledrejection。
async/await 与 try-catch	异步	以同步方式书写和捕获 Promise 链中的错误。	try-catch 必须包裹 await 表达式，且函数必须是 async。

5. setTimeout回调函数中错误捕获的有效策略

既然外部try-catch无法奏效，那么我们如何在setTimeout的回调函数中优雅地处理错误呢？以下是几种行之有效的策略。

策略一：在setTimeout回调函数内部使用try-catch

这是最直接、最基础的解决方案。如果错误发生在回调函数内部，那么就将try-catch块放到回调函数内部。这样，当回调函数被事件循环推入调用栈并执行时，它自己的try-catch就可以捕获到内部发生的错误。

console.log("--- 策略一：setTimeout 回调内部 try-catch 示例开始 ---");

setTimeout(() => {
    try {
        console.log("setTimeout 回调函数内部开始执行...");
        // 故意在回调函数中抛出一个错误
        throw new Error("这是来自 setTimeout 回调内部的错误！");
        console.log("这行代码永远不会执行到 (在回调函数内)。");
    } catch (error) {
        console.error("在 setTimeout 回调内部捕获到错误:", error.message);
    } finally {
        console.log("setTimeout 回调内部的 try-catch 块执行完毕。");
    }
}, 1000);

console.log("主线程代码继续执行，等待 setTimeout...");

console.log("--- 策略一：setTimeout 回调内部 try-catch 示例结束 ---");

执行流程与输出:

1. 同步代码按顺序执行，包括安排setTimeout。
2. 主线程代码继续执行，等待 setTimeout... 打印。
3. --- 策略一：setTimeout 回调内部 try-catch 示例结束 --- 打印。
4. 1秒后，setTimeout回调函数被事件循环推入调用栈。
5. 回调函数内部的try块开始执行。
6. setTimeout 回调函数内部开始执行... 打印。
7. throw new Error(...) 被执行，错误抛出。
8. 内部catch块捕获到错误，在 setTimeout 回调内部捕获到错误:... 打印。
9. finally块执行，setTimeout 回调内部的 try-catch 块执行完毕。 打印。

优点:

• 简单直观，直接解决了问题。
• 错误捕获精确到回调函数内部。

缺点:

• 对于每一个setTimeout回调都需要手动添加try-catch，如果有很多setTimeout，代码会显得冗余。
• 无法捕获setTimeout本身（即其参数）在安排过程中可能发生的同步错误（但这种情况较少见，且try-catch可捕获）。

策略二：使用全局错误处理器 (作为最后的防线)

尽管我们应该尽量在局部捕获错误，但作为一种兜底机制，全局错误处理器是必不可少的。它们能够捕获任何未被局部try-catch处理的运行时错误。

在浏览器环境中：window.onerror

当一个未捕获的错误在浏览器主线程中发生时（包括setTimeout回调中未被捕获的错误），window.onerror事件会被触发。

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>全局错误处理示例 (浏览器)</title>
</head>
<body>
    <h1>请打开控制台查看错误信息</h1>

    <script>
        console.log("--- 策略二：window.onerror 示例开始 ---");

        // 注册全局错误处理器
        window.onerror = function(message, source, lineno, colno, error) {
            console.error("通过 window.onerror 捕获到全局错误:");
            console.error("消息:", message);
            console.error("源文件:", source);
            console.error("行号:", lineno);
            console.error("列号:", colno);
            console.error("错误对象:", error);
            // 返回 true 表示错误已处理，阻止浏览器默认的错误报告（例如在控制台打印）
            return true;
        };

        setTimeout(() => {
            console.log("setTimeout 回调函数即将抛出未捕获错误...");
            // 故意抛出错误，且没有内部 try-catch
            throw new Error("这是一个未被局部捕获的 setTimeout 错误！");
        }, 1000);

        setTimeout(() => {
            try {
                console.log("setTimeout (有内部 try-catch) 回调函数即将抛出错误...");
                throw new Error("这是一个被局部捕获的 setTimeout 错误！");
            } catch (e) {
                console.warn("局部捕获成功:", e.message);
            }
        }, 2000);

        console.log("--- 策略二：window.onerror 示例结束 ---");
    </script>
</body>
</html>

在Node.js环境中：process.on('uncaughtException')

在Node.js中，uncaughtException事件会在一个未捕获的异常冒泡到事件循环的顶部时被触发。

// Node.js 环境
console.log("--- 策略二：process.on('uncaughtException') 示例开始 ---");

// 注册全局未捕获异常处理器
process.on('uncaughtException', (error) => {
    console.error("通过 process.on('uncaughtException') 捕获到全局错误:");
    console.error("错误类型:", error.name);
    console.error("错误信息:", error.message);
    console.error("错误堆栈:", error.stack);
    // 注意：在捕获到 uncaughtException 后，进程处于不确定状态。
    // 通常建议在记录错误后优雅地关闭或重启应用。
    // process.exit(1); // 生产环境中可能需要退出进程
});

setTimeout(() => {
    console.log("setTimeout 回调函数即将抛出未捕获错误...");
    // 故意抛出错误，且没有内部 try-catch
    throw new Error("这是一个未被局部捕获的 setTimeout 错误 (Node.js)！");
}, 1000);

setTimeout(() => {
    try {
        console.log("setTimeout (有内部 try-catch) 回调函数即将抛出错误...");
        throw new Error("这是一个被局部捕获的 setTimeout 错误 (Node.js)！");
    } catch (e) {
        console.warn("局部捕获成功 (Node.js):", e.message);
    }
}, 2000);

console.log("--- 策略二：process.on('uncaughtException') 示例结束 ---");

// 确保进程不会立即退出，以便 setTimeout 有机会执行
// 但在实际应用中，如果捕获 uncaughtException，通常会选择退出
// setTimeout(() => {}, 5000); // 仅为演示目的，让进程保持活动

优点:

• 作为最终的保障，捕获任何未被局部处理的错误。
• 有助于错误监控和日志记录。

缺点:

• window.onerror和uncaughtException只是“报告”错误，它们并不能阻止错误发生，也不能恢复程序的正常执行流程（尤其是在Node.js中，uncaughtException后的应用程序状态是不可靠的）。
• 错误发生时，上下文信息可能不如局部try-catch那样丰富。

策略三：将setTimeout“Promise化”，并结合async/await和try-catch

在现代JavaScript中，Promise和async/await是处理异步操作的首选方式。通过将基于回调的API（如setTimeout）封装成Promise，我们可以利用Promise的错误处理机制（.catch()），并进一步结合async/await，以同步的语法来编写异步代码，从而让try-catch在异步流程中发挥作用。

首先，我们需要一个“Promise化”的delay函数：

/**
 * 返回一个 Promise，在指定延迟后解决或拒绝。
 * @param {number} ms 延迟毫秒数。
 * @param {boolean} shouldReject 是否应该拒绝 Promise。
 * @returns {Promise<void>}
 */
function delay(ms, shouldReject = false) {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            if (shouldReject) {
                reject(new Error(`延迟 ${ms}ms 后发生错误！`));
            } else {
                resolve();
            }
        }, ms);
    });
}

现在，我们可以用async/await和try-catch来处理它：

console.log("--- 策略三：async/await + try-catch 示例开始 ---");

async function performAsyncOperation() {
    try {
        console.log("开始异步操作...");
        await delay(1000); // 等待1秒
        console.log("1秒延迟完成。");

        // 模拟一个可能出错的异步步骤
        await delay(500, true); // 延迟0.5秒后抛出错误
        console.log("这行代码不会执行到。");

    } catch (error) {
        console.error("在 async/await try-catch 中捕获到错误:", error.message);
    } finally {
        console.log("async 函数的 try-catch 块执行完毕。");
    }
}

performAsyncOperation();

// 如果 async 函数内部没有 catch 错误，未处理的 Promise 拒绝会触发 unhandledrejection
async function performAsyncOperationWithoutCatch() {
    console.log("开始没有内部 catch 的异步操作...");
    await delay(2000);
    console.log("2秒延迟完成。");
    await delay(500, true); // 抛出错误
    console.log("这行代码也不会执行到。");
}

// 确保在全局捕获 unhandledrejection
if (typeof window !== 'undefined') { // 浏览器环境
    window.addEventListener('unhandledrejection', (event) => {
        console.error("通过 unhandledrejection 捕获到未处理的 Promise 拒绝:", event.reason.message);
        event.preventDefault(); // 阻止浏览器默认处理 (例如在控制台打印)
    });
} else if (typeof process !== 'undefined') { // Node.js 环境
    process.on('unhandledRejection', (reason, promise) => {
        console.error("通过 unhandledRejection 捕获到未处理的 Promise 拒绝:", reason.message);
    });
}

performAsyncOperationWithoutCatch(); // 这个调用会触发 unhandledrejection

console.log("--- 策略三：async/await + try-catch 示例结束 ---");

执行流程与输出:

1. 同步代码执行，包括安排performAsyncOperation和performAsyncOperationWithoutCatch。
2. performAsyncOperation被调用，它是一个async函数，立即返回一个Promise。
3. try块开始执行，await delay(1000)暂停performAsyncOperation的执行，等待delay Promise解决。
4. 主线程继续执行其他同步代码，包括调用performAsyncOperationWithoutCatch。
5. performAsyncOperationWithoutCatch被调用，也立即返回一个Promise。await delay(2000)暂停其执行。
6. --- 策略三：async/await + try-catch 示例结束 --- 打印。
7. 1秒后，第一个delay Promise解决，performAsyncOperation恢复执行。
8. 1秒延迟完成。 打印。
9. await delay(500, true)被调用，它会返回一个拒绝的Promise。
10. try-catch捕获到这个拒绝，在 async/await try-catch 中捕获到错误:... 打印。
11. async 函数的 try-catch 块执行完毕。 打印。
12. 2秒后，第二个delay Promise解决，performAsyncOperationWithoutCatch恢复执行。
13. 2秒延迟完成。 打印。
14. await delay(500, true)被调用，返回一个拒绝的Promise。
15. 由于performAsyncOperationWithoutCatch函数内部没有try-catch来捕获这个拒绝，它会成为一个未处理的Promise拒绝，触发unhandledrejection事件。

优点:

• 以同步的、更易读的方式处理异步错误。
• try-catch能够有效地捕获整个async函数内部的Promise拒绝。
• 符合现代JavaScript异步编程的最佳实践。

缺点:

• 需要将基于回调的API封装成Promise。
• 如果async函数本身没有try-catch或.catch()，其拒绝仍会导致未处理的Promise拒绝。

策略四：错误优先回调 (Node.js 传统模式)

虽然不直接针对setTimeout，但在Node.js的很多传统API中，错误优先回调（Error-First Callback）是一个常见的模式。这种模式下，回调函数的第一个参数约定为错误对象（如果有），第二个参数才是成功结果。虽然setTimeout本身不遵循这个模式，但我们可以自定义一个setTimeout的封装来模拟它。

console.log("--- 策略四：错误优先回调模拟示例开始 ---");

/**
 * 模拟一个带有错误优先回调的异步操作
 * @param {number} delayMs 延迟毫秒数
 * @param {boolean} shouldError 是否应该在回调中返回错误
 * @param {Function} callback 错误优先回调函数 (err, data)
 */
function myAsyncOperation(delayMs, shouldError, callback) {
    setTimeout(() => {
        if (shouldError) {
            callback(new Error(`异步操作在延迟 ${delayMs}ms 后失败了！`));
        } else {
            callback(null, `异步操作在延迟 ${delayMs}ms 后成功完成。`);
        }
    }, delayMs);
}

// 成功案例
myAsyncOperation(1000, false, (err, data) => {
    if (err) {
        console.error("成功案例捕获到错误:", err.message);
    } else {
        console.log("成功案例结果:", data);
    }
});

// 失败案例
myAsyncOperation(2000, true, (err, data) => {
    if (err) {
        console.error("失败案例捕获到错误:", err.message);
    } else {
        console.log("失败案例结果:", data);
    }
});

console.log("--- 策略四：错误优先回调模拟示例结束 ---");

优点:

• 在Node.js生态系统中有广泛的应用，对于处理传统API很有用。
• 强制开发者在每个异步操作的回调中考虑错误情况。

缺点:

• 回调地狱（Callback Hell）问题，代码可读性随着异步操作链的增加而下降。
• 不适用于浏览器环境中的setTimeout原生行为。
• 不能使用try-catch来捕获，必须通过回调函数的第一个参数检查错误。

策略五：封装或装饰setTimeout以实现统一错误处理

如果你有大量需要处理错误的setTimeout调用，并且不希望每次都手动编写try-catch，可以创建一个封装函数来统一处理。这个封装函数可以接收一个回调函数，并在执行回调时自动包裹try-catch。

console.log("--- 策略五：封装 setTimeout 示例开始 ---");

/**
 * 一个安全的 setTimeout 封装，自动捕获回调函数中的错误并交由错误处理器处理。
 * @param {Function} callback 要执行的回调函数。
 * @param {number} delay 延迟毫秒数。
 * @param {Function} errorHandler 可选的错误处理函数，默认为 console.error。
 * @returns {NodeJS.Timeout | number} setTimeout 的返回值。
 */
function safeSetTimeout(callback, delay, errorHandler = console.error) {
    return setTimeout(() => {
        try {
            callback();
        } catch (error) {
            errorHandler("safeSetTimeout 捕获到错误:", error);
        }
    }, delay);
}

// 使用封装后的 safeSetTimeout
safeSetTimeout(() => {
    console.log("safeSetTimeout 回调执行 (无错误)...");
}, 1000);

safeSetTimeout(() => {
    console.log("safeSetTimeout 回调执行 (有错误)...");
    throw new Error("这是 safeSetTimeout 自动捕获的错误！");
}, 2000);

// 使用自定义错误处理器
safeSetTimeout(() => {
    console.log("safeSetTimeout 回调执行 (有错误，自定义处理器)...");
    throw new Error("这是 safeSetTimeout 自动捕获的错误 (自定义处理)！");
}, 3000, (prefix, error) => {
    console.warn(prefix, "自定义处理：", error.message);
});

console.log("--- 策略五：封装 setTimeout 示例结束 ---");

优点:

• 实现了代码复用，减少了重复的try-catch代码。
• 提供了统一的错误处理入口，便于日志记录、上报等。
• 提高了代码的健壮性。

缺点:

• 需要引入一个额外的封装层。
• 对于非常简单的setTimeout，可能感觉有些过度设计。

6. 异步编程中的微任务与宏任务

为了更全面地理解JavaScript的异步执行模型，有必要简要提及微任务（Microtasks）和宏任务（Macrotasks）的区别。事件循环处理任务时，会优先处理所有可用的微任务，然后才从宏任务队列中取出一个宏任务执行。

• 宏任务 (Macrotasks):
  • setTimeout
  • setInterval
  • setImmediate (Node.js)
  • I/O 操作
  • UI 渲染 (浏览器)
  • MessageChannel
  • requestAnimationFrame (浏览器)
• 微任务 (Microtasks):
  • Promise 的 .then(), .catch(), .finally() 回调
  • queueMicrotask
  • MutationObserver (浏览器)
  • process.nextTick (Node.js)

事件循环的优先级：

1. 执行当前宏任务（包括同步代码）。
2. 检查微任务队列，执行并清空所有微任务。
3. 渲染UI (浏览器)。
4. 从宏任务队列中取出一个新的宏任务，重复以上步骤。

这个机制解释了为什么Promise.resolve().then(...)会比setTimeout(..., 0)先执行，即使setTimeout的延迟是0。因为Promise.then的回调是微任务，而setTimeout的回调是宏任务。

特性	宏任务 (Macrotask)	微任务 (Microtask)
例子	setTimeout, setInterval, I/O, UI 渲染	Promise.then/catch/finally, queueMicrotask, process.nextTick
执行时机	当前宏任务执行完毕，清空微任务队列后，事件循环从宏任务队列中取下一个宏任务执行。	在当前宏任务执行完毕后、下一个宏任务开始之前，清空所有微任务。
优先级	较低	较高

理解这一点对于处理复杂异步流程的顺序至关重要，尽管它不是try-catch在setTimeout中失败的直接原因，但它完善了我们对JavaScript异步模型中错误传播的理解。例如，未处理的Promise拒绝（微任务）和setTimeout中的未捕获错误（宏任务）都会被全局错误处理器捕获，但它们触发的时机和机制略有不同。

7. 结语

通过今天的讲座，我们深入探讨了try-catch为何无法捕获setTimeout回调函数内部错误的根本原因：JavaScript的单线程执行模型和事件循环机制。try-catch的同步特性决定了它只能在当前执行上下文中捕获错误，而setTimeout的回调函数则是在未来的某个时间点，在一个全新的、独立的执行上下文中被事件循环调度的。

我们学习了多种有效的策略来处理setTimeout及其他异步操作中的错误，包括在回调内部使用try-catch、利用全局错误处理器作为兜底、通过Promise和async/await构建更强大的异步错误处理流，以及通过封装函数实现统一管理。

掌握这些知识，对于编写健壮、可维护的JavaScript应用程序至关重要。理解异步边界和错误传播的原理，是成为一名优秀的JavaScript开发者的关键一步。希望今天的分享能帮助大家在未来的编程实践中更加游刃有余。