前端错误监控与处理实战指南

但 window.onerror 有个巨坑——它抓不到跨域脚本的错误。啥意思呢？你引了个 CDN 上的 jQuery，那里面出错了，onerror 收到的信息就是"Script error"，其他啥也没有。这是浏览器的安全策略，怕你别有用心地探测其他域的脚本内容。要解决这个问题，得两边配合：CDN 那边要加 Access-Control-Allow-Origin 头，你这边 script 标签要加 crossorigin="anonymous"。

<!-- 不加 crossorigin，报错信息会被浏览器吞掉 -->
<script src="https://cdn.example.com/app.js"></script>
<!-- 加了 crossorigin，配合 CDN 的 CORS 头，才能拿到详细错误 -->
<script src="https://cdn.example.com/app.js" crossorigin="anonymous"></script>

console.error 就是个摆设，别指望它

很多人喜欢在代码里 console.error 一下，觉得这样就算处理了错误。兄弟，console.error 只是打印到控制台，它既不阻止程序崩溃，也不通知你去处理。更关键的是，生产环境谁看控制台啊？用户的浏览器控制台你看得见吗？

而且异步错误这东西，真的是个幽灵。你看这段代码：

// 这种错误，window.onerror 根本抓不到
setTimeout(() => {
    throw new Error('我在异步里爆炸了');
}, 1000);

// Promise 里的错误，onerror 也看不见
Promise.resolve().then(() => {
    throw new Error('Promise 内部错误');
});

// async/await 如果没包 try-catch，也是悄无声息地挂
async function fetchData() {
    const response = await fetch('/api/data');
    // 如果这里网络错误，整个函数就停了
    const data = await response.json();
    // 如果返回的不是 JSON，这里又炸
    return data;
}

这些异步错误，window.onerror 一个都抓不到。它们就像深夜里的刺客，悄无声息地把你的程序干掉，然后消失在事件循环的黑暗中。

Promise.reject 这个定时炸弹

Promise 如果没处理 rejection，那简直就是埋了个地雷。而且这地雷还有个特性——专门挑你上线那天炸。

// 这种写法，如果 fetch 失败，Promise 就处于 rejected 状态，但没人管
function getUserInfo(userId) {
    return fetch(`/api/user/${userId}`).then(res => res.json());
}

// 调用的时候没 catch，错误就漏了
getUserInfo(123).then(data => {
    renderUser(data);
    // 如果前面 reject 了，这行根本不会执行
});

// 没有 .catch()，错误就被"吞"了（其实浏览器会报 unhandledrejection，但很多人忽略这个）

// 正确的姿势应该是这样
getUserInfo(123).then(data => renderUser(data)).catch(err => {
    console.error('获取用户信息失败:', err);
    showErrorToast('用户信息加载失败，请重试');
    // 甚至可以上报错误
    reportError({
        type: 'API_ERROR',
        api: '/api/user/123',
        error: err.message
    });
});

而且现代浏览器对 unhandled rejection 的处理越来越严格。以前可能只是个警告，现在有些环境直接给你把进程杀了。所以一定得加上全局的 unhandledrejection 监听：

window.addEventListener('unhandledrejection', function(event) {
    // event.reason 就是 reject 的原因（通常是 Error 对象）
    const errorInfo = {
        type: 'unhandled_promise_rejection',
        message: event.reason?.message || 'Unknown promise rejection',
        stack: event.reason?.stack || 'No stack',
        timestamp: new Date().toISOString()
    };
    // 上报错误
    reportError(errorInfo);
    // 阻止浏览器默认行为（比如在控制台打印）
    event.preventDefault();
});

// 还有个 rejectionhandled 事件，用来监听"迟到"的 catch
window.addEventListener('rejectionhandled', function(event) {
    // 这个很少用，但知道有这个东西就行
    console.log('Promise rejection was handled later:', event.reason);
});

资源加载失败，浏览器的提示有多敷衍

图片挂了、CSS 404 了、脚本加载失败，这些错误 window.onerror 也抓不到。你得用专门的 error 事件监听：

// 监听图片加载失败
document.addEventListener('error', function(event) {
    const target = event.target;
    // 判断是不是图片
    if (target.tagName === 'IMG') {
        console.error('图片加载失败:', target.src);
        // 可以搞个兜底图，别让页面丑着
        target.src = '/assets/fallback-image.png';
        // 上报错误，带上图片 URL
        reportError({
            type: 'RESOURCE_ERROR',
            resourceType: 'image',
            url: target.src,
            pageUrl: window.location.href
        });
    }
    // 判断是不是脚本
    if (target.tagName === 'SCRIPT') {
        reportError({
            type: 'RESOURCE_ERROR',
            resourceType: 'script',
            url: target.src,
            // 脚本错误比较严重，可能需要立即通知
            severity: 'high'
        });
    }
}, true);

// 注意这里要用捕获阶段，因为 error 事件不冒泡

// 还有个专门的 window.addEventListener('error') 可以抓资源错误
window.addEventListener('error', function(event) {
    // event.target 可以判断是哪种资源
    console.log('资源错误详情:', event.target);
}, true);

但说实话，资源错误的堆栈信息基本为零，你就只能知道"某个 URL 加载失败了"，至于为啥失败（是 404？还是超时？还是被 CORS 拦截了？），得靠猜。这时候 network 条件的上下文就特别重要，后面会讲到怎么收集这些信息。

给代码穿上防弹衣，这些监控手段必须安排上

知道了浏览器怎么"发疯"，咱们就得给代码穿上防弹衣。但防弹衣也不能乱穿，穿太厚影响行动（性能），穿太薄又防不住子弹（漏报）。

网络错误这块，很多人其实没监控到位

大家通常只关心 JS 逻辑错误，但线上问题一大半其实是网络相关的。接口超时、返回 500、DNS 解析失败，这些"外家功夫"不防，用户该骂娘还是骂娘。

// 封装一个带监控的 fetch，别直接用原生 fetch
class MonitoredFetch {
    constructor(options = {}) {
        this.timeout = options.timeout || 10000; // 默认 10 秒超时
        this.retries = options.retries || 1; // 默认重试 1 次
        this.baseURL = options.baseURL || '';
    }

