Minara Discover 性能优化方案

配套文档：performance-analysis.html · 初版 2026-04-19 · 修订 2026-04-20（根据 self-review 修 C1–C5 / M1–M4，回退原 P0.0 的 localeDetection 关停方案） · 代码基准 release@3f254fd71

指导原则

先立基线，再动手。所有"效果"必须有 before/after 数字。没有基线的性能工作是盲修。
按影响 / 工作量矩阵排序。优先做"高影响 + 小工作量"（P0 快赢），然后是"高影响 + 大工作量"（P1 结构），最后是"中影响 + 大工作量"（P2 收尾）。
小步快跑，独立可回滚。每个任务一条分支、一条 PR、一个验收指标；禁止多项混合提交。
用户侧视角。关注 LCP / INP / CLS 而非"构建大小"这种开发侧幻觉指标；最终交付看 PageSpeed 真实数据。
保护与进度同步。移除 ignoreBuildErrors / ignoreDuringBuilds 放在 P0，避免一边优化一边引入回归。

指标与验收门槛

基线：Lighthouse 2026-04-19 实测 · 8 个页面 · 最差页取值

指标	基线实测	最差页	P0 末目标	P1 末目标	最终目标	如何测
Performance Score	25–46	/app/workflow	≥ 50	≥ 80	≥ 90	Lighthouse CLI
LCP (移动 Slow 4G)	44.9 s	/app/workflow	< 15 s	< 5 s	< 2.5 s	Lighthouse × 3 取中位
FCP	9.7 s	/app/workflow	< 4 s	< 2 s	< 1.8 s	Lighthouse
TBT	2.4 s	/app/workflow	< 1 s	< 0.4 s	< 0.2 s	Lighthouse
TTI	45.2 s	/app/workflow	< 18 s	< 7 s	< 3.8 s	Lighthouse
CLS	0.145	/app/strategy-studio	< 0.1	< 0.08	< 0.05	strategy-studio 专题修
主线程工作	45.8 s	/app/strategy-studio	< 18 s	< 6 s	< 2 s	Lighthouse main-thread-tasks
Unused JS	1.6 MB	/home	< 1 MB	< 400 KB	< 200 KB	Lighthouse unused-javascript
单页面下载	11.0 MB	/app/strategy-studio	< 6 MB	< 3 MB	< 1.5 MB	Lighthouse network-requests
重定向链 (P0.0)	7.8 s	/app/workflow	0 s	0 s	0 s	Lighthouse `redirects` audit
INP（真实用户）	未测，估 > 500 ms	–	< 300 ms	< 200 ms	< 100 ms	Cloudflare Web Analytics P75
public/ 总体积	138 MB	–	< 95 MB	< 60 MB	< 40 MB	`du -sh public/`

全局硬性门槛（P1 起）：首页、/about、/use-case、/how-to-guides/[slug] 必须全部为 SSG；对应路由不能出现 'use client'。

测试页面列表（每阶段末必测，与基线对齐）

URL	类型	基线 Score	基线 LCP	关注指标
`/home`	产品首页（匿名）	28	20.8 s	LCP, TBT
`/about`	关于页	29	21.0 s	LCP（大 SVG + YouTube）
`/use-cases`	use-cases 列表页	33	17.1 s	LCP, 路由包体
`/how-to-guides/btc-eth-trading-strategy-complete-battle-plan`	重型模板页	46	4.0 s	路由包体（30 份复制）
`/app/chat`	App shell	28	20.6 s	下载总量 · 10.7 MB
`/app/trade/perps/BTC`	交易页（perps）	26	28.3 s	TradingView 加载、CLS
`/app/strategy-studio`	策略工作室	29	29.4 s	主线程 46s · 下载 11 MB
`/app/workflow`	workflow 画布	25	44.9 s	最差页，重定向 7.8 s

🔥 Lighthouse 实测复盘（2026-04-19）

详见 performance-analysis.html §🚨 Lighthouse 实测。关键回校：

所有 5 个页面 Performance Score 28–46 / 100。LCP 实测 17–21s（原估 4–6.5s，严重低估）；TTI 23–42s；主线程工作 11–36s。
所有页面被重定向到 /zh/，单次重定向浪费 1.3–4.3s（/about 最严重，4.3s）。这是最廉价的改进，必须作为 P0 第一件事。
api.minara.ai/quick-search/all-assets 单次返回 2.5 MB JSON（/app/chat 冷载）。
minara.ai/zh/icon0.svg 文件体积 1.2 MB — 几乎肯定是 bug（把某个 logo/插画错用作 favicon）。
Unused JavaScript：/home 1.6 MB、/app/chat 1.5 MB、/use-cases 1.1 MB。Lighthouse 标明"移除即可省 2.8–6.7s"。
CoinGecko widget 213 KB 在所有页面加载（只在 token/trade 路由需要）。
YouTube embed 在 /about 加载 451 KB —— 之前未发现。

Chrome MCP 实测补充（同一报告 §⚡）：

Auth/Wallet Provider 在 marketing 页发私有接口：未登录的 /home 冷加载调了 api.minara.ai/users/pnls/all × 6、cross-chain/activities × 8、arbitrum/batch × 6。
FB Pixel 3 ID 各自注册：facebook.com/tr + privacy_sandbox/pixel/register 各 3 次 = 6 次无谓请求。
fonts.googleapis.com/css2 一次加载请求 7 次：印证 7 套字体。
同一个 757 KB 大 chunk 打入所有路由（_next/static/chunks/1476-*.js）。
Cloudflare Web Analytics 已部署（/cdn-cgi/rum）：可直接从 CF 后台拉真实用户 P75 CWV。

