Worker 错误日志优化关键在于结构化、带上下文、可联动：统一 onerror 捕获并 postMessage 上报；注入 traceId 等任务上下文；JSON 格式输出固定字段；关联主线程日志构建故障链。
优化 Worker 线程内的错误日志分析，关键不是堆更多日志，而是让每条日志自带上下文、可定位、可联动。Worker 本身隔离运行，异常默认不透出、无堆栈、难复现，所以日志必须“一次写对”，才能支撑快速归因。
统一捕获入口，避免静默崩溃
Worker 默认不会把异常通知主线程，onerror 是唯一可靠的全局兜底机制，但需主动启用并配合 postMessage 主动上报。
- 在 Worker 脚本顶部立即注册 onerror，不要依赖 try-catch 包裹全部逻辑（容易漏掉定时器、事件回调等异步路径）
- onerror 回调中必须提取 event.message、event.filename、event.lineno、event.stack，并通过 postMessage 发送结构化对象，例如：
{ type: 'WORKER_ERROR', timestamp: Date.now(), payload: { ... } } - 主线程需对应监听 message 事件，过滤 type === 'WORKER_ERROR'，并统一记录到应用级错误日志系统（而非仅 console.error）
注入请求/任务上下文，解决“日志散、线索断”问题
单条 Worker 日志缺乏调用链信息，无法判断是哪个用户操作、哪次请求触发的异常。必须在初始化或接收消息时注入上下文。
- 主线程创建 Worker 后，首次 postMessage 时附带 traceId、taskId、userId 等字段；Worker 收到后存入闭包变量或 WeakMap，后续所有日志都自动带上这些字段
- 对批量任务（如数据处理循环），为每个子任务生成 subTaskId，并在日志中显式标注，避免“某次循环失败但不知第几轮”
- 避免用 Date.now() 或 Math.random() 生成 ID——应使用主线程统一分发的、可跨线程追踪的标识
结构化输出，适配 OpenClaw 等分析工具
非结构化日志（如纯字符串 console.log）无法被 OpenClaw 自动提取关键字段，必须按约定格式输出。
- 所有 error 日志统一用 JSON 字符串格式输出，例如：
console.error(JSON.stringify({ level: 'ERROR', code: 'PARSE_FAILED', field: 'timestamp', value: '2026-06-24T02:19:00Z' })) - 定义固定字段：level、code（业务错误码）、module（所属模块名）、cause（根因简述）、stack（截断后的前 3 行堆栈）
- 避免日志混杂调试信息与错误信息——用不同 level 区分，OpenClaw 可基于 level 和 code 快速归类重复报错
关联主线程日志，构建完整故障链
Worker 异常往往只是表象，真正根因可能在主线程参数传入错误、资源加载失败或通信超时。必须打通两端日志。
- 主线程在发送消息前打一条 “SEND_TO_WORKER” 日志，含相同 traceId 和 payload 摘要；Worker 收到后打 “RECEIVED_FROM_MAIN” 日志，也带 traceId
- 错误发生时，OpenClaw 可根据 traceId 自动串联主线程初始化日志、通信日志、Worker 内部日志，识别是“传参为空”还是“Worker 解析逻辑缺陷”
- 对高频 Worker（如打点、加密、渲染预处理），建立“Worker 实例 ID → 创建时间 → 主线程调用栈”映射表，便于回溯特定实例生命周期
