Sentry 映射到源码以后，还缺什么才能判断根因？

告警里的app.js:1:8421映射到了price.ts:42，排障只前进了一步。那一行可能是读取失败的地方，真正的问题可能来自上游响应、旧缓存、错误状态顺序，或另一次部署的产物错配。

Source map 解决生成代码与源代码位置的关联。AST 可以帮助理解目标表达式。它们都不会单凭一行源码证明“是谁引入了根因”，更不支持承诺秒级定界与固定倍数的恢复提速。

同名文件为什么会骗人

假设上午与下午都部署了app.js，两次内容不同。用文件名去找“最近上传的 map”，可能得到一个看似合理却属于另一次构建的源位置。即使错误行能显示，也可能把调查带到错误提交。

Sentry 2025 年 3 月 28 日的 Debug ID 文章解释了构建产物与 source map 的关联思路。这是旧资料，不能包装成 2026 年 10 月新发布；当前 SDK、构建器和上传工具的具体配置仍要按锁定版本核查。Debug ID 也不是所有上下文的替代品：部署、提交、环境、受影响资源仍需记录。

先检查身份，再让 AI 看上下文

下面的例子不解析真实 source map，只检查自建证据清单。它展示一个必要前置条件：事件、生成文件与 map 的构建身份必须一致。清单必须来自受控构建过程，不能由告警发送者随意填写。

保存为artifact-check.mjs，执行node artifact-check.mjs：

import assert from "node:assert/strict"; const artifacts = new Map([ ["build-a", { commit: "commit-a", debugId: "debug-a", mapDebugId: "debug-a" }], ["build-b", { commit: "commit-b", debugId: "debug-b", mapDebugId: "debug-b" }] ]); function evidenceFor(event, manifest) { if (!event || typeof event.buildId !== "string") return { status: "invalid-event" }; const artifact = manifest.get(event.buildId); if (!artifact) return { status: "missing-artifact" }; if (event.debugId !== artifact.debugId || artifact.mapDebugId !== artifact.debugId) return { status: "identity-mismatch" }; return { status: "ready-for-symbolication", commit: artifact.commit }; } assert.equal(evidenceFor({ buildId: "build-a", debugId: "debug-a" }, artifacts).commit, "commit-a"); assert.equal(evidenceFor({ buildId: "build-a", debugId: "debug-b" }, artifacts).status, "identity-mismatch"); assert.equal(evidenceFor({ buildId: "missing", debugId: "debug-a" }, artifacts).status, "missing-artifact"); const badMap = new Map([["build-a", { ...artifacts.get("build-a"), mapDebugId: "debug-b" }]]); assert.equal(evidenceFor({ buildId: "build-a", debugId: "debug-a" }, badMap).status, "identity-mismatch"); assert.equal(evidenceFor(null, artifacts).status, "invalid-event"); console.log("artifact identity fixtures passed; no real source map parsed");

通过清单校验，仍只意味着可以继续做符号化。实际链路还要测试 map 缺失、错误列偏移、内联资源、不同压缩配置等情况，确认工具还原结果。本文没有接入 Sentry，也没有上传任何项目源码。

上下文采集也有边界

从告警里收到的路径不能直接拼成 shell 命令。应先从允许的构建 ID 查受控产物目录，再做真实路径校验、文件类型与大小限制。读取 Git 内容时使用固定命令和参数数组；不要执行模型或告警文本提供的命令。软链接逃逸也需要检查，不能只判断字符串前缀。

给模型的材料应围绕问题：脱敏后的栈、最少响应字段、状态转移和对应提交。Cookie、访问令牌、用户原始输入、完整仓库都不是默认附件。若缺信息，模型应产出可验证的假设，而不是把猜测写成“根因已确定”。

把一句猜测变成一个会失败的测试

例如异常是product.price读取失败。至少有三种不同假设：响应确实缺 product；UI 在请求完成前读取；组件切换后旧请求回写新状态。它们可能命中同一行，却需要不同的修复。

复现要让旧版本在目标断言上失败，再让补丁通过同一断言；只有语法错误、依赖缺失或测试环境崩溃，不算复现业务故障。修复后还要验证相邻路径，避免用一个空值兜底把真实的价格缺失悄悄变成零元展示。

Playwright 的自动重试断言适合等待可观察状态，不应以固定等待时间代替行为断言。本轮外部依赖安装尚未获准，未运行 Playwright；浏览器交互与真实符号化仍待执行。已运行的仅是上面的身份清单测试，不能据此宣称定位耗时或恢复时间。

发布前应补齐：事件与产物匹配证据、受影响范围、复现输入、旧失败与新通过记录、未覆盖设备。参考资料：Sentry Debug IDs，2025-03-28；Playwright 断言，滚动文档。10 月 25 日尚未发生，本文没有当日事故或生产战果。