TiHUBB 视觉引擎分析报告 (Editorial vs Fashion)

1. 语义权重引发的模型推理延迟 (Model Inference Bottleneck)

• 现象描述：在 geminiService.ts 中，虽然 systemInstruction 是统一的，但在 userPrompt 中传入了变量 Engine: EDITORIAL。
• 深层原因：当模型接收到 EDITORIAL 指令时，其内部生成的逻辑会趋向于 “高密度叙事”（参考指令中的 Monocle 和 The Economist 风格）。相比 FASHION 模式通常生成的短促、碎片化信息，EDITORIAL 模式下模型会尝试生成更长的列表（list 数组）和更复杂的洞察（insights 数组）。
• 卡顿点：gemini-3-flash-preview 在处理复杂 JSON Schema 且内容长度接近输出上限时，首字延迟（TTFT）会显著增加，可能触及了 withTimeout 设定的 90s 阈值，或导致浏览器在解析巨量 JSON 字符串时出现微秒级阻塞。

2. CJK 字库加载与渲染主线程阻塞 (Font Rendering & Main Thread Block)

• 现象描述：EDITORIAL 模式强制使用了 “Noto Serif SC” (宋体) 和 “Noto Sans SC” (黑体)。
• 深层原因：
  • 文件体积：中文字体文件极其庞大。EDITORIAL 模式下文字密度极高，浏览器在预览区（Preview Area）渲染 PosterCard 时，必须等待 Google Fonts 完成全量的字形解析。
  • 重绘开销：PosterCard.tsx 中使用了 noise-layer (SVG 滤镜)。在 EDITORIAL 这种多文本、细线条的排版下，SVG 滤镜叠加庞大的宋体字形，会导致浏览器的 Layout & Paint 阶段计算量激增。FASHION 模式通常文字较少且多用英文（Montserrat），渲染压力小。

3. JSON Schema 约束下的递归死循环风险 (Schema Constraint Stress)

• 现象描述：Editorial 模式容易触发 LAYERED_POINTS 或 EDITORIAL_CLASSIC 样式。
• 深层原因：在 services/geminiService.ts 定义的 responseSchema 中，list 和 insights 的属性非常繁多。当文本源数据（Source Text）逻辑性极强时，模型会试图在每一个字段中填入高质量内容。
• 卡顿点：如果生成的 JSON 字符串由于内容过多导致截断（Token Limit Hit），JSON.parse 就会抛出异常。虽然代码有 try-catch，但在某些极端情况下，不完整的 JSON 块可能导致前端 UI 状态更新异常，表现为“一直处于加载中”的假死状态。

4. 导出逻辑的预渲染开销 (Export Pre-rendering Overhead)

• 现象描述：App 组件中有 downloadHtml 逻辑，其包含了复杂的 html2canvas 模拟逻辑。
• 深层原因：即使没有点击下载，App.tsx 中的 cardRefs 也在实时监听 DOM。EDITORIAL 模式下由于 DOM 节点数（Node Count）远超 FASHION 模式，React 的 useRef 追踪和虚拟 DOM 比对开销在低配设备上会造成肉眼可见的卡顿。

---

📝 结论与优化建议

结论：这不是代码逻辑死循环，而是 “模型推理长文本生成的长尾延迟” 与 “复杂宋体排版带来的渲染层性能衰减” 共同作用的结果。

后续优化方向（无需动代码，仅供参考）：

1. 缩短输入量：建议将 Editorial 模式的输入文本控制在 1500 字以内，以降低模型推理负担。
2. 字体降级测试：在本地尝试暂时屏蔽 constants.ts 中的 Noto Serif SC，观察若切换为系统默认宋体是否还卡顿。
3. 增加 Token 监控：目前 ThinkingBudget 为 0，对于 EDITORIAL 这种重逻辑模式，可能需要适度的推理预算来确保 JSON 结构的稳定性，防止由于模型输出“纠结”导致的进程挂起。

该报告旨在解释为何 FASHION（轻量级、短文本、英文字体为主）能跑通，而 EDITORIAL（重量级、长文本、中文字库大、SVG 滤镜多）会卡顿。