    async request(url, options = {}) {
        const fullURL = this.baseURL + url;
        const startTime = performance.now();
        let attemptCount = 0;

        const executeRequest = async () => {
            attemptCount++;
            try {
                // 创建 AbortController 用于超时控制
                const controller = new AbortController();
                const timeoutId = setTimeout(() => controller.abort(), this.timeout);
                const response = await fetch(fullURL, {
                    ...options,
                    signal: controller.signal
                });
                clearTimeout(timeoutId);

                // 记录性能数据，不管成功失败都要记
                const duration = performance.now() - startTime;
                this.logPerformance(fullURL, duration, response.status);

                // HTTP 错误状态也要当作错误处理
                if (!response.ok) {
                    throw new HTTPError(`HTTP ${response.status}`, response.status, fullURL);
                }
                return response;
            } catch (error) {
                // 区分错误类型
                if (error.name === 'AbortError') {
                    throw new TimeoutError(`Request timeout after ${this.timeout}ms`, fullURL);
                }
                // 网络错误（断网、DNS 失败等）
                if (error.message.includes('fetch') || error.message.includes('network')) {
                    throw new NetworkError(error.message, fullURL);
                }
                throw error;
            }
        };

        // 重试逻辑
        let lastError;
        for (let i = 0; i < this.retries; i++) {
            try {
                return await executeRequest();
            } catch (error) {
                lastError = error;
                // 只有网络错误和超时才重试，4xx 错误重试也没用
                if (error instanceof HTTPError && error.status >= 400 && error.status < 500) {
                    throw error;
                }
                // 延迟重试，别猛冲
                if (i < this.retries - 1) {
                    await this.delay(1000 * (i + 1)); // 指数退避
                }
            }
        }

        // 重试用完了还是失败，上报错误
        this.reportError(lastError, {
            url: fullURL,
            method: options.method || 'GET',
            attemptCount,
            duration: performance.now() - startTime
        });
        throw lastError;
    }

    logPerformance(url, duration, status) {
        // 发送到性能监控，可以用来做 SLI
        if (window.performanceObserver) {
            // 或者用自己的上报逻辑
            console.log(`[Performance] ${url}: ${duration.toFixed(2)}ms, status: ${status}`);
        }
    }

    reportError(error, context) {
        const errorInfo = {
            type: 'NETWORK_ERROR',
            errorType: error.constructor.name,
            message: error.message,
            url: context.url,
            method: context.method,
            attemptCount: context.attemptCount,
            duration: context.duration,
            userAgent: navigator.userAgent,
            // 网络状况，这个很有用
            connection: navigator.connection ? {
                effectiveType: navigator.connection.effectiveType, // 4g/3g/2g
                downlink: navigator.connection.downlink,
                rtt: navigator.connection.rtt
            } : 'unknown'
        };
        reportError(errorInfo);
    }

    delay(ms) {
        return new Promise(resolve => setTimeout(resolve, ms));
    }
}

// 自定义错误类型，方便区分
class HTTPError extends Error {
    constructor(message, status, url) {
        super(message);
        this.name = 'HTTPError';
        this.status = status;
        this.url = url;
    }
}

class TimeoutError extends Error {
    constructor(message, url) {
        super(message);
        this.name = 'TimeoutError';
        this.url = url;
    }
}

class NetworkError extends Error {
    constructor(message, url) {
        super(message);
        this.name = 'NetworkError';
        this.url = url;
    }
}

// 使用示例
const api = new MonitoredFetch({
    baseURL: 'https://api.example.com',
    timeout: 5000,
    retries: 2
});

// 调用的时候就像普通 fetch 一样，但背后有监控和重试
api.request('/user/profile').then(res => res.json()).then(data => console.log(data)).catch(err => {
    // 这里拿到的错误已经是分类好的，可以针对性处理
    if (err instanceof TimeoutError) {
        showToast('网络太慢了，请检查网络或稍后再试');
    } else if (err instanceof NetworkError) {
        showToast('网络好像断了，看看 WiFi 是不是没连');
    }
});

看到没，网络监控不只是记个错，还得把当时的网络环境、重试次数、耗时都记下来。这样你排查问题的时候才能还原现场，而不是对着"请求失败"四个字发呆。

SourceMap 这玩意儿，真的是救命稻草

生产环境的代码都是压缩过的，报错信息长这样：at t.e (app.abc123.js:1:2345)。你看着这一堆 a.b.c，根本不知道是哪个文件哪行代码。这时候 SourceMap 就是你的救命稻草。

但 SourceMap 怎么用，这里面有讲究。你不能直接把 SourceMap 文件扔到生产环境，因为那样等于把源码公开了（虽然可以配置只映射到行不映射到列，但还是能反推个大概）。所以通常的做法是：

1. 构建时生成 SourceMap，但不上传到 CDN
2. 把 SourceMap 文件存到内部服务器或者 Sentry 这种错误监控平台
3. 线上报错时，用监控平台保存的 SourceMap 来还原堆栈

// webpack 配置示例，怎么生成 SourceMap
// webpack.config.js
module.exports = {
    // 生产环境用这个，生成单独的 map 文件，但不包含源码（只映射行列）
    devtool: 'hidden-source-map',
    // 或者用这个，更安全，只映射到行，不映射到列，反编译难度大一些
    // devtool: 'nosources-source-map',
    output: {
        filename: '[name].[contenthash].js',
        // 很重要：sourceMapFilename 要配置好
        sourceMapFilename: 'sourcemaps/[name].[contenthash].js.map'
    }
};

// 如果你用 Vite
// vite.config.js
export default {
    build: {
        sourcemap: 'hidden', // 生成但不引用
        // 或者
        // sourcemap: true, // 开发时用
    }
};

然后在错误监控服务里，你需要实现一个堆栈还原的功能。如果你用 Sentry，它自动就做了。如果自己实现，大概长这样：

// 简化的堆栈还原逻辑，实际要用 source-map 库
const { SourceMapConsumer } = require('source-map');

async function unminifyStackTrace(stackTrace, sourceMapContent) {
    const consumer = await new SourceMapConsumer(sourceMapContent);
    const lines = stackTrace.split('\n');
    const unminifiedLines = lines.map(line => {
        // 解析压缩后的位置，比如 "at t.e (app.abc123.js:1:2345)"
        const match = line.match(/at\s+(.+?)\s+\((.+):(\d+):(\d+)\)/);
        if (!match) return line;
        const [, funcName, fileName, lineNum, colNum] = match;
        // 用 SourceMap 还原
        const originalPosition = consumer.originalPositionFor({
            line: parseInt(lineNum),
            column: parseInt(colNum)
        });
        if (originalPosition.source) {
            return `at ${originalPosition.name || funcName} (${originalPosition.source}:${originalPosition.line}:${originalPosition.column})`;
        }
        return line;
    });
    consumer.destroy();
    return unminifiedLines.join('\n');
}

// 使用示例
const minifiedStack = "at t.e (app.abc123.js:1:2345)\nat n.r (app.abc123.js:1:5678)";
const sourceMap = fs.readFileSync('./app.abc123.js.map', 'utf8');
unminifyStackTrace(minifiedStack, sourceMap).then(originalStack => console.log(originalStack));
// 输出：at handleClick (src/components/Button.tsx:45:12)\nat render (src/App.tsx:123:8)

还原报错现场，得像侦探小说一样精彩

光知道哪行代码错了还不够，你得知道当时用户干了啥、页面啥状态、网络啥情况。这就需要"录屏"功能——不是真的录视频，而是记录用户操作和页面变化。

// 简化的用户行为录屏实现，用 rrweb 的思路
class SessionRecorder {
    constructor(options = {}) {
        this.events = [];
        this.maxEvents = options.maxEvents || 1000; // 限制数量，别撑爆内存
        this.isRecording = false;
    }

