把小程序/收银前端错误接进 Sentry：上报就要“能定位”
商家端最怕的不是报错，而是“用户说卡住了，你看不到堆栈”。Sentry 在2026年的常规做法是：前端 SDK 负责上报，打好Release，再用sourcemap把压缩后的代码还原成可读堆栈，配合告警规则把高频问题拎出来。
一个真实场景：收银台高峰期每小时2000单，只要“支付按钮点击无响应”在10分钟内出现30次，就该自动通知到值班群，而不是等门店打电话。
接入方式：小程序和收银系统两条线
微信小程序（推荐 sentry-miniapp）
搜索结果提到小程序可以用sentry-miniapp SDK。接入后重点是把用户上下文带上，方便按门店/设备筛。
- 关键字段：store_id（门店）、device_id（设备）、cashier_id（收银员）、network（网络类型）
- 采样建议：只对“支付/退款/开票”这类核心链路提高采样，普通页面维持低采样，避免噪音
收银系统 Web 前端（JS SDK）
网页收银台用 Sentry JavaScript SDK，务必启用错误捕获和性能追踪的基础配置。更重要的是：每次发布都带 release，否则你只能看到“minified 报错”，排查会非常痛。
Release 标记 + sourcemap：把“1行报错”变成“具体文件第几行”
2026年常见链路是：构建时注入release=版本号，然后用sentry-cli上传 sourcemap。这样 Sentry 才能把线上压缩堆栈映射回源码。
- Release 命名：建议用“业务名+日期+构建号”，例如 cashier-web@2026.05.11+1024
- 上传点：CI 构建产物生成后立即上传 sourcemap，并把同一个 release 写进前端初始化配置
- 验证方法：在 Sentry 找到一条新错误，堆栈能直接跳到源码文件和行号，说明映射成功
告警规则与堆栈排查：让问题自动“找人”
Sentry 在 Alerts 配置里常用两类：Issue Alerts（问题告警）和Metric Alerts（指标告警）。商家应用更实用的是“按影响面”触发。
- 建议规则1：10分钟内同一错误触发≥20次，通知到收银值班群
- 建议规则2：影响用户数≥5（或门店数≥3），直接升级到负责人
- 建议规则3：支付/退款页面的错误出现就提高优先级（用 tag 或路由匹配）
定位时按这个顺序看更快：Release 是否集中（判断是否回归）→ 受影响门店/设备是否集中（判断环境）→ 堆栈顶层函数和面包屑（breadcrumb）→ 复现路径（点击序列、接口失败、权限问题）。如果你发现错误只在某个 release 出现，回滚或热修的决策会很干脆。
可执行建议：今天就做三件事——给小程序/收银端都加上 store_id、device_id 等 tags；把 release 固定写进构建流程并用 sentry-cli 上传 sourcemap；在 Alerts 里落地一条“10分钟20次+支付链路加权”的告警规则。做完这三步，门店再说“点不了”，你基本能在5分钟内看到原因。
