文章给出了一个经典的实战案例：用户反馈某页面打开缓慢，怀疑是 API 慢。整个排查流程展示了端到端 Trace 的价值。第一步：在云监控2.0用户体验监控的 API 请求模块按"缓慢占比"排序，迅速定位到 /java/products 接口平均耗时高达 40 多秒。第二步：点击"查看调用链"，从链路瀑布图直接看到从移动端到后端的完整链路，确认耗时主要发生在后端 /products 接口，并记录 Trace ID c7f332f53a9f42ffa21ef6c92f029c15。第三步：进入应用监控，使用 Trace ID 查询，发现后端执行了 6 次 SELECT postgres.products，总耗时 42.3 秒，平均每次约 8 秒。第四步：点击 Span 查看 SQL，发现是 SELECT * FROM products 后对每个产品再循环执行 SELECT * FROM reviews, weekly_promotions 的典型 N+1 查询问题，加上 weekly_promotions 是"慢视图"，导致总耗时超过 40 秒。第五步：通过持续性能剖析的 Profile 数据验证，发现 sun.nio.ch.Net.poll 占比接近 100%，证实线程一直在等待 Postgres 数据返回，与分析结论完全吻合。