    start() {
        if (this.isRecording) return;
        this.isRecording = true;
        // 记录初始 DOM 状态
        this.recordEvent({
            type: 'init',
            timestamp: Date.now(),
            // 这里应该序列化 DOM，简化示例就记个 URL
            url: window.location.href,
            viewport: {
                width: window.innerWidth,
                height: window.innerHeight
            },
            userAgent: navigator.userAgent
        });

        // 监听点击
        this.clickHandler = (e) => {
            this.recordEvent({
                type: 'click',
                timestamp: Date.now(),
                target: this.describeElement(e.target),
                x: e.clientX,
                y: e.clientY
            });
        };
        document.addEventListener('click', this.clickHandler, true);

        // 监听输入
        this.inputHandler = (e) => {
            if (e.target.tagName === 'INPUT' || e.target.tagName === 'TEXTAREA') {
                this.recordEvent({
                    type: 'input',
                    timestamp: Date.now(),
                    target: this.describeElement(e.target),
                    // 注意：密码框不能记值，隐私保护
                    value: e.target.type === 'password' ? '***' : e.target.value.substring(0, 100) // 截断，别记太长
                });
            }
        };
        document.addEventListener('input', this.inputHandler, true);

        // 监听页面跳转
        this.popstateHandler = () => {
            this.recordEvent({
                type: 'navigation',
                timestamp: Date.now(),
                url: window.location.href
            });
        };
        window.addEventListener('popstate', this.popstateHandler);

        // 定时记录性能数据
        this.performanceInterval = setInterval(() => {
            this.recordEvent({
                type: 'performance',
                timestamp: Date.now(),
                memory: performance.memory ? {
                    usedJSHeapSize: performance.memory.usedJSHeapSize,
                    totalJSHeapSize: performance.memory.totalJSHeapSize
                } : null,
                // 长任务（阻塞主线程超过 50ms 的任务）
                longTasks: this.getLongTasks()
            });
        }, 5000);
    }

    describeElement(element) {
        // 给元素一个可读描述，比如 "button#submit.primary-btn"
        const tag = element.tagName.toLowerCase();
        const id = element.id ? `#${element.id}` : '';
        const classes = element.className && typeof element.className === 'string' ? `.${element.className.split(' ').join('.')}` : '';
        const text = element.textContent ? element.textContent.substring(0, 50) : '';
        return `${tag}${id}${classes}${text ? ` "${text}"` : ''}`;
    }

    getLongTasks() {
        // 需要 PerformanceObserver 支持
        if (!window.PerformanceObserver) return [];
        // 实际实现要维护一个列表，这里简化
        return [];
    }

    recordEvent(event) {
        if (this.events.length >= this.maxEvents) {
            this.events.shift(); // 满了就丢最老的，保持滑动窗口
        }
        this.events.push(event);
    }

    getContextForError() {
        return {
            recentEvents: this.events.slice(-50), // 报错前最近 50 个操作
            timestamp: Date.now()
        };
    }

    stop() {
        this.isRecording = false;
        document.removeEventListener('click', this.clickHandler, true);
        document.removeEventListener('input', this.inputHandler, true);
        window.removeEventListener('popstate', this.popstateHandler);
        clearInterval(this.performanceInterval);
    }
}

// 使用示例
const recorder = new SessionRecorder({ maxEvents: 500 });
recorder.start();

// 报错时
window.addEventListener('error', (e) => {
    const context = recorder.getContextForError();
    reportError({
        message: e.message,
        stack: e.error?.stack,
        // 带上用户操作上下文
        userActions: context.recentEvents,
        // 还可以带上 DOM 快照（如果用了 rrweb 的话）
        domSnapshot: captureDOMSnapshot()
    });
});

这种"录屏"数据配合错误堆栈，你排查问题的时候就跟看监控录像似的，用户点了哪、输入了啥、页面怎么变的，一目了然。但要注意隐私合规，密码、身份证号这些敏感信息一定要脱敏。

埋点策略得有讲究，别把用户浏览器卡死

监控代码本身不能成为性能瓶颈。我见过有团队为了"全量监控"，在每个函数开头结尾都插桩，结果主线程直接堵死，页面卡顿得要命。

// 错误的示范：这种写法，函数多了直接卡爆
function heavyFunction() {
    monitor.startTrack('heavyFunction');
    // 这里可能有 DOM 操作，阻塞渲染
    // ... 业务逻辑
    monitor.endTrack('heavyFunction');
}

// 正确的姿势：采样 + 异步上报
class SmartMonitor {
    constructor(options = {}) {
        this.sampleRate = options.sampleRate || 0.1; // 只监控 10% 的请求
        this.batchSize = options.batchSize || 10; // 批量上报，攒够 10 条发一次
        this.buffer = [];
        this.flushInterval = options.flushInterval || 5000; // 最多 5 秒发一次
        this.isSending = false;
        // 定时刷新
        setInterval(() => this.flush(), this.flushInterval);
        // 页面关闭前强制发送（用 sendBeacon，可靠）
        window.addEventListener('beforeunload', () => this.flush(true));
    }

    track(event) {
        // 采样：不是所有事件都记
        if (Math.random() > this.sampleRate) return;
        this.buffer.push({ ...event, timestamp: Date.now() });
        // 攒够一批就发，但用 requestIdleCallback，别卡主线程
        if (this.buffer.length >= this.batchSize) {
            if (window.requestIdleCallback) {
                requestIdleCallback(() => this.flush(), { timeout: 2000 });
            } else {
                setTimeout(() => this.flush(), 0); // 降级
            }
        }
    }

    flush(isBeacon = false) {
        if (this.buffer.length === 0 || this.isSending) return;
        this.isSending = true;
        const data = [...this.buffer]; // 拷贝一份
        this.buffer = []; // 清空缓存

        if (isBeacon && navigator.sendBeacon) {
            // 页面关闭时用 sendBeacon，可靠但大小有限制（通常 64KB）
            const blob = new Blob([JSON.stringify(data)], { type: 'application/json' });
            navigator.sendBeacon('/monitor/collect', blob);
            this.isSending = false;
        } else {
            // 普通 fetch 上报
            fetch('/monitor/collect', {
                method: 'POST',
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify(data),
                keepalive: true // 页面关闭后也尽量发完
            }).catch(err => {
                // 上报失败，存回 buffer 下次再试，但别无限增长
                if (this.buffer.length < 100) {
                    this.buffer.unshift(...data);
                }
            }).finally(() => {
                this.isSending = false;
            });
        }
    }
}

// 使用：性能开销极小
const monitor = new SmartMonitor({ sampleRate: 0.1 });
function businessLogic() {
    monitor.track({ type: 'function_start', name: 'businessLogic' });
    // ... 业务代码
    monitor.track({ type: 'function_end', name: 'businessLogic', duration: 123 });
}

关键点：采样（别全量）、批量（别一条条发）、异步（别卡主线程）、降级（sendBeacon）。这样监控代码对性能的影响可以忽略不计。

这招好用是好用，但副作用你也得心里有数

监控这东西，用好了是神器，用不好就是给自己挖坑。我见过太多团队监控搞得太激进，结果问题没解决，先制造了一堆新问题。

监控代码太猛，主线程直接堵死