P0 据此增补了 P0.0（/about 双跳消减，保留自动语言检测） 与 P0.9（favicon / quick-search / YouTube embed 单点爆炸修复） 两节。

2026-04-20 修订摘要

self-review 发现初版若干问题，本轮修订：

P0.0 重写：原方案建议关闭 localeDetection 属于功能回退（首次访问的非英语用户看英文首页）。产品侧确认自动语言检测是必须保留的 feature。新方案只做 /about 双跳消减，不动 locale 检测；收益范围从"-1.3 ~ -7.8s" 缩到 "-0.3 ~ -4s"（以 /about 的 4.3s redirect saving 为上界）。
P0.2 拆为 spike + 修复：不再假设"10 分钟搞定"，先 spike 跑 build 看错误数。
P0.3 拆出 P0.3b TradingView 下沉：独立 1 天，TradingView 全局 Script 挪到路由级需处理实例化/销毁/SPA 重挂。
P0.5 加 grep 步骤：GIF → 视频前先枚举所有 .gif 引用分类，避免 <img src=.gif> 与 <video> 混用断点。
P0.8 缩编：Provider 下沉的完整 route-group 拆分归 P1.1；P0.8 只做"useEffect 条件化"短期止血。
里程碑现实化：W1 day 1 不塞 3 件事；最差页 P0 末 LCP 目标从 15s 放宽到 25s。
DoD 指标自动化：scripts/perf-report/deploy.sh snapshot <label> 产出 JSON + HTML 作为对比证据，不再截图。
补充风险：首次访问 UX / FB Pixel 转化缺失 / PageSpeed 分数方差 / 设计视觉回归 / 缺 staging gate。

P0.0 /about 双跳消减（半天 · 保留自动语言检测）

背景：Lighthouse 对所有 5 页报告 "Avoid multiple page redirects"，省时 1.3–4.3s。实际观察到的跳转链：

/about → /zh/about → /zh/why-minara/about（3 hops / 2 redirects，/about 的 4.3s 全部来源于此）
/home → /zh/home（1 redirect · 来自 locale 检测）
/app/workflow → /zh/app/workflow（1 redirect · locale 检测 · 实测 7.8s savings，但主要来自跳转落地页主线程堵塞而非跳转本身）

本章只处理可不回退功能的部分：/about 的第二跳（/why-minara/about 重定向）。 Locale 检测（localeDetection: true）保留不动 —— 首次访问非英语用户的自动跳转是产品必需 feature。

当前 /about 的设计问题（src/app/[locale]/about/page.tsx）：

// 实际服务页在 /why-minara/about
// 但 /why-minara/about/metadata.ts 声明 canonical = '/about'
// 所以 /about 用 redirect() 跳 /why-minara/about —— canonical URL ≠ 实际服务 URL

这是个历史 SEO 反模式：canonical 不可直达。

两个二选一方案（需产品/SEO 决定）：

A. /about 作为真正 canonical（推荐）：把 src/router/about/ 组件渲染搬到 src/app/[locale]/about/page.tsx；src/app/[locale]/why-minara/about/page.tsx 改成 redirect('/about') 做 301 永久；metadata 保持 canonical = '/about' 不变。外链系统不受影响。
B. /why-minara/about 作为 canonical：把 metadata 里 canonical 改成 /why-minara/about；保留 /about 的 redirect（或在 next.config.mjs 的 redirects() 声明为 permanent 301，由 CDN 缓存，对非首次访问无视）；更新 header 链接保持已有写法。历史外链仍经 1 跳。

改点（方案 A 为例）：

把 src/app/[locale]/about/page.tsx 从 redirect() 改为直接渲染 <About />；保留 query string 透传
src/app/[locale]/why-minara/about/page.tsx 改为 redirect('/about')；关键：使用 redirect() with RedirectType.permanent（301）让浏览器缓存
确认 src/components/seo/metadata.ts 生成的 canonical = /about
更新 header 导航里所有 /why-minara/about → /about（grep src/router/homepage/use-header-link.ts 等 9 处）
sitemap 脚本若手写了 /why-minara/about 条目，改成 /about
hreflang 自动指向正确 URL（无需改代码，但需验证）
更新文内所有"关于我们" / "About" 文案链接（SEO 内链权重）

验收：

curl -sI http://localhost:3000/about -H 'Accept-Language: en' → 直接 200（不再 307）
curl -sI http://localhost:3000/about -H 'Accept-Language: zh' → 只有 1 跳到 /zh/about（不再有第 2 跳）
Lighthouse 重跑 /about：redirect savings 从 4,265ms 降到 ≤ 1,800ms
之前收录 /why-minara/about 的 SE 抓取下一次爬取返回 301，页面权重无损失（观察 Search Console 2 周）

风险 / 回滚：

风险	预防	回滚
Header 内链漏改某处导致 404	grep 全部 `/why-minara/about` 引用双重验证	revert 单 PR；`/why-minara/about` 页面仍存在即可兜底
Google 短期排名波动（URL 结构变化惯例）	301 正确返回，hreflang 正确	无需回滚，2–4 周自然恢复
/about 下还有子路由期望 `/why-minara/about/xxx`	搜 `/why-minara/about/` 前缀确认	只改 about 本身，子路由维持原路径

预期收益：

