fix: 撤回省 CPU hack，恢复 best practice（dashboard 数据修订诊断）

用户 review 后指出"丢西瓜捡芝麻"风险，复盘 Vercel 30 天 dashboard 后修订：

## 真实根因（不是 /_not-found）

dashboard 30 天曲线显示 5/11 CPU 峰值 80-90min（基线 5-15min/day），完美
对应 SEO PR 落地时间：
- 5/11 15:01-15:39 UTC: PR #341 (253 MDX descriptions + 32 新 EN 翻译)
- 5/11 16:02-18:41 UTC: PR #342 (remark heading shift + leetcode dedup)
- 5/11 19:01-19:27 UTC: PR #343 + #340，4 小时 4 次 deploy 清空 ISR

加上 deploy.yml 里 IndexNow 主动告诉 Bing 重抓 → 5/10-5/12 crawler 风暴。
**这是 SEO 工作 successful 的代价，不是 bug。** 真实流量。

/_not-found 静态化 + bot blocklist 是真实 waste 清理（保留），但不能独立
解释 4× 激增。

## 撤回的两条 hack

1. Sentry tracesSampleRate 0.1 → 0.02：撤回，保持 10%
   observability 不能为这点 CPU 让步，10% 是行业标准，client/server/edge
   三处必须一致才能跨 runtime 串联 trace。

2. fetchEvents 失败一律返空：改成只在 NEXT_PHASE === phase-production-build
   时返空，运行时仍 throw 让 Sentry 抓真故障。否则 prod backend 挂了会被
   误显示成"暂无活动"，掩盖故障。

## 保留的修复（best practice，不是 hack）

- /_not-found ƒ → ○：根 404 本就不需要 i18n
- proxy.ts bot blocklist：扫描器不该烧 Fluid
- /[locale]/docs /events /login 缺 setRequestLocale → 补：SSG/ISR 本就该工作
- /editor /share cascade ●：纯 client component，安全

## Build 验证

pnpm build 重跑：
- /[locale]/events 仍是 ● ISR 5m 1y
- [events] fetch failed at build, rendering empty shell（NEXT_PHASE guard 工作）

Author: github-actions[bot]

app/[locale]/events/page.tsx

@@ -30,15 +30,24 @@ interface ApiResponse<T> {
   message?: string;
 }
 
+/**
+ * 在 build 阶段才允许"后端不可达就降级返空"。Next 16 用 NEXT_PHASE 标记
+ * phase-production-build，build 时返空让 generateStaticParams 能跑完不挂；
+ * 运行时仍然 throw，Sentry / 错误页才能感知真故障，不至于把 prod backend
+ * 挂了误显示成"暂无活动"。
+ */
+const IS_BUILD = process.env.NEXT_PHASE === "phase-production-build";
+
 async function fetchEvents(): Promise<EventView[]> {
   const backendUrl = process.env.BACKEND_URL;
-  // 改成"失败降级返回空"而非 throw：build 时 SSG（generateStaticParams 触发预渲染）
-  // 如果后端不可达，throw 会让整次 build 失败。返回空数组让页面 build 出"暂无活动"
-  // 的静态壳，等 revalidate=300 到点后台刷新拿到真数据。
-  // 同步好处：Vercel CF 偶发挡 build IP / 后端临时挂时不再 break deploy。
   if (!backendUrl) {
-    console.warn("[events] BACKEND_URL not set, rendering empty list");
-    return [];
+    if (IS_BUILD) {
+      console.warn(
+        "[events] BACKEND_URL not set at build, rendering empty shell; ISR will fetch real data after deploy",
+      );
+      return [];
+    }
+    throw new Error("BACKEND_URL is not configured");
   }
   try {
     const res = await fetch(`${backendUrl}/api/events`, {
@@ -49,16 +58,26 @@ async function fetchEvents(): Promise<EventView[]> {
       },
     });
     if (!res.ok) {
-      console.warn(
-        `[events] backend ${res.status} ${res.statusText}, rendering empty list`,
-      );
-      return [];
+      if (IS_BUILD) {
+        console.warn(
+          `[events] backend ${res.status} at build, rendering empty shell`,
+        );
+        return [];
+      }
+      throw new Error(`/api/events backend ${res.status} ${res.statusText}`);
     }
     const json = (await res.json()) as ApiResponse<EventView[]>;
     return json.success && json.data ? json.data : [];
   } catch (err) {
-    console.warn("[events] fetch failed, rendering empty list:", err);
-    return [];
+    if (IS_BUILD) {
+      console.warn(
+        "[events] fetch failed at build, rendering empty shell:",
+        err,
+      );
+      return [];
+    }
+    // 运行时失败仍然 throw —— Sentry 抓到，错误页正常显示，不掩盖故障
+    throw err;
   }
 }
 