前面说了性能优化，但还有些更隐蔽的坑。比如有些监控库为了"精确计时"，用 performance.now() 在每次 DOM 操作前后打戳，结果频繁的时钟查询本身就成为性能瓶颈。

还有些库为了获取"完整的错误上下文"，在报错时遍历整个 DOM 树，序列化成字符串。如果页面很大（比如那种无限滚动的长列表），这一下就能卡死好几秒。

// 危险操作：报错时遍历整个 DOM
function getFullDOMContext() {
    return document.documentElement.outerHTML; // 大页面这里直接爆炸，内存和 CPU 双杀
}

// 相对安全的做法：只取关键元素
function getSafeContext() {
    const context = {
        url: window.location.href,
        viewport: {
            width: window.innerWidth,
            height: window.innerHeight
        },
        // 只取 body 的直接子元素数量，判断页面复杂度
        bodyChildrenCount: document.body.children.length,
        // 当前聚焦的元素
        activeElement: document.activeElement?.tagName,
        // 滚动位置
        scrollY: window.scrollY
    };
    return context;
}

另外，监控代码本身也可能报错。比如你想记录 navigator.connection 的网络状态，但某些浏览器不支持这个 API，直接抛错。所以监控代码里要再套 try-catch，形成"监控的监控"：

// 防御性编程：监控代码也要被保护
function safeMonitor(fn) {
    return function (...args) {
        try {
            return fn.apply(this, args);
        } catch (e) {
            // 监控代码出错，至少别影响业务
            console.error('Monitor error:', e);
            // 甚至可以上报"监控器故障"，但小心死循环
            if (window.__monitorFailed) {
                window.__monitorFailed = true;
                // 简化版的上报，避免再用复杂的监控逻辑
                fetch('/monitor/self-error', {
                    method: 'POST',
                    body: JSON.stringify({ error: e.message }),
                    keepalive: true
                });
            }
        }
    };
}

// 包装所有监控方法
const originalTrack = monitor.track;
monitor.track = safeMonitor(originalTrack);

海量报错数据，服务器账单比你工资涨得还快

如果你不做采样和聚合，生产环境的海量报错能把你的监控服务冲垮。想象一下，一个 bug 影响了 10 万用户，每人触发 10 次，这就是 100 万条错误日志。存起来、索引起来、查询起来，都是钱。

所以一定要有分级和聚合策略：

// 错误聚合：相同的错误只记一次，但记次数
class ErrorAggregator {
    constructor() {
        this.errorMap = new Map(); // 用 Map 做内存中的聚合
        this.flushInterval = 60000; // 1 分钟同步一次
        setInterval(() => this.syncToServer(), this.flushInterval);
    }

    // 生成错误指纹，用来判断是不是同一个错误
    getFingerprint(error) {
        const stack = error.stack || '';
        const stackLines = stack.split('\n').slice(0, 3);
        // 用正则去掉具体的行号列号，只保留函数名和文件名
        const normalizedStack = stackLines.map(line =>
            line.replace(/:\d+:\d+/g, '') // 去掉:12:34 这种
        ).join('|');
        // 加上错误类型和消息
        return `${error.name}:${error.message}:${normalizedStack}`;
    }

    report(error, context = {}) {
        const fingerprint = this.getFingerprint(error);
        const now = Date.now();
        if (this.errorMap.has(fingerprint)) {
            // 已存在的错误，增加计数
            const record = this.errorMap.get(fingerprint);
            record.count++;
            record.lastTime = now;
            // 保留最近几个用户的上下文，用于复现
            if (record.samples.length < 5) {
                record.samples.push(context);
            }
        } else {
            // 新错误
            this.errorMap.set(fingerprint, {
                fingerprint,
                name: error.name,
                message: error.message,
                stack: error.stack,
                firstTime: now,
                lastTime: now,
                count: 1,
                samples: [context]
            });
        }
    }

    syncToServer() {
        if (this.errorMap.size === 0) return;
        const errors = Array.from(this.errorMap.values());
        this.errorMap.clear(); // 清空内存
        // 批量上报聚合后的错误
        fetch('/monitor/aggregated-errors', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({
                timestamp: Date.now(),
                errors: errors,
                // 加上聚合统计
                totalErrors: errors.reduce((sum, e) => sum + e.count, 0),
                uniqueErrors: errors.length
            })
        });
    }
}

// 使用
const aggregator = new ErrorAggregator();
window.addEventListener('error', (e) => {
    aggregator.report(e.error, {
        url: window.location.href,
        userId: getCurrentUserId() // 如果有的话
    });
});

这样你存的不是 100 万条重复记录，而是几百条聚合记录，每条带个计数器。查询的时候也能一眼看出哪个错误影响面最大。

误报率太高，狼来了的故事听多了

如果监控太敏感，一堆无关紧要的警告会把真正的 P0 级错误淹没。比如第三方脚本的小错误、浏览器插件注入的代码错误、用户网络不稳定导致的请求失败，这些如果都报上来，团队很快就麻木了。

// 错误过滤策略
function shouldReportError(error) {
    // 1. 过滤掉已知的无害错误（比如某些浏览器扩展的锅）
    const knownHarmlessPatterns = [
        /ResizeObserver loop limit exceeded/, // Chrome 的 benign error
        /Script error\.?/, // 跨域脚本错误，信息太少，通常处理不了
        /Non-Error promise rejection captured/ // 某些框架的警告
    ];
    for (const pattern of knownHarmlessPatterns) {
        if (pattern.test(error.message)) return false;
    }

    // 2. 过滤掉第三方脚本的错误（如果你确定不管）
    if (error.stack) {
        const isThirdParty = error.stack.split('\n').some(line =>
            line.includes('chrome-extension://') ||
            line.includes('moz-extension://') ||
            line.includes('https://third-party-analytics.com')
        );
        if (isThirdParty) return false;
    }

    // 3. 只报自己域名的错误
    const isOwnDomain = error.stack && error.stack.includes(window.location.hostname);
    if (!isOwnDomain) return false;
    // 谨慎开启，可能会漏掉 CDN 资源的错误

    // 4. 采样：高频错误降低采样率
    const fingerprint = getFingerprint(error);
    const count = getRecentErrorCount(fingerprint); // 需要维护一个计数
    if (count > 100) { // 这个错误已经出现 100 次以上了，只采样 10%
        return Math.random() < 0.1;
    }
    return true;
}

// 上报前检查
window.addEventListener('error', (e) => {
    if (!shouldReportError(e.error)) return;
    reportError(e.error);
});

过滤策略要持续维护，根据线上实际情况调整。定期 review 错误列表，把那些"无害但 noisy"的错误加入黑名单。

真到了生产环境，这套组合拳该怎么打

监控搭好了，怎么用是个学问。不能所有错误都一视同仁，得有分级处理机制。

分级处理才是王道

错误得分级，就像医院分急诊和门诊一样。有些错误记下来就行，有些得立即通知，有些得直接触发回滚。