/about LCP -1.5 ~ -4.3s（取决于 301 是否进 CDN 缓存）
其他页面无变化（locale 检测保留，1 跳不可避免，但属于产品要求）

阶段 P0 · 快赢止血（预计 1 周）

目标：立刻回收最大流量、解除最明显的主线程阻塞、建立指标闭环；不改变任何架构。全阶段应可在 5–7 个工作日内由 1 名工程师完成。

P0.1 建立性能基线（第一件事）

在 next.config.mjs 接入 @next/bundle-analyzer：ANALYZE=true pnpm build 导出 .next/analyze/*.html，归档到 docs/perf-baseline/2026-04-YY/
跑 3 次 PageSpeed Insights（移动端）对测试页面列表中的每一个 URL，导出 PDF 或截图
启动 next build 记录：初始 JS (gzip)、每路由页面 JS (gzip)、首屏 HTML 大小
引入 web-vitals 上报到 GA/Sentry：首期只看 LCP/INP/CLS 中位数
验收：docs/perf-baseline/2026-04-YY/ 有完整数字；后续每任务完成后重跑并对比

P0.2 恢复 CI 类型安全网（1h spike + 0.5–3d 修复）

分两步，不能合并（原方案"10 分钟"低估了历史欠债）：

P0.2a · Spike（1 小时）：

临时本地注释掉 eslint.ignoreDuringBuilds + typescript.ignoreBuildErrors，跑一次 next build
记录错误类型与数量到 docs/perf-baseline/ci-errors-$(date +%F).log
决策：
- 错误数 ≤ 20 → 和 P0.2b 合成 1 个 PR，当天修完
- 错误数 20–100 → P0.2b 单独 PR，1–2 天
- 错误数 > 100 → 单独 epic，按文件 / 类型切 3–5 个小 PR 分批修

P0.2b · 修复并开启 (0.5–3 天)：

按 spike 决策修复所有阻塞 build 的 TS/ESLint 错误（不修 warnings，除非影响构建）
next.config.mjs 正式删除两行 ignore*
CI 里分别跑 next build + next lint + tsc --noEmit
验收：所有上述命令本地 + CI 绿；后续 PR 若引入新错误，CI fail

风险：如果错误集中在第三方 dep 的 type 声明（非业务代码），可能需要 // @ts-expect-error 标注 + 单独跟踪。

P0.3 Layout 脚本 strategy 化 + polyfill / CDN 清理（半天）

改点：src/app/[locale]/layout.tsx

GA / GTM 两条 <Script> 加 strategy="afterInteractive"（显式）
Facebook Pixel <Script> 改 strategy="lazyOnload"；三个 addPixelId 跟 Growth 确认用途，无法砍则保留 —— 不能静默删除，避免转化事件丢失
markdown-it-fix 移除 beforeInteractive（需先跑步骤 a 验证）：
- a. 先复现依赖路径：grep -rn "isSpace" node_modules/markdown-it/lib 看哪些 fn 调用；在 dev 模式下确认 SSR / CSR 两条路径都能在 polyfill 缺失时正确抛错
- b. 迁移 polyfill 到 src/instrumentation-client.ts（Next 15 原生支持）或 markdown-it import 的 wrapper 顶部
- c. 回归：所有含 markdown 内容的页面（chat、how-to-guides、docs）在 prod build 下 smoke test
下沉 CoinGecko widget：仅在实际使用的组件挂载时动态注入（next/script + strategy="lazyOnload"）
移除 unpkg 的 canvas-datagrid：已有 canvas-datagrid npm 依赖，通过 next/dynamic + ssr:false 导入；同时避免未固定版本的供应链风险
所有 <Script> 补全 strategy
验收：Lighthouse Network 面板中，首页加载时 head 阶段 ≤ 2 个第三方请求（GA + fonts）；PageSpeed TBT 较基线下降 ≥ 400 ms
风险：FB Pixel lazyOnload 后，早期 pageview 事件可能在用户秒关页面时丢失。观察 FB Events Manager 48h，若转化数据下降 ≥ 10%，回到 afterInteractive。

P0.3b TradingView 脚本下沉（1 天 · 独立 PR）

TradingView charting_library.js 目前在 layout.tsx L149 全局 <Script defer>，实测 /app/workflow、/app/chat（都不需要图表）也会加载它。下沉到真正使用的路由 比想象复杂。

改点：

写 src/components/tv-loader/index.tsx 组件：
- 在 useEffect 里 append <script> 到 document.head
- 组件销毁时 不 remove script（全局注入只一次，避免 SPA 切换时 thrash）
- 用 module-level flag 保证全进程只注入一次
- 暴露 useTVReady() hook 供下游 widget 组件等待 script ready
在 src/router/session/trade/layout.tsx（或 perps/spot 各自 layout）挂 <TVLoader />
同样在 src/router/session/strategy/ 挂
删除 layout.tsx 里的全局 <Script src="/charting-library/..." />
所有 TradingView widget 消费组件改为等 useTVReady() 返回 true 再实例化
验收：
- /home、/about、/app/chat、/app/workflow 的 Network 面板不再出现 charting_library.js
- /app/trade/perps/BTC 正常渲染 K 线
- SPA 切换（workflow → trade → workflow → trade）时 charting_library 只 download 一次
风险：
- 若 strategy studio 的图表模块内部对 window.TradingView 做了 eager 引用，<TVLoader> 需要在 strategy 组件挂载前就已注入 → 用 <TVLoader /> 放 layout 顶层即可
- 回滚：revert PR，<Script> 回到 layout；白名单路由方案保留作 fallback

P0.4 字体瘦身（半天 · 需设计签字）

改点：src/app/[locale]/layout.tsx L152–166 + src/app/[locale]/globals.css

先 grep 使用点：grep -rn "font-family.*Jost\|font-Jost\|DM Serif\|Pixelify\|Righteous" src 定位每种字体的实际使用组件
逐字体决策 + 截图签字：把使用点渲染截图发设计师：
- DM Serif Text / Jost / Righteous / Pixelify Sans 是否可换系统 fallback？
- 若只是装饰（hero 大标题），能否用 variable font 合并多款？
- 设计不签字不动
Noto Serif SC：仅在 locale 为 zh / zh-TW 时注入（在 layout 内判断 locale 后条件渲染 <link>；其他语种不拉）
保留的字体全部迁移到 next/font/google（自动 preload、避免 CLS；与 Roboto 同）
若保留 4+ 字体，额外动作：本地自托管子集（subset: ['latin'] 已够；CJK 只 subset 中文核心字形）
WCAG 验收：删除字体后需走一遍 Chrome Lighthouse Accessibility audit，确保对比度 / 最小字号不回退
验收：
- layout.tsx 中 <link href="fonts.googleapis.com"> 外部 <link> 清零（全部 next/font）
- Lighthouse "Ensure text remains visible during webfont load" 通过
- 设计师签字（docs/perf-baseline/2026-MM-DD/font-review.md）
风险 / 回滚：字体突然换 fallback 会导致 brand 视觉瞬变。以单字体单 PR 落地，如出现用户反馈立刻 revert 单个字体。

P0.5 巨型静态资源换格式（2–3 天）

Step 0 · 先枚举调用点（关键！不同调用点迁移动作不同）：

# 所有 GIF 引用位置 + 引用方式
grep -rn "cooking/[0-9]\.gif\|minara\.gif" src --include="*.tsx" --include="*.ts" --include="*.md"

分类：

<img src="xxx.gif"> 或 <Image src="xxx.gif"> → 换 <video autoPlay muted loop playsInline> 并 poster="xxx.webp" 保留首帧
WrappedImage 包装（内部 <img>） → 需先扩展 WrappedImage 支持 type="video" 或提供 WrappedVideo
markdown ![](xxx.gif) → markdown 无法渲染 <video>，需在 MD → HTML 时加规则把 .gif 换成 <video> 或保留 GIF（不处理这类，单独评估）
纯 CSS background-image → <video> 替代不自然，保持 GIF 或换 WebP 静态图
Open Graph og:image → 只能 PNG/JPG/WebP（YouTube/X 不支持 video），保持 PNG 但压缩

Step 1 · GIF → 视频（优先级高）：

public/images/guide/minara.gif 27 MB →

ffmpeg -i minara.gif -c:v libx264 -movflags +faststart -pix_fmt yuv420p \
  -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" minara.mp4
ffmpeg -i minara.gif -c:v libvpx-vp9 -crf 30 -b:v 0 minara.webm
# 生成首帧 poster
ffmpeg -i minara.gif -vframes 1 minara-poster.webp

cooking/1-4.gif（每个 1–1.5 MB）同样三件套
对 <img src=".gif"> 调用点改为：<video autoPlay muted loop playsInline poster="minara-poster.webp"><source src="minara.webm" type="video/webm"><source src="minara.mp4" type="video/mp4"></video>

Step 2 · 巨型 PNG → WebP + 降分辨率：

share/dark/background.png 14 MB、share/light/background.png 7.1 MB：先在浏览器里测真实展示尺寸，sips -Z <maxdim> 降分辨率到 2× DPR 需要的像素，再 cwebp -q 85 转 WebP
copilot/hero-bg.png 13 MB → 同上
campaign/korea-trading-competition/hero.png 4.9 MB → WebP
替换 <Image> / <img> src 引用

Step 3 · OG 图压缩：

og/image-0/1/2.png 3 × 3MB → JPEG 85q 或 WebP，目标每张 < 500 KB（OG 规范 1200×630）
og/*.png 保持文件名不变，只替换内容（防止社媒缓存失效时 URL 变动）

Step 4 · 加 CI 守护：

scripts/check-public-size.sh：单文件 > 500 KB 在 CI fail（白名单：已有的合法大 asset）
package.json scripts 加 "lint:public-size": "scripts/check-public-size.sh"
GitHub Actions 或本地 pre-commit 调用

验收：

du -sh public/ < 95 MB
Lighthouse 首页 "Properly size images" + "Serve images in next-gen formats" 两条诊断消失
旧 GIF 文件从 public/ 删除（保留原始 src 在 docs/assets-archive/ 以防需要重压）

风险：

<video> 在 iOS Safari 偶现黑屏（autoplay policy），muted + playsInline 必须同时设；在 iPhone 物理设备上实测一次
用 ffmpeg 转 WebM 可能丢失原 GIF 的透明通道（关键帧），若某张 GIF 有透明背景需额外确认

P0.6 删除未用的依赖（半天）

每个依赖的移除必须 grep 验证 + build 验证，不能按 audit 断言直删。

Prismjs：
- pnpm why prismjs 看 transitive
- grep -rn "from 'prismjs'\|require.*prismjs" src 看直接引用
- 确认无引用后 pnpm remove prismjs；跑 next build + 手动打开包含代码块的页面
highlight.js：import 'highlight.js/styles/github.css' 在 layout.tsx L22 存在 —— 先决定 P1.3 要不要迁 Shiki，如果迁则此 CSS 也去；如果不迁，highlight.js 不删
jotai / jotai-immer：
- grep -rn "from 'jotai\|from 'jotai-immer'" src | wc -l 统计
- 逐个消费点迁到 zustand 或 constate（可能有 deep 用法需重构）
- 如果 > 5 处 usage，不删，留到 P1.8 做统一状态管理迁移
canvas-datagrid、dom-to-image、@zumer/snapdom、cropperjs、@xyflow/react：
- 不删，但明确标注"延迟加载入口"
- P1.4 里改为 next/dynamic
验收：
- pnpm install 后 node_modules 缩小
- next build 初始 JS chunk 下降 ≥ 200 KB
- 本地 smoke test 5 个页面（home + about + discover + trade + chat）无运行时错误

P0.7 discover 轮询节流与可见性感知（半天 · 需产品签字频率）

改点：src/store/discover/index.ts + src/trade/shared/trade.service.ts + src/services/use-chat-list.ts

4 个 useRequest 补 cacheKey（如 discover:fear-greed:{locale}）
轮询频率调整需产品签字（用户体验 vs 服务器成本 trade-off）：
- discover 指标：30 s → 60 s ？（产品：fear-greed 变化频率是否可接受 60s 延迟）
- chat list running：3 s → 5 s ？
- trade positions：3 s，保持不变（交易实时性要求）
- 产品 OK 后再改，不自行决定
所有轮询加 visibility gate：封一个 usePolling(fn, interval) hook，内部监听 document.visibilityState === 'hidden' 暂停；返回前台 resume
失败重试加指数退避（1s → 2s → 4s → ... 最大 5min）；连续 3 次失败停止并报 Sentry
clearInterval 在 unmount / 登出 / visibilitychange=hidden 都要触发（目前部分缺失）
验收：
- devtools Network → 切到后台标签 30 s 内 discover 请求数 = 0
- trade 登出后 5 s 内所有 trade 相关轮询停止
- 人工断网 → 重连后指数退避生效（日志可见），无请求洪水
风险：visibility 暂停可能让用户切回来后看到"过期数据"，需在 visibility=visible 时立即触发一次 refetch

P0.8 Store useEffect 条件化止血（1 天）

范围说明：完整的 route-group 拆分（营销路由单独 layout 不挂 Auth/Wallet Provider）已挪到 P1.1，避免同一件事 P0/P1 重复列。P0.8 只做能在不改架构的前提下快速止血的 1 件事：让 Store 的自动请求在无登录态时不发生。

背景：未登录的 /home 上 pnls/all 被调 6 次、cross-chain/activities 8 次，原因是 Store 里 useEffect 无条件 fire。

改点：

grep "挂载时自动请求"：

grep -rn "useEffect" src/store/custodial-wallet src/store/user src/services/use-chat-list | head -20
grep -rn "useRequest\|useRequest(" src/store src/services --include="*.ts*"

为每个无条件请求的 effect 加 guard：
```
useEffect(() => {
  if (!hasCredential) return;
  refresh();
}, [hasCredential]);
```
或对 useRequest 使用 ready: hasCredential（ahooks 原生支持）
不做的 2 件事（归 P1）：
- 不统一加 cacheKey（会破坏依赖 "每次 fetch 都拿新数据" 的组件）
- 不做 route-group 拆分（属于架构改动）

验收：

无痕模式访问 /home，Network 面板中：pnls/all / cross-chain/activities / arbitrum/batch 请求数 = 0
/use-cases、/about 同上
登录后 访问 /app/chat：这些接口正常发送，数据正常渲染（对比基线，功能 0 回退）
对比前后 Network 面板，已登录场景的请求数变化应 = 0（P0.8 只影响未登录场景）

风险 / 回滚：

如果某个 Store selector 在未登录态期望 "曾经有过初始数据"，guard 加完可能显示空态。对每个加了 guard 的 Store 单独 smoke test 登出态下的 UI。
回滚：revert 单 Store 的 guard，影响面可控。

P0.9 单点爆炸修复（半天 · 一组"检查报告直接发现的 bug"）

每个修复点前都有一步 "先确认"——不按假设直接动手。

1.2 MB favicon 确认 + 修复：
- 先：cat src/app/icon0.svg | head -5 && ls -la src/app/icon*.{svg,png} 读文件头 + 看体积
- 情况 1（高概率）：icon0.svg 的 <svg> 标签里 base64 内嵌了某张 logo 插画 → 导出为 PNG/WebP 作 icon，SVG 重绘为简单轮廓 ≤ 5 KB
- 情况 2（低概率）：确实是故意做高分辨率 brand mark → 与设计协商，至少压 SVGO + gzip
- 不能盲删或替换
/quick-search/all-assets 2.5 MB JSON 分三步：
- Step 1：先 curl -H 'Accept-Encoding: gzip' ... -o - -w '%{size_download}\n%{content_type}\n' 看是否已压缩。如果没开 gzip/br，这是后端一行 config 改动
- Step 2：若已压缩还 2.5 MB，说明内容真大 → 跟后端拆接口：首屏 /top-assets 返回 50–100 高频交易对（≤ 200 KB），用户开始输入搜索词时 lazy fetch /all-assets
- Step 3：前端改 src/features/chat-base/input/lexical/use-all-assets.ts 的 fetch 逻辑
- 需要后端配合，不是纯前端 PR
/about YouTube 嵌入换 lite-youtube-embed：
- grep -rn "youtube\|youtu\.be" src/router/about src/app 找到实际嵌入点
- 安装 lite-youtube-embed (~3 KB) 或手写 <iframe> + click-to-load placeholder
- 保留 thumbnail（从 YouTube API 或手动下载一张）作 poster
- click 后才注入真 iframe

验收：

Network 面板：favicon 请求 < 50 KB
/quick-search/all-assets 首响应 < 200 KB（含压缩）或首屏只拉 /top-assets
/about 首屏 Network 面板不再有 youtube.com/.../player_embed 加载
点 /about 视频占位图，YouTube 正常播放

风险 / 回滚：

favicon：浏览器 tab 图标若外观显著变化，设计师签字
quick-search 后端改动：需跟后端 PR 联动，单前端 PR merge 前要确认后端已上
YouTube 占位：失焦 SEO（Google 可能不抓视频 structured data），若站点依赖 YT 视频 rich result 需加 VideoObject schema 补偿

P0.10 CoinGecko widget 下沉 + Unused CSS 清理（半天）

Lighthouse 显示 CoinGecko widget（213 KB、28–30 ms 主线程）在所有 5 个页面加载；同时 Unused CSS 约 30 KB。

把 CoinGecko <Script> 从 src/app/[locale]/layout.tsx L148 挪到真正使用它的组件（如 src/components/token-pop-up/ 或 src/router/session/token/），改 next/dynamic 或组件挂载时 next/script strategy="lazyOnload" 注入
审计 30 KB unused CSS（多半在 globals.css 或 Tailwind 未扫描到的文件中遗留）：tailwindcss purge scope 正确？highlight.js/styles/github.css 全局引入是否有必要？

验收：/home、/about、/use-cases、/how-to-guides/[slug] 均不再加载 gecko-coin-price-chart-widget.js。

阶段 P1 · 结构性重构（预计 3 周）

目标：真正把架构从"全部 client SSR on-demand"拉回"静态优先 + 按需 client"；这个阶段改动大但收益最持久。

P1.1 营销页 RSC 化 + SSG（1 周）

范围：/、/home、/about、/use-case、/faq、/pricing（评估）

拆分原则：凡是不依赖用户登录态的 UI（hero、feature grid、testimonials、footer），移除文件头 'use client'，放 server component
把依赖交互的部分（动画按钮、切换 tab、video 自动播）下沉到小颗粒 client leaf（capability-animations.tsx 等）
在对应 page.tsx 导出 export const dynamic = 'force-static' 或 revalidate = 3600
引入 <Suspense fallback={<Skeleton />}> 包裹任何含数据获取的 client island
根 layout.tsx Provider 下沉：把 UserAuthStoreProvider / CustodialWalletStoreProvider / ShareChatImageStore 挪到 新建的 src/app/[locale]/(session)/layout.tsx 组分组，营销页不再承担认证态初始化成本
验收：
- 上述页面 next build 输出 ● (Static) 标记
- 页面 HTML 体积（gzip）< 30 KB（无需含整个 React tree）
- Lighthouse 移动端 LCP < 3.0 s

P1.2 how-to-guides 30 份模板重构（3 天）

将所有 30 份 src/router/how-to-guides/<slug>/index.tsx 内容抽取为 JSON：src/content/how-to-guides/<slug>.json（结构：hero、relatedGrid、faq、…）
写单个组件 src/router/how-to-guides/template.tsx（仅 1 份 ~200 行）

新建 src/app/[locale]/how-to-guides/[slug]/page.tsx：

import { loadGuideContent, listGuideSlugs } from '@/content/how-to-guides';
export async function generateStaticParams() {
  return listGuideSlugs().map(slug => ({ slug }));
}
export default async function Page({ params }) {
  const data = await loadGuideContent(params.slug);
  return <GuideTemplate data={data} />;
}
export const revalidate = 86400;

旧 src/router/how-to-guides/<slug>/ 目录整体删除；保留 sitemap 生成脚本对内容目录的指向更新
验收：
- src/router/how-to-guides/ 代码量从 ~60K LOC 降到 < 500 LOC
- 30 条 guide 路由在 next build 输出 ● (Static)
- next-sitemap 仍产出全部 30 条 URL

P1.3 语法高亮合一（1 天）

保留 react-syntax-highlighter 或（推荐）迁到 Shiki （SSR 渲染出纯 HTML，客户端 0 JS）
删除 highlight.js 与 prismjs（含 layout.tsx 中 import 'highlight.js/styles/github.css'）
代码块改为 server component 预渲染；如果必须在客户端（长文档），用 next/dynamic + ssr:false
验收：pnpm why prismjs highlight.js 输出 "no such package"；消息流 markdown 无视觉差异回归测试通过

P1.4 重型依赖按需化（1 周，多 PR）

批量把以下依赖改成 next/dynamic({ ssr: false, loading })：

依赖	建议承载点
Monaco editor	✅ 已做
`@xyflow/react`（workflow 画布）	仅 `/app/workflow` 动态导入
`echarts` + `echarts-for-react`	仅 strategy studio 图表组件
`canvas-datagrid`	spreadsheet section 内部 dynamic
`cropperjs` + `react-cropper`	头像上传 modal 打开时 dynamic
`dom-to-image` / `@zumer/snapdom`	share 截图功能触发时 dynamic
`canvas-confetti`	胜利动画触发时 dynamic
`@lexical/*`（编辑器）	聊天输入框 focus 后再加载（可选）
TradingView charting library	P0 已下沉到交易/策略路由；这里确认最终只在 trade/strategy bundle

验收：首页初始 JS 相比 P0 再降 ≥ 25%

P1.5 Namespace import + barrel 重构（1 周，多 PR）

20 处 import * as X 全部改为命名 import（ast-grep 可批量）
核心 barrel 拆分：components/primitive/index.ts、features/chat-base/index.ts、utils/date|number/index.ts
- 拆为子路径：@/components/primitive/button、@/features/chat-base/core/use-chat 等
- 通过 ESLint 规则 no-restricted-imports 禁止从 barrel 导入（给一个 codemod 脚本帮忙替换）
41 处 from 'lodash' → from 'lodash-es/capitalize' 之类（或在 optimizePackageImports 命中前提下保留，但统一风格）
验收：next build 首页/guide 页 JS chunk 再降 10–20%

P1.6 启用 PPR + 评估 React Compiler（3 天）

next.config.mjs 加 experimental.ppr = true（需 Next canary/15.4；15.3 stable 尚有限制——先 POC 评估）
安装 babel-plugin-react-compiler，在 babel 配置开启；先在 src/features/chat-base/ 小范围试点
将 reactStrictMode 设回 true（默认 off 是反模式；会暴露一批并发模式相关 bug，值得在这一阶段集中修复）
验收：试点路由 INP 中位数下降 ≥ 20%；无新增 hydration warning

P1.7 discover news feed 虚拟化（半天）

src/router/session/discover/news-page/index.tsx eventsList 的 .map() 改为 virtua 或 react-window（项目已有）
NewsCard 的 motion.* 入场动画仅对视口内的 item 触发（IntersectionObserver + useReducedMotion）
验收：500 条 news 场景 scroll FPS > 55；内存 heap 下降

P1.8 Zustand / constate 细粒度化（3 天）

审计 jotai 实际使用范围；若能合并到 zustand/constate，移除 jotai
src/store/trade-store/index.ts：41 个 selector 保留，但消费端禁止 useXxx() 整取——通过 ESLint 规则或人工 code review 确保只拿需要字段
src/store/chat/index.tsx L286 的 s => s 改为导出若干窄 selector
验收：React DevTools Profiler 录制 trade 页 30 s 交互，总 render 次数下降 ≥ 30%

阶段 P2 · 收尾与运维（预计 1 周，可与 P1 并行）

P2.1 资源链路收紧

next.config.mjs images.remotePatterns 改白名单（仅允许 space.minara.ai、CoinGecko CDN、Twitter/Google OAuth、Solana/Ethereum 等必要域名）
SVG 瘦身：minara-logo-with-text-*.svg 用 SVGO 精简 + 删除重复副本；blockchain.svg 959 KB 若为装饰，降级 PNG/WebP；chain/base.svg 同理
24 处 <img> → next/image；如果 WrappedImage 组件内部是 <img>，也包一层 next/image
验收：public 压缩到 < 40 MB；首页"Properly size images"100 分

P2.2 细节运行时优化

合并 share layout 三次 getTranslations → 一次
删除 create-markdown-render.tsx 热路径的 console.warn
合并 markdown 5 条串联预处理 useMemo 为一条（组合函数）
Leaderboard / chat list 循环内 inline style={{}} 提取为常量

P2.3 观测与守护

CI 加 size-limit 或 bundlesize：首页 JS 超过阈值直接 fail（建议 200 KB gzip）
@next/bundle-analyzer 结果自动贴到 PR 评论
Sentry 接 web-vitals 实时监控；加 LCP / INP 的告警阈值
设置月度回归报告模板：每月重跑 PageSpeed + bundle-analyzer，结果归档到 docs/perf-reports/YYYY-MM/

里程碑与排期（单人估算，含 buffer）

每周末必须跑 ./scripts/perf-report/deploy.sh snapshot pX-end 并归档对比，数字说话。

周	阶段	主任务	预期（按最差页 /app/workflow 估算）
W1 day 1–2	P0.1 + P0.2a	基线工具入 CI + spike CI type errors 数	基线归档；P0.2b 工作量确定
W1 day 3	P0.0 + P0.9（需先与产品确认 /about canonical + favicon 修法）	/about 双跳消减 + 3 个单点 bug	LCP: 44.9 → 42 s; /about: 21 → 17 s
W1 day 4–5	P0.3 + P0.3b	脚本 strategy + TradingView 下沉	TBT -400~800 ms
W1 末（day 5–7）	P0.4 + P0.5 + P0.6 + P0.7 + P0.8	字体 / 大图 / 依赖瘦身 / 轮询 / Store guard	score ≥ 40; LCP ≤ 30 s（最差页）
W2–W3	P1.1 + P1.2	营销页 RSC/SSG 化（含 Auth/Wallet Provider 下沉到 (session) 组）+ how-to-guides 模板重构	营销页 LCP < 6 s; score ≥ 65
W4	P1.3 + P1.4	高亮合一 + 重型依赖全 dynamic	Unused JS < 600 KB; TBT < 600 ms
W5	P1.5	barrel / namespace import 重构	首屏 JS -40% vs W1 末
W6	P1.6 + P1.7 + P1.8	PPR/Compiler POC + 虚拟化 + store 审计	INP < 200 ms; score ≥ 80
W7	P2	资源链路收紧 + 观测守护	score ≥ 85 最差页；最终验收跑 `snapshot final`

和原版差异：

从 "6 周一人" 改为 "7 周一人 + 1 周 buffer"
P0 末 LCP 最差页目标从 15 s 放宽到 30 s（实测可达性），最终目标仍是 2.5 s
两人并行可压到 4–5 周（之前写的 "3 周" 不现实）

W1 day 1 不再塞 3 件事。先建基线 + spike CI 错误数，有了数才能定节奏。

风险与回滚

风险	预防	回滚策略
移除 `ignoreBuildErrors` 后 CI 挂一大片	P0.2a spike 先看错误数，据此决定节奏	不移除 flag，单独 epic 分批修（见 P0.2）
RSC 化漏加 `'use client'` 引发 "useState 不能在 server"	单 PR 控制单页面；先预览环境验证	revert 单页面；其他页面不受影响
P0.0 /about 迁移引发 SEO 排名短期波动	301 正确返回；hreflang 正确；发布前通知增长	无需回滚，2–4 周自然恢复；Search Console 持续观察
SSG how-to-guides 导致 sitemap 生成链断	迁移时双跑 `next-sitemap` + 原脚本	保留旧 `router/how-to-guides` 目录直至 sitemap 验证通过再删
TradingView 下沉到 trade 路由后某些非 trade 页仍在用	代码检索 `TradingView`/`charting-library`/`trading_view` 引用	Hotfix：恢复 layout 注入，但仅限白名单路由
Facebook Pixel lazyOnload 后早期 pageview 事件丢失	发布前与 Growth 对齐；观察 Events Manager 48h	回到 `afterInteractive`；pixel 事件是法律 / 广告投放依赖，不能静默降级
字体删除 / fallback 引发品牌视觉回退	设计师签字 + 每字体截图对比 + 单字体单 PR	revert 单字体 PR
WCAG 对比度 / 最小字号违规	Lighthouse Accessibility audit	revert + 调 fallback 字体族
PageSpeed 分数跑分方差 5–10 分	每次 `snapshot` 跑 3 次取中位	若单次 drop < 10%，视为噪声；持续性回退才 revert
缺 staging gate：改动直上生产	所有 P0/P1 PR 必须先合 `release` 分支在预发 `minara-perf` 对应预发域名（若有）验证	若无预发，用本地 `next start` + Lighthouse CLI 本地验收
PPR 在 15.3 稳定性不够	先在 canary 15.4 POC	移除 experimental flag，页面仍以 SSG 运作
Zustand selector 收窄引入 stale closure	以路由为单位改动 + 人工 code review	回到整 store 读取（损失性能但功能正确）
`ahooks` 自动 cacheKey 破坏"每次拿新数据"的组件	不统一加 cacheKey；显式配置或走 `staleTime: 0`	单 PR 恢复无 cacheKey

完成定义（DoD）

每个任务 PR 必须：

含自动化的基线对比数字（不再截图）：
- bundle size diff：@next/bundle-analyzer 输出附 PR
- Lighthouse diff：./scripts/perf-report/deploy.sh snapshot <pr-label> 产出 JSON；与 baseline 对比的关键指标（LCP / TBT / score）用 jq 提取贴到 PR 描述
含 test/<branch>/test-cases.md 的验收清单
通过 next build + next lint + tsc --noEmit
不引入 console 噪音（server 端也不例外；P2.2 之前允许现存残留）
在 PR 描述里写明预期回收的指标、实测值、与基线的 delta
通过 staging gate：release 分支预发验证（如项目启用预发域名）或本地 next start + Lighthouse CLI 验收

PR 排序约束：

独立 PR：P0.0 / P0.2 / P0.3 / P0.3b / P0.4 / P0.5 / P0.6 / P0.7 / P0.8 / P0.9 / P0.10 —— 彼此不依赖，可并行开
依赖：P1.1（营销页 RSC + Provider 下沉）必须在 P0.8（Store guard）之后；P1.4 必须在 P0.6（依赖清理）之后
阻塞：P0.2b 若错误数 > 100，P0.3 起所有 PR 先在 release 基础上 cherry-pick，等 P0.2b merge 后再 rebase

阶段完成：

P0 末：跑 ./scripts/perf-report/deploy.sh snapshot p0-end 归档，最差页 LCP 改进 ≥ 30%；报告展示在 https://minara-perf.yijian.nftgo.cloud/post-fix/p0-end/
P1 末：同 snapshot p1-end；营销页 + guide 全 Static；Lighthouse 移动端 Performance 分中位 ≥ 85
P2 末：同 snapshot final；CI 加入 bundle 守护；月度回归报告第 1 期归档

附录 · 关键文件速查

问题	文件
脚本/字体堆叠	`src/app/[locale]/layout.tsx`
构建配置	`next.config.mjs`
模板复制	`src/router/how-to-guides/<slug>/index.tsx`
轮询源头	`src/store/discover/index.ts`, `src/trade/shared/trade.service.ts`, `src/services/use-chat-list.ts`
状态管理	`src/store/trade-store/index.ts`, `src/store/chat/index.tsx`
流式渲染（保持）	`src/features/chat-base/core/xhr-stream-utils.ts`, `src/features/chat-base/message-view/section/create-streaming-markdown.tsx`
巨型资源	`public/images/guide/minara.gif`, `public/images/share/`, `public/images/copilot/hero-bg.png`, `public/images/og/`
Barrel 文件	`src/components/primitive/index.ts`, `src/features/chat-base/index.ts`, `src/utils/date/index.ts`, `src/utils/number/index.ts`