dev_docs/vercel-cpu-overage-2026-05.md

@@ -4,12 +4,30 @@
 > Fast Origin Transfer 12.04 GB / 10 GB（120%）。用户报告"之前做过 SSR
 > 优化但情况更糟"。本文档记录调查方法、根因、修复、验证手段。
 
-## TL;DR
+## TL;DR（看完 Vercel dashboard 30 天图表后的修订诊断）
 
-之前的 SSG 优化（2026-05-06 commit `8517332`）**只翻转了 1 条路由**（/[locale]
-首页）。`next build` 输出显示**还剩 18 条 ƒ Dynamic**，其中最致命的是
-`/_not-found`：所有漏洞扫描器（.env / wp-admin / php-info / graphql）和真实
-404 全落到这条 dynamic 路由。
+**真正的元凶**：5/11 一天里 PR #341（253 MDX descriptions backfill + 32 新 EN
+翻译页）+ PR #342（remark h1 plugin）+ PR #343（escape-angles）连续 4 次
+deploy。每次 deploy 自动 ping IndexNow → Bing/Google 5/10-5/12 大规模重抓 +
+索引 32 个新 URL。Dashboard 30 天曲线显示 5/11 CPU 峰值 80-90min（pre-spike
+基线 5-15min/day），完美对应 SEO PR 落地时间。
+
+**这是 SEO 工作 successful 的代价，不是 bug**。流量是真实的搜索引擎 + 真实
+用户增长，付费 Pro plan 阈值就是这么到的。
+
+**本 PR 做的事是真实 waste 的清理**（不是 hack）：
+
+- `/_not-found` 之前是 ƒ Dynamic（每条 scanner 都烧 Fluid）→ ○ Static
+- `proxy.ts` 加 bot path 早返 404，scanner 不再进 Fluid
+- `/[locale]/docs` `/events` `/login` 缺 setRequestLocale 导致退回 dynamic →
+  补上 + generateStaticParams 让 SSG/ISR 真正工作
+
+**撤回的"省 CPU hack"（写完才意识到丢了西瓜）**：
+
+- ~~Sentry tracesSampleRate 0.1 → 0.02~~：保持 10%。observability 不能为这
+  点 CPU 让步，10% 是行业标准
+- ~~fetchEvents 失败一律返空~~：改成只在 `NEXT_PHASE === "phase-production-build"`
+  时返空，运行时仍然 throw 让 Sentry 抓到真故障
 
 本次修复在 `next build` 输出层面把 6 条路由从 ƒ 翻成 ● / ○：
 