// 错误分级系统
class ErrorSeverityClassifier {
    classify(error, context = {}) {
        // P0：核心流程阻断，必须立即处理
        if (this.isP0Error(error, context)) {
            return {
                level: 'P0',
                action: 'immediate_alert', // 立即电话/短信通知
                autoRollback: true, // 考虑自动回滚
                notifyChannels: ['pagerduty', 'slack', 'email']
            };
        }
        // P1：重要功能受损，15 分钟内响应
        if (this.isP1Error(error, context)) {
            return {
                level: 'P1',
                action: 'urgent_alert',
                responseTime: 15 * 60 * 1000, // 15 分钟
                notifyChannels: ['slack', 'email']
            };
        }
        // P2：次要功能问题，当天处理
        if (this.isP2Error(error, context)) {
            return {
                level: 'P2',
                action: 'daily_digest', // 日报汇总
                notifyChannels: ['email']
            };
        }
        // P3：轻微问题，周会 review
        return {
            level: 'P3',
            action: 'weekly_review',
            notifyChannels: []
        };
    }

    isP0Error(error, context) {
        // 支付流程报错
        if (context.pageType === 'checkout' && error.message.includes('payment')) {
            return true;
        }
        // 核心 API 持续 500 错误
        if (context.apiPath?.includes('/api/core') && context.httpStatus >= 500) {
            // 而且错误率超过阈值
            if (context.errorRate > 0.1) return true; // 10% 的请求失败
        }
        // 白屏错误（渲染层崩溃）
        if (error.message?.includes('render') || error.message?.includes('mount')) {
            if (context.isWhiteScreen) return true;
        }
        return false;
    }

    isP1Error(error, context) {
        // 登录注册流程
        if (context.pageType === 'login' || context.pageType === 'signup') {
            return true;
        }
        // 用户数据加载失败
        if (error.message?.includes('user profile')) return true;
        return false;
    }

    isP2Error(error, context) {
        // 非核心功能，比如推荐算法挂了
        if (context.pageType === 'recommendation') return true;
        // 单个图片加载失败
        if (error.type === 'RESOURCE_ERROR' && error.resourceType === 'image') {
            return true;
        }
        return false;
    }
}

// 自动回滚逻辑（需要配合 CI/CD）
async function autoRollback(errorInfo) {
    // 只有 P0 错误且持续 5 分钟以上才触发
    if (errorInfo.level !== 'P0') return;
    const recentErrors = await getRecentP0Errors(5 * 60 * 1000); // 最近 5 分钟
    if (recentErrors.length < 10) return; // 错误数不够，可能是偶发

    // 触发回滚
    console.error('🚨 触发自动回滚！');
    // 调用 CI/CD API 回滚到上一个版本
    fetch('/deploy/rollback', {
        method: 'POST',
        headers: { 'Authorization': 'Bearer ' + DEPLOY_TOKEN },
        body: JSON.stringify({
            reason: `Auto-rollback due to P0 error: ${errorInfo.message}`,
            targetVersion: 'previous-stable'
        })
    });
    // 通知团队
    notifyTeam({
        type: 'AUTO_ROLLBACK_TRIGGERED',
        error: errorInfo,
        timestamp: Date.now()
    });
}

分级策略要根据业务特点定制。电商网站的支付错误是 P0，内容网站的推荐算法错误可能就是 P2。这个得和团队一起梳理清楚。

优雅的降级方案，让页面"瘸腿"也能跑

现代前端都是 SPA，一个组件挂了可能导致整个页面白屏。这时候得有降级策略，让页面"瘸腿"也能跑。

// React 的错误边界示例，但思路适用于所有框架
import React from 'react';

class ErrorBoundary extends React.Component {
    constructor(props) {
        super(props);
        this.state = { hasError: false, error: null };
    }

    static getDerivedStateFromError(error) {
        // 下次渲染显示降级 UI
        return { hasError: true, error };
    }

    componentDidCatch(error, errorInfo) {
        // 上报错误
        reportError({
            error: error,
            componentStack: errorInfo.componentStack,
            componentName: this.props.componentName || 'unknown'
        });
        // 根据错误类型决定降级策略
        if (this.props.critical) {
            // 关键组件，整个页面降级
            this.setState({ fallbackType: 'fullPage' });
        } else {
            // 非关键组件，只降级这个组件
            this.setState({ fallbackType: 'component' });
        }
    }

    render() {
        if (this.state.hasError) {
            // 根据 fallbackType 显示不同的降级 UI
            if (this.state.fallbackType === 'fullPage') {
                return (
                    <div className="error-page">
                        <h1>页面出了点小问题</h1>
                        <p>我们的技术团队已经收到通知，正在紧急修复</p>
                        <button onClick={() => window.location.reload()}>刷新试试</button>
                        {/* 甚至可以提供"简化版"入口 */}
                        <a href="/lite-version">访问简化版</a>
                    </div>
                );
            }
            // 组件级降级
            return (
                <div className="component-error-fallback">
                    <p>这部分内容加载失败</p>
                    <button onClick={() => this.setState({ hasError: false })}>重试</button>
                </div>
            );
        }
        return this.props.children;
    }
}

// 使用：给关键页面包一层
function ProductPage() {
    return (
        <ErrorBoundary critical componentName="ProductPage">
            <ProductDetail />
            <RelatedProducts />
        </ErrorBoundary>
    );
}

// 给非关键组件单独包
function Sidebar() {
    return (
        <ErrorBoundary componentName="Sidebar">
            <Recommendations />
        </ErrorBoundary>
    );
}

对于非 React 项目，可以用类似的思路：

// Vue3 的错误处理
app.config.errorHandler = (err, instance, info) => {
    console.error('Vue Error:', err);
    // 上报
    reportError({
        error: err,
        component: instance?.$options?.name || 'anonymous',
        info: info // 比如 "render function"
    });
    // 根据严重程度决定要不要 toast 提示用户
    if (isCriticalError(err)) {
        showGlobalError('页面出现严重错误，建议刷新');
    }
};

// 或者更细粒度的，在组件内
export default {
    name: 'SafeComponent',
    methods: {
        riskyOperation() {
            try {
                // 可能出错的操作
            } catch (e) {
                // 捕获并处理，不让错误冒泡
                this.handleError(e);
            }
        }
    },
    errorCaptured(err, instance, info) {
        // 捕获子组件错误
        console.log('子组件出错:', err);
        return false; // 返回 false 阻止错误继续传播
    }
};

配合 CI/CD，把低级错误扼杀在摇篮里

监控是最后一道防线，更好的办法是在代码提交前就发现问题。配合 CI/CD 流水线，可以自动跑异常模拟测试。

