JavaScript错误上报：收集前端调用DDColor API的异常数据
在构建面向大众的老照片修复工具时，一个看似简单的“上传→上色→下载”流程背后，往往隐藏着大量潜在的技术风险。用户上传一张模糊的黑白旧照，点击“智能修复”，却迟迟得不到结果——这种体验上的断裂，很少是单一环节的问题，而往往是前端与AI模型交互过程中多个微小异常累积的结果。
尤其是在使用像 DDColor 这类高性能图像着色模型时，尽管其在色彩还原和细节保留方面表现出色，但一旦集成到 ComfyUI 这样的可视化工作流平台中，前端调用过程就变得复杂且脆弱。输入尺寸不符、参数配置错误、网络中断、跨域限制……这些都可能让整个流程静默失败，而用户甚至不会意识到问题出在哪里。
更棘手的是，很多这类错误并不会导致页面崩溃，也不会触发明显的报错提示，而是以“请求超时”或“无响应”的形式悄然发生。如果缺乏有效的监控机制，开发团队将长期处于“盲人摸象”的状态，只能被动等待用户反馈才能发现问题。这显然无法满足现代 AI 应用对稳定性和可维护性的基本要求。
于是，我们不得不面对这样一个现实：再强大的模型，也需要同样强大的可观测性来支撑。而在这其中，JavaScript 错误上报机制，正是打通前端“黑盒”的关键钥匙。
DDColor 作为近年来表现突出的黑白图像彩色化模型，基于扩散模型架构，在人物肤色、织物纹理和建筑材质的还原上展现出远超传统 GAN 方法的真实感。它通常部署于后端推理服务，并通过 RESTful 接口暴露给前端调用。在 ComfyUI 中，这一过程被进一步封装为可视化节点，用户只需拖拽即可完成图像修复任务，无需编写任何代码。
但正因如此低门槛的设计，反而放大了前端容错的压力。普通用户并不了解“推荐输入尺寸为 460x680”这样的技术细节，他们只会上传任意大小的照片，甚至可能是 PDF 文件或损坏的图片。此时，前端不仅要处理正常的业务逻辑，还必须具备足够的韧性去捕获并应对各种边界情况。
例如，当用户上传一张 2000px 宽的老旧扫描图时，系统可能会因为超出模型最大输入限制而导致 GPU 内存溢出；又或者在移动端弱网环境下，/api/run请求尚未完成，用户已关闭页面，导致调试信息丢失。这些问题若不加以记录，便难以复现和优化。
因此，我们在实现功能的同时，也必须建立一套完整的前端异常采集体系。核心思路是：将每一次 API 调用视为一次可观测事件，无论成功与否，都要留下痕迹。
来看一个典型的调用场景：
async function runDDColorWorkflow(imageFile, modelType = 'person') { const formData = new FormData(); formData.append('image', imageFile); try { // 步骤1：上传图像到 ComfyUI const uploadResponse = await fetch('/upload/image', { method: 'POST', body: formData }); if (!uploadResponse.ok) throw new Error(`Upload failed: ${uploadResponse.statusText}`); const result = await uploadResponse.json(); const imagePath = result.name; // 步骤2：加载对应工作流模板 const workflowPath = modelType === 'building' ? 'DDColor建筑黑白修复.json' : 'DDColor人物黑白修复.json'; const workflowRes = await fetch(`/workflows/${workflowPath}`); const workflowData = await workflowRes.json(); // 修改图像路径和模型参数 workflowData['3'].inputs.image = imagePath; workflowData['6'].inputs.width = modelType === 'building' ? 1280 : 680; workflowData['6'].inputs.height = modelType === 'building' ? 960 : 460; // 步骤3：提交工作流执行请求 const execResponse = await fetch('/api/run', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(workflowData) }); if (!execResponse.ok) throw new Error(`Execution failed: ${execResponse.statusText}`); console.log('DDColor workflow started successfully.'); } catch (error) { reportErrorToServer({ type: 'DDCOLOR_API_ERROR', message: error.message, stack: error.stack, timestamp: new Date().toISOString(), userAgent: navigator.userAgent, url: window.location.href, extra: { modelType, fileName: imageFile.name } }); } }这个函数封装了从图像上传到工作流执行的完整链路。值得注意的是，所有异常都被集中捕获并通过reportErrorToServer()上报。这一点至关重要——它确保了即使是最轻微的接口 400 错误，也能被系统感知。
然而，仅靠try-catch是不够的。JavaScript 的异步特性决定了还有很多异常发生在我们的掌控之外。比如未被await的 Promise 拒绝、动态脚本加载失败、甚至是浏览器兼容性问题引发的语法错误。这些都需要通过全局监听器来覆盖。
为此，我们需要注册一系列全局错误处理器：
function initErrorReporting() { // 捕获未捕获的运行时错误 window.onerror = function(message, source, lineno, colno, error) { reportErrorToServer({ type: 'RUNTIME_ERROR', message, source, lineno, colno, stack: error?.stack || 'No stack trace', url: location.href, userAgent: navigator.userAgent, timestamp: Date.now() }); return true; // 阻止默认弹窗 }; // 捕获未处理的 Promise 异常 window.addEventListener('unhandledrejection', function(event) { reportErrorToServer({ type: 'PROMISE_REJECTION', reason: event.reason?.message || String(event.reason), stack: event.reason?.stack || 'No stack', url: location.href, timestamp: Date.now() }); event.preventDefault(); }); // 捕获资源加载失败 window.addEventListener('error', function(e) { const target = e.target; if (target instanceof HTMLImageElement || target instanceof HTMLScriptElement || target instanceof HTMLLinkElement) { reportErrorToServer({ type: 'RESOURCE_LOAD_ERROR', src: target.src || target.href, tagName: target.tagName, url: location.href, timestamp: Date.now() }); } }, true); } // 上报函数（使用 sendBeacon 保证页面卸载时仍可发送） function reportErrorToServer(errorData) { const payload = JSON.stringify(errorData); if (navigator.sendBeacon) { navigator.sendBeacon('/api/log-error', payload); } else { fetch('/api/log-error', { method: 'POST', body: payload, keepalive: true, headers: { 'Content-Type': 'application/json' } }).catch(() => { /* 忽略上报失败 */ }); } } initErrorReporting();这套机制的设计有几个关键考量点：
- 全面性：不仅捕获显式抛出的异常，还包括 Promise 拒绝、资源加载失败等隐性错误；
- 可靠性：优先使用
navigator.sendBeacon，该 API 能在页面卸载后继续发送请求，避免因用户快速关闭页面而导致日志丢失； - 非侵入性：上报过程完全异步，不影响主流程性能，也不会造成额外卡顿；
- 上下文丰富：每条错误都附带时间戳、URL、UserAgent、堆栈信息以及自定义扩展字段，便于后续分析定位。
实际运行中，这套系统帮助我们发现了许多意料之外的问题。例如某次上线后发现移动端修复成功率显著下降，通过错误日志分析才发现是 iOS Safari 对大于 1MB 的 Blob 对象存在内存限制，导致图像上传失败。若无自动上报，这个问题可能要数周后才会被察觉。
当然，错误上报不是越多越好。我们也需要考虑隐私合规与数据治理的问题。原则上：
- 不采集用户身份信息；
- 不记录文件内容本身；
- 对敏感路径做脱敏处理；
- 设置采样率防止高频重复错误刷爆日志系统。
此外，还可以结合本地缓存机制，在离线状态下暂存错误日志，待网络恢复后再批量补传，进一步提升数据完整性。
从架构上看，整个系统的数据流动清晰可追溯：
[用户浏览器] ↓ [ComfyUI 前端] ←→ [JS 错误监控模块] ↓ [ComfyUI 后端] ↓ [DDColor 推理引擎 (GPU)] ↓ [结果返回 + 日志入库]前端作为第一道防线，承担着异常捕获的核心职责。而后端则根据上报的日志进行聚合分析，识别高频失败模式，进而推动模型优化或前端策略调整。例如，当我们发现大量“图像尺寸过大”的错误时，就可以在前端增加预检逻辑，提前提示用户裁剪或压缩图片。
最终，这种“智能模型 + 可视化流程 + 稳定监控”的三位一体设计，不仅提升了系统的鲁棒性，也为产品迭代提供了宝贵的数据支持。每一次失败都不再是沉默的损耗，而是转化为改进的动力。
在处理老照片这类承载情感价值的内容时，系统的稳定性本身就是用户体验的一部分。没有人愿意看到祖辈的合影在修复途中莫名消失。而通过精细化的错误上报机制，我们可以做到：即便失败，也要知道为何失败。
这种对细节的掌控力，才是构建值得信赖的 AI 应用的真正基石。