@@ -152,16 +170,33 @@ x-vercel-cache: HIT    # ← CDN 命中
 age: 142
 ```
 
-### H3：Sentry tracesSampleRate 0.1（10%）叠在每次调用上
+### H3：~~Sentry tracesSampleRate 0.1 → 0.02~~（撤回）
+
+最初打算改 10% → 2% 省 CPU。CR 后撤回——Sentry trace 在 30 天 CPU 占比远不及
+crawler 流量，2% 省的是芝麻丢的是西瓜（observability）。10% 是行业标准，
+client/server/edge 三处必须一致才能跨 runtime 串联请求链路。
+
+**结论**：保持 0.1，不动 Sentry config。
+
+### H4：dashboard 数据让根因更清晰（SEO 重抓风暴）
+
+补观察后修订：
 
-**证据**：`sentry.server.config.ts:23` 和 `sentry.edge.config.ts:18` 都写
-`tracesSampleRate: 0.1`。在 368K 月度 invocations 下 = ~37K traces，每条
-trace 含 span 序列化 + 异步上报，叠加在每次 Fluid 调用 + 每次 edge middleware
-上。
+| 日期                 | CPU          | 主要 deploy                                              |
+| -------------------- | ------------ | -------------------------------------------------------- |
+| 4/14 - 5/5           | 5-15min/day  | 普通流量 + 周期扫描 baseline                             |
+| 5/11 15:01-15:39 UTC | 30 → 50min   | PR #341：253 MDX descriptions backfill + 32 新 EN 翻译   |
+| 5/11 16:02-18:41 UTC | 50 → 80min   | PR #342：remark heading shift + leetcode dedup           |
+| 5/11 19:01-19:27 UTC | **90min 峰** | PR #343 + #340 deps，4 小时内 4 次 deploy ISR cache wipe |
+| 5/12                 | ~45min       | crawler 余波未消，但日益下降                             |
 
-**修复**：0.1 → 0.02。日均仍能采到几千条 trace 监控 P95 性能趋势。
+`.github/workflows/deploy.yml` 的 `INDEXNOW_API` 让每次 deploy 都**主动告诉**
+Bing / Google "URL 变了，快重抓"。PR #341 一次性改 253 个 MDX + 加 32 个新
+URL，触发的就是这一波重抓。
 
-**验证**：Sentry dashboard `Performance` tab，Events / 24h 应该下降 5×。
+**结论**：5.11 之后激增是真实流量。本 PR 修的是**不该花的 CPU**（scanner /
+缺 SSG 的路由），让真实流量的边际成本最小化，但解决不了"SEO 太成功"这件事。
+长期路径：上 Pro plan 或 Cloudflare proxy 挡 crawler。
 
 ## 还没修但记录在案的问题
 

sentry.edge.config.ts

@@ -15,9 +15,9 @@ const dsn = process.env.SENTRY_DSN ?? process.env.NEXT_PUBLIC_SENTRY_DSN;
 Sentry.init({
   dsn,
   enabled: process.env.NODE_ENV === "production" && !!dsn,
-  // 10% → 2%（dev_docs/vercel-cpu-overage-2026-05.md H3）。Edge middleware
-  // 每条请求都过这里，10% trace 直接叠在 Fluid CPU 上。降到 2% 显著省 CPU。
-  tracesSampleRate: 0.02,
+  // 10% 采样：与 server config 对齐，保证 client/server/edge 三处 trace 比例一致，
+  // 跨 runtime 串联请求链路才完整。省 CPU 的 hack 撤回，observability 优先。
+  tracesSampleRate: 0.1,
   debug: false,
   beforeSend(event) {
     if (event.request?.headers) {

sentry.server.config.ts

@@ -20,10 +20,10 @@ const dsn = process.env.SENTRY_DSN ?? process.env.NEXT_PUBLIC_SENTRY_DSN;
 Sentry.init({
   dsn,
   enabled: process.env.NODE_ENV === "production" && !!dsn,
-  // 10% → 2%（dev_docs/vercel-cpu-overage-2026-05.md H3）。
-  // 10% 在月百万级请求量下产生 10w+ traces，每条 trace 上报又叠加 Fluid CPU。
-  // 2% 仍能日采几千条覆盖 P95 性能趋势，trace 配额也更宽裕。
-  tracesSampleRate: 0.02,
+  // 10% 采样：行业标准，足以发现 P95/P99 慢请求 + 偶发错误关联的请求链路。
+  // （曾试过 2% 想省 Vercel CPU，但 trace overhead 占比远小于 SEO 重抓带来的
+  // crawler 流量，2% 是省芝麻丢西瓜的 hack —— observability 不能为这点 CPU 让步。）
+  tracesSampleRate: 0.1,
   debug: false,
   beforeSend(event) {
     if (event.request?.headers) {