// Cypress E2E 测试示例，模拟各种异常情况
describe('异常场景测试', () => {
    it('应该优雅处理 API 500 错误', () => {
        // 拦截 API 请求，强制返回 500
        cy.intercept('GET', '/api/user/profile', {
            statusCode: 500,
            body: { error: 'Internal Server Error' }
        }).as('getProfile');
        cy.visit('/profile');
        cy.wait('@getProfile');
        // 验证页面没有白屏，显示了错误提示
        cy.get('[data-testid="error-toast"]').should('be.visible');
        cy.get('[data-testid="retry-button"]').should('be.enabled');
    });

    it('应该处理网络超时', () => {
        // 让请求永远 pending，模拟超时
        cy.intercept('GET', '/api/slow-endpoint', (req) => {
            // 不回复，让请求超时
        }).as('slowRequest');
        cy.visit('/slow-page');
        // 等待超时时间（比如 5 秒）
        cy.wait(5000);
        // 验证显示了超时提示
        cy.contains('请求超时').should('be.visible');
    });

    it('应该处理 JS 运行时错误', () => {
        // 故意制造一个 JS 错误
        cy.visit('/test-page');
        cy.window().then((win) => {
            win.eval('setTimeout(() => { throw new Error("Test error"); }, 100)');
        });
        // 验证错误边界捕获了错误，页面没有崩溃
        cy.get('body').should('not.have.class', 'white-screen');
        cy.get('[data-testid="error-boundary"]').should('be.visible');
    });

    it('应该处理资源加载失败', () => {
        // 拦截图片请求，返回 404
        cy.intercept('GET', '**/*.jpg', { statusCode: 404 }).as('image404');
        cy.visit('/gallery');
        cy.wait('@image404');
        // 验证显示了兜底图或者错误占位符
        cy.get('img').each(($img) => {
            // 检查 onerror 是否被触发，图片是否被替换为兜底图
            cy.wrap($img).should('have.attr', 'src').and('include', 'fallback');
        });
    });
});

// 在 CI 中跑这些测试
// .github/workflows/test.yml
/*
name: E2E Tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Cypress run
        uses: cypress-io/github-action@v4
        with:
          start: npm start
          wait-on: 'http://localhost:3000'
*/

这些自动化测试能帮你发现"明显会崩"的场景。虽然不能覆盖所有错误，但至少能保证核心流程在异常情况下不挂。

遇到那种"在我本地明明是好的"玄学问题咋整

最烦人的就是这种玄学问题。本地好好的，一上线就崩；测试环境没问题，生产环境就报错。这时候怎么排查？

复现不了是最耍流氓的，教你几招顺藤摸瓜

首先，得有足够的上下文。用户 ID、时间戳、浏览器版本、操作系统，这些基础信息必须有。

// 增强版错误上报，带上丰富的上下文
function getRichContext() {
    return {
        // 用户标识（脱敏）
        userId: getUserId(), // 或者匿名 ID
        sessionId: getSessionId(),
        // 时间信息
        timestamp: Date.now(),
        timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
        // 浏览器环境
        userAgent: navigator.userAgent,
        viewport: {
            width: window.innerWidth,
            height: window.innerHeight
        },
        screen: {
            width: screen.width,
            height: screen.height,
            colorDepth: screen.colorDepth
        },
        devicePixelRatio: window.devicePixelRatio,
        // 网络状况
        connection: navigator.connection ? {
            effectiveType: navigator.connection.effectiveType,
            downlink: navigator.connection.downlink,
            rtt: navigator.connection.rtt,
            saveData: navigator.connection.saveData // 用户是否开启了省流量模式
        } : null,
        online: navigator.onLine,
        // 页面状态
        url: window.location.href,
        referrer: document.referrer,
        visibilityState: document.visibilityState, // 报错时页面是否在前台
        // 性能指标（如果可用）
        performance: {
            // 页面加载时间
            loadTime: performance.timing ? performance.timing.loadEventEnd - performance.timing.navigationStart : null,
            // DOM 内容加载时间
            domContentLoaded: performance.timing ? performance.timing.domContentLoadedEventEnd - performance.timing.navigationStart : null,
            // 内存使用（Chrome only）
            memory: performance.memory ? {
                usedJSHeapSize: performance.memory.usedJSHeapSize,
                totalJSHeapSize: performance.memory.totalJSHeapSize,
                jsHeapSizeLimit: performance.memory.jsHeapSizeLimit
            } : null
        },
        // 已加载的资源（用来排查资源加载顺序问题）
        resources: performance.getEntriesByType ? performance.getEntriesByType('resource').slice(-20).map(r => ({
            name: r.name,
            duration: r.duration,
            initiatorType: r.initiatorType
        })) : [],
        // 全局状态（如果你用 Redux/Vuex）
        storeState: getReduxState ? sanitizeState(getReduxState()) : null,
        // 最近的 console 日志（需要提前劫持 console 方法）
        recentLogs: getRecentConsoleLogs()
    };
}

// 劫持 console，记录最近的日志
const recentLogs = [];
const MAX_LOGS = 50;
['log', 'warn', 'error', 'info'].forEach(method => {
    const original = console[method];
    console[method] = function (...args) {
        recentLogs.push({
            method,
            args: args.map(arg => {
                // 简化序列化，避免循环引用
                try {
                    return typeof arg === 'object' ? JSON.stringify(arg).substring(0, 200) : String(arg);
                } catch (e) {
                    return '[unserializable]';
                }
            }),
            timestamp: Date.now()
        });
        if (recentLogs.length > MAX_LOGS) {
            recentLogs.shift();
        }
        return original.apply(this, args);
    };
});

function getRecentConsoleLogs() {
    return recentLogs;
}

// 上报时带上这些上下文
window.addEventListener('error', (e) => {
    reportError({
        error: {
            message: e.message,
            stack: e.error?.stack
        },
        context: getRichContext()
    });
});

有了这些信息，你可以按用户 ID 查日志，看他在报错前都干了啥。也可以按时间戳聚合，看是不是某个时间点集中爆发（可能是 CDN 节点问题、服务器发布问题）。

偶发的内存泄漏，怎么像抓鬼一样揪出来

内存泄漏最难搞，因为它不会立即报错，而是让页面越来越卡，最后崩溃。而且本地开发时通常不会长时间运行，很难发现。

// 内存监控工具
class MemoryLeakDetector {
    constructor() {
        this.measurements = [];
        this.checkInterval = 30000; // 30 秒检查一次
        this.growthThreshold = 1.5; // 内存增长超过 50% 就报警
        this.startMonitoring();
    }

    startMonitoring() {
        if (!performance.memory) {
            console.warn('当前浏览器不支持内存监控');
            return;
        }
        setInterval(() => this.checkMemory(), this.checkInterval);
    }

    checkMemory() {
        const memory = performance.memory;
        const usedMB = memory.usedJSHeapSize / 1048576;
        const totalMB = memory.totalJSHeapSize / 1048576;
        this.measurements.push({
            timestamp: Date.now(),
            usedMB: usedMB,
            totalMB: totalMB,
            url: window.location.href // 记录当前页面，SPA 可能切换路由
        });
        // 只保留最近 20 个测量点
        if (this.measurements.length > 20) {
            this.measurements.shift();
        }
        // 分析趋势
        this.analyzeTrend();
    }

    analyzeTrend() {
        if (this.measurements.length < 5) return;
        // 计算最近 5 个点的平均增长率
        const recent = this.measurements.slice(-5);
        const first = recent[0].usedMB;
        const last = recent[4].usedMB;
        const growth = last / first;
        if (growth > this.growthThreshold) {
            // 内存快速增长，可能泄漏
            this.reportLeak({
                growthFactor: growth,
                startMB: first,
                endMB: last,
                measurements: recent,
                // 尝试获取堆快照（需要 Chrome DevTools 协议，生产环境通常不行）
                // 但可以记录当前的 DOM 节点数作为参考
                domNodes: document.getElementsByTagName('*').length,
                eventListeners: this.getEventListenerCount() // 粗略估计
            });
        }
    }

