微前端架构下子应用Lambda异常堆栈混入主应用日志是因未归因而非污染；需通过打标（APP_ID/trace ID）、结构化日志、通道隔离（CloudWatch订阅过滤）及事件化上报（CloudWatch Events+S3）实现精准溯源与可观测性提升。
微前端本身是前端架构模式，不直接涉及后端 Lambda；但若主应用通过 API 网关调用多个子应用对应的 Lambda 服务（即“前端微前端 + 后端微服务”混合架构），那么子应用 Lambda 的异常堆栈确实可能混入主应用日志流，造成日志污染、排查困难、告警失真。
核心问题定位：日志不是“被污染”，而是“未归因”
Lambda 默认将错误日志输出到 CloudWatch Logs，而主应用（如 Node.js Express 或 NestJS）若统一收集所有下游响应日志，又未对来源做标记，就会把 子应用 A 的 500 错误堆栈 和 主应用自身的业务日志 混在同一个日志组或同一行中。这不是技术污染，而是日志元信息缺失。
关键防护手段：从源头打标、通道隔离、结构化归因
-
为每个子应用 Lambda 显式注入唯一标识：在 Lambda 环境变量中设置
APP_ID=order-service、ENV=prod，并在所有日志语句前缀自动拼接：[order-service/prod]。Node.js 示例：console.error(`[order-service/prod] Failed to fetch user: ${err.stack}`); -
主应用调用层强制日志上下文透传：主应用在调用子应用 Lambda 前，生成唯一 trace ID（如
trace-7a2f9e1c），通过 HTTP Header（X-Trace-ID）透传；Lambda 接收后将其写入每条日志，确保主子链路可串联。 -
禁止主应用原样 dump Lambda 响应体日志：主应用收到 Lambda 的 5xx 响应时，不应
console.error(JSON.stringify(resp))，而应提取结构化字段：
– 错误码（resp.statusCode）
– 子应用标识（resp.headers['X-App-ID']）
– 简明错误消息（resp.body.message）
– trace ID（resp.headers['X-Trace-ID']）
再格式化为单行日志：[MAIN] downstream call failed: app=order-service, code=502, trace=trace-7a2f9e1c, msg="timeout" -
利用 CloudWatch Logs Insights 做日志路由分流：配置订阅过滤器（Subscription Filter），将含
[order-service/]前缀的日志自动转发至专属日志组/aws/lambda/order-service-errors，与主应用日志组物理隔离。
增强可观测性：避免堆栈“淹没”，转为可检索事件
不要让完整堆栈出现在主应用日志中，而是将其作为独立事件上报：
- Lambda 在捕获异常后，主动调用
CloudWatch Events PutEvents发送结构化错误事件，包含：app_id、error_type、stack_summary（仅首 3 行）、full_stack_s3_uri（完整堆栈上传至 S3 加密存储） - 主应用日志中只记录事件 ID 和简要摘要，运维人员可通过事件 ID 快速拉取原始堆栈，避免日志流被长文本拖慢或截断