    getEventListenerCount() {
        // 这个很难精确获取，但可以通过 hack 的方式估计
        // 实际生产环境建议用 WeakRef 和 FinalizationRegistry 来跟踪对象
        return 'estimated';
    }

    reportLeak(details) {
        reportError({
            type: 'MEMORY_LEAK_DETECTED',
            severity: 'warning',
            details: details,
            suggestion: '页面内存持续增长，可能存在泄漏，建议检查定时器、事件监听、DOM 引用'
        });
        // 如果增长太夸张，提示用户刷新（避免崩溃）
        if (details.growthFactor > 3) {
            showToast('页面运行时间较长，建议刷新以获得最佳体验');
        }
    }
}

// 使用
const leakDetector = new MemoryLeakDetector();

更专业的做法是用 Chrome 的 Performance 面板手动分析，但生产环境你没法让用户帮你开 DevTools。所以这种自动监控是必要的补充。

第三方脚本挂了怎么办？沙箱隔离和超时熔断

现在的网站都依赖一堆第三方脚本：统计、广告、客服、支付……这些脚本如果挂了，可能拖慢甚至拖垮你的页面。

// 第三方脚本加载管理器
class ThirdPartyManager {
    constructor() {
        this.scripts = new Map();
        this.timeouts = {
            'analytics': 5000, // 统计脚本 5 秒超时
            'chat-widget': 10000, // 客服组件 10 秒
            'payment': 15000 // 支付脚本 15 秒，这个重要可以多等会儿
        };
    }

    async loadScript(name, url, options = {}) {
        const timeout = options.timeout || this.timeouts[name] || 5000;
        return new Promise((resolve, reject) => {
            const script = document.createElement('script');
            script.src = url;
            script.async = true;

            // 超时熔断
            const timer = setTimeout(() => {
                script.remove();
                this.scripts.set(name, { status: 'timeout', loadedAt: null });
                reject(new Error(`Script ${name} load timeout after ${timeout}ms`));
            }, timeout);

            script.onload = () => {
                clearTimeout(timer);
                this.scripts.set(name, { status: 'loaded', loadedAt: Date.now() });
                resolve(script);
            };

            script.onerror = () => {
                clearTimeout(timer);
                this.scripts.set(name, { status: 'error', loadedAt: null });
                reject(new Error(`Script ${name} load failed`));
            };

            // 沙箱隔离：用 iframe 加载特别危险的脚本（可选，看安全需求）
            if (options.sandbox) {
                this.loadInSandbox(name, url, resolve, reject);
            } else {
                document.head.appendChild(script);
            }
        }).catch(err => {
            // 第三方脚本失败不影响主流程
            console.warn(`第三方脚本 ${name} 加载失败:`, err);
            reportError({
                type: 'THIRD_PARTY_ERROR',
                scriptName: name,
                error: err.message
            });
            return null; // 返回 null 表示加载失败，但业务代码继续跑
        });
    }

    loadInSandbox(name, url, resolve, reject) {
        // 创建隐藏 iframe 作为沙箱
        const iframe = document.createElement('iframe');
        iframe.style.display = 'none';
        iframe.sandbox = 'allow-scripts allow-same-origin'; // 限制权限
        iframe.onload = () => {
            const iframeDoc = iframe.contentDocument;
            const script = iframeDoc.createElement('script');
            script.src = url;
            script.onload = () => resolve(iframe);
            script.onerror = () => reject(new Error('Sandboxed script failed'));
            iframeDoc.head.appendChild(script);
        };
        document.body.appendChild(iframe);
    }

    // 检查某个脚本是否可用
    isAvailable(name) {
        const script = this.scripts.get(name);
        return script && script.status === 'loaded';
    }
}

// 使用示例
const tpm = new ThirdPartyManager();

// 加载非关键脚本，失败也无所谓
tpm.loadScript('analytics', 'https://analytics.example.com/track.js', {
    timeout: 3000 // 统计脚本 3 秒没加载完就放弃，别拖慢页面
});

// 加载关键脚本（比如支付），但也要有超时
tpm.loadScript('payment', 'https://payment.example.com/sdk.js', {
    timeout: 10000
}).then(() => {
    // 初始化支付组件
    initPayment();
}).catch(() => {
    // 支付脚本加载失败，显示降级提示
    showPaymentFallback();
});

// 业务代码里检查可用性
function trackEvent(event) {
    if (tpm.isAvailable('analytics')) {
        window.analytics.track(event); // 假设第三方脚本全局暴露了方法
    } else {
        // 脚本不可用，存到本地队列，等它加载了再补发，或者直接丢弃
        console.log('Analytics not ready, dropping event:', event);
    }
}

关键点：超时熔断（别无限等）、失败降级（别阻塞主流程）、可选加载（非关键脚本可以没有）。这样第三方脚本挂了，你的页面还能正常跑。

面对用户截图里那个模糊不清的报错，怎么引导他们提供有价值的信息

有时候用户反馈问题，就给你一张模糊的截图，上面半个错误信息。这时候怎么引导他们提供有用的信息？

首先，你的错误页面本身要设计得能提供信息：

<!-- 友好的错误页面，带诊断信息 -->
<div class="error-container">
    <h1>哎呀，出错了</h1>
    <p>我们已经记录了这个问题，技术团队正在处理</p>
    <!-- 给高级用户的诊断信息 -->
    <details class="diagnostics">
        <summary>技术详情（点击展开，反馈给客服时有用）</summary>
        <div class="error-code">
            <p>错误 ID: <span id="error-id">ERR-20240315-ABC123</span></p>
            <p>时间：<span id="error-time">2024-03-15 14:32:01</span></p>
            <p>页面：<span id="error-page">/checkout/payment</span></p>
            <button onclick="copyDiagnostics()">复制诊断信息</button>
        </div>
    </details>
    <div class="actions">
        <button onclick="location.reload()">刷新页面</button>
        <button onclick="contactSupport()">联系客服</button>
    </div>
</div>
<script>
// 生成错误 ID，方便后续追踪
function generateErrorId() {
    return 'ERR-' + new Date().toISOString().slice(0, 10).replace(/-/g, '') + '-' + Math.random().toString(36).substring(2, 8).toUpperCase();
}

// 把诊断信息复制到剪贴板，方便用户粘贴给客服
function copyDiagnostics() {
    const info = {
        errorId: document.getElementById('error-id').textContent,
        time: document.getElementById('error-time').textContent,
        page: document.getElementById('error-page').textContent,
        userAgent: navigator.userAgent
        // 还可以加更多
    };
    navigator.clipboard.writeText(JSON.stringify(info, null, 2)).then(() => alert()).( ());
}


({
    : .().,
    
});
</script>

其次，客服话术要培训好。别问"你遇到什么问题"这种开放式问题，要问"错误 ID 是多少"、"报错时你在哪个页面"、"有没有看到红色的错误提示"。

几个让你少加班的野路子技巧

说了这么多监控和排查的，最好的错误处理是不出错。这里分享几个从源头减少错误的野路子。

TypeScript 把类型检查做到极致

别只是把 TS 当 JS 用，要利用它的严格模式。

// tsconfig.json 严格配置
{
    "compilerOptions": {
        "strict": true, // 开启所有严格选项
        "noImplicitAny": true, // 禁止隐式 any
        "strictNullChecks": true, // 严格检查 null/undefined
        "noUncheckedIndexedAccess": true, // 索引访问可能 undefined
        "exactOptionalPropertyTypes": true, // 区分 undefined 和可选属性
        "noImplicitReturns": true, // 函数所有分支必须有返回值
        "noFallthroughCasesInSwitch": true, // switch case 必须有 break
        "noUncheckedSideEffectImports": true // 检查副作用导入
    }
}

// 实际例子：严格类型能避免一堆运行时错误
// 不好的写法：隐式 any，后面调用时不知道有没有这个方法
function processData(data) {
    return data.map(item => item.name); // 如果 data 不是数组，这里就炸
}

// 好的写法：明确类型，编译时就发现问题
interface User {
    id: number;
    name: string;
    email: string;
}
function processData(data: User[]): string[] {
    // TS 会保证 data 是数组，item 有 name 属性
    return data.map(item => item.name);
}

// 更严格的：处理边界情况
function safeProcessData(data: User[] | undefined | null): string[] {
    // 开启 strictNullChecks 后，必须处理 undefined/null
    if (!data) {
        return []; // 或者抛出错误，但至少显式处理了
    }
    // 开启 noUncheckedIndexedAccess 后，连数组索引都要检查
    const first = data[0];
    if (first) {
        // 必须检查，因为 data[0] 可能是 undefined
        console.log(first.name);
    }
    return data.map(item => item.name);
}

// 用 branded type 防止 ID 混淆
type UserId = string & { __brand: 'UserId' };
type OrderId = string & { __brand: 'OrderId' };

function getUser(id: UserId) { ... }
function getOrder(id: OrderId) { ... }

const userId = '123' as UserId;
const orderId = '456' as OrderId;

getUser(userId); // OK
getUser(orderId); // 编译错误！不能混用

TS 的学习曲线是陡，但用好了能消灭一半的低级错误。特别是严格 null 检查，能把"Cannot read property of undefined"这种错误在编译期就干掉。

单元测试别偷懒，边界条件才是重灾区

写测试别只测"正常情况"，要测边界：空数组、undefined、极大值、网络超时。

// Jest 测试示例，重点测边界
import { processOrder, calculateDiscount } from './order';

describe('processOrder', () => {
    // 正常情况
    it('应该正确处理正常订单', () => {
        const order = { items: [{ price: 100, quantity: 2 }], coupon: 'SAVE20' };
        expect(processOrder(order)).toEqual({ total: 200, discount: 40, final: 160 });
    });

    // 边界：空数组
    it('应该处理空购物车', () => {
        const order = { items: [] };
        expect(processOrder(order)).toEqual({ total: 0, discount: 0, final: 0 });
    });

    // 边界：undefined 输入
    it('应该处理 undefined 输入', () => {
        expect(processOrder(undefined)).toThrow('Invalid order data'); // 或者返回默认值，看业务需求
    });

    // 边界：价格或数量为 0/负数
    it('应该拒绝无效的价格', () => {
        const order = { items: [{ price: -100, quantity: 1 }] };
        expect(() => processOrder(order)).toThrow('Invalid price');
    });

    // 边界：极大值（防止溢出）
    it('应该处理极大金额', () => {
        const order = { items: [{ price: Number.MAX_SAFE_INTEGER, quantity: 2 }] };
        // 应该抛出溢出错误或者用 BigInt 处理
        expect(() => processOrder(order)).toThrow('Amount overflow');
    });

    // 异步错误
    it('应该处理 API 超时', async () => {
        jest.useFakeTimers();
        const promise = processOrderWithAPI({ items: [] });
        jest.advanceTimersByTime(10000); // 快进 10 秒
        await expect(promise).rejects.toThrow('Request timeout');
        jest.useRealTimers();
    });
});

// 用属性测试（Property-based testing）发现边界情况
// 用 fast-check 库
import fc from 'fast-check';

describe('calculateDiscount', () => {
    it('折扣不应该超过原价', () => {
        fc.assert(
            fc.property(
                fc.integer({ min: 0, max: 100000 }), // 随机价格
                fc.float({ min: 0, max: 1 }), // 随机折扣率
                (price, rate) => {
                    const discount = calculateDiscount(price, rate);
                    return discount <= price && discount >= 0;
                }
            )
        );
    });
});

测试覆盖率要追求，但更重要的是覆盖场景。100% 覆盖率但只测了正常路径，不如 80% 覆盖率但边界都测到了。

团队规矩：谁搞出 P0 事故谁请喝奶茶

技术之外，管理手段也很重要。我们团队有个规矩：谁提交的代码导致线上 P0 事故（核心功能挂了、大量用户受影响），谁请全组喝奶茶。

这招比 Code Review 好使多了。Code Review 大家还容易敷衍，"LGTM"（Looks Good To Me）就过了。但想到可能要请 20 个人喝奶茶，Review 的时候眼睛都瞪大了，每一行都仔细看。

而且出了事故不惩罚，只是请喝奶茶，氛围比较轻松。大家复盘的时候也不会互相甩锅，而是真的想怎么避免下次再犯。毕竟谁都有手滑的时候，但同一个错误犯两次就真说不过去了。

我们还配合一个"事故日记"，每次 P0 事故都记录下来：什么时候发生的、什么原因、怎么修复、怎么预防。新员工入职先看这个日记，了解团队的"黑历史"，也学习排查问题的思路。

下次再看到红色报错别心慌，甚至想笑

说了这么多，其实想传达一个心态：bug 是写出来的，不是测出来的。只要代码在变，bug 就在路上。重要的不是追求零 bug（那不可能），而是建立一套体系，让 bug 的影响可控、可快速修复、可从中学习。

我现在看到 Sentry 的报警邮件，第一反应已经不是"卧槽又出事了"，而是"让我看看这次是什么新鲜玩意儿"。毕竟处理过的错误类型越多，排查新问题的速度就越快。而且很多错误看着吓人，其实就是个边界条件没处理好，改两行代码就完事。

记住，没有完美的系统，只有永远在修 Bug 的路上狂奔的我们。今晚能不能睡个安稳觉，就看你这波监控搭得稳不稳、降级方案设计得合理不合理、团队配合默不默契了。

不过说真的，自从我们把监控体系搭完善之后，凌晨三点的电话确实少多了。现在偶尔响一次，我甚至有点怀念那种肾上腺素飙升的感觉——毕竟，这才是前端工程师的"浪漫"啊（不是）。

好了，该说的都说了，去检查下你的 Sentry 配置吧，别等会儿电话真响了。☕