前端工程服务异常时如何分层降级

前端工程服务异常时如何分层降级

很多团队做生成式 UI（Generative UI）时，一开始就想造一套替代前端框架的万能引擎：用户输入一句话，AI 便生成带复杂状态管理、弹窗交互和国际化的整套 React 代码。

实际接入时，LLM 输出可能不符合 JSON 协议，过深的动态组件树也会增加渲染和排查成本。

生成式 UI 的第一版 MVP（Minimum Viable Product），重点在于裁剪与降级。先搭好可校验、可降级的渲染链路，再接入不确定的生成能力。

1. 为什么不应直接执行大模型生成的 JSX？

有些技术文章建议让大模型输出字符串形式的 React JSX，再用 eval() 或 new Function() 动态执行。这种方式不适合直接用于生产环境。

XSS 攻击风险暂且不说，最致命的是大模型根本无法保证 JSX 语法的闭合性。在流式输出（Streaming）的过程中，只要缺少一个闭合标签 </div>，你的整个 React 渲染树就会当场崩溃报错。

生成式 UI 不应让大模型直接操控 DOM 或执行代码。模型只输出抽象的数据协议（Schema）；DOM 绘制、事件监听和样式渲染则由前端预置的组件白名单完成。

大模型负责决定“画什么”，前端引擎负责决定“怎么画”。把渲染权牢牢握在前端手心里，系统才有了最基础的安全底线。

2. 核心链路的三层拆解：协议、校验与受控渲染

在设计第一版 MVP 引擎时，我们把整体链路拆解为三个独立的模块：

下面这套 TypeScript 与 React 结合的 MVP 渲染引擎实现，演示了如何在生产环境中安全地解析并渲染 AI 动态生成的 Schema。

import React, { useMemo } from 'react';
import { z } from 'zod';

// 1. 定义严密的生成式 UI Component Schema
export const ComponentSchema: z.ZodType<any> = z.lazy(() =>
z.object({
id: z.string(),
type: z.string(),
props: z.record(z.any()).optional(),
children: z.array(ComponentSchema).optional(),
})
);

export type UISchema = z.infer<typeof ComponentSchema>;

// 2. 注册预置的受控组件白名单
const ComponentRegistry: Record<string, React.FC<any>> = {
Card: ({ title, children }) => (
<div style={{ border: '1px solid #e5e7eb', borderRadius: 8, padding: 16, marginBottom: 12 }}>
{title && <h4 style={{ margin: '0 0 8px 0', fontSize: 16 }}>{title}</h4>}
{children}
</div>
),
Button: ({ label, variant = 'primary', onClickKey }) => (
<button
onClick={() => console.log(`Trigger Action: ${onClickKey}`)}
style={{
background: variant === 'primary' ? '#2563eb' : '#9ca3af',
color: '#fff',
border: 'none',
padding: '6px 12px',
borderRadius: 4,
cursor: 'pointer',
}}
>
{label}
</button>
),
Text: ({ content, color = '#374151' }) => <p style={{ color, margin: '4px 0' }}>{content}</p>,
};

// 兜底占位组件
const FallbackComponent: React.FC<{ type: string }> = ({ type }) => (
<div style={{ padding: 8, background: '#fef2f2', border: '1px dashed #ef4444', color: '#b91c1c' }}>
无法渲染未授权组件: [{type}]
</div>
);

// 3. 安全渲染器组件
interface GenerativeUIRendererProps {
schemaRaw: string; // 允许传入流式 JSON 字符串
}

export const GenerativeUIRenderer: React.FC<GenerativeUIRendererProps> = ({ schemaRaw }) => {
// 安全解析 JSON
const parsedSchema = useMemo<UISchema | null>(() => {
try {
const json = JSON.parse(schemaRaw);
const validation = ComponentSchema.safeParse(json);
return validation.success ? validation.data : null;
} catch {
return null;
}
}, [schemaRaw]);

if (!parsedSchema) {
return <div style={{ color: '#6b7280', fontSize: 14 }}>动态 UI 渲染中或 Schema 结构损坏…</div>;
}

// 递归渲染 Node
const renderNode = (node: UISchema): React.ReactNode => {
const Component = ComponentRegistry[node.type] || (() => <FallbackComponent type={node.type} />);
const renderedChildren = node.children?.map(child => <React.Fragment key={child.id}>{renderNode(child)}</React.Fragment>);

return <Component {…(node.props || {})}>{renderedChildren}</Component>;
};

return <div className="gen-ui-container">{renderNode(parsedSchema)}</div>;
};

3. MVP 阶段应放弃的三个虚假需求

第一版上线前，产品侧通常还会提出更多能力诉求。MVP 阶段可先不支持：

第一，放弃任意自定义样式支持。不要允许大模型在 Schema 里传任意的 CSS 内联样式字符串。LLM 很容易写出 position: absolute; top: -9999px 这种把元素移出屏幕外的奇葩样式。所有的样式调整应收口为预定义好的 variant 枚举值（比如 primary、secondary、danger）。

第二，放弃复杂的多组件联动状态。如果在 MVP 里试图让 AI 生成带有类似 if (componentA.value > 10) componentB.hide() 的复杂逻辑，你的调试成本会呈指数级飙升。第一版的生成式 UI 只做数据展示与简单单向动作触发，复杂交互继续交由手写组件处理。

第三，限制嵌套深度。在渲染引擎中应显式设置 maxDepth 检查。过深的嵌套会增加递归渲染和 DOM 布局成本；具体上限应结合组件复杂度和设备性能压测确定。

4. 落地总结：先测量，后演进

第一版不必覆盖所有界面和交互类型，先验证协议、白名单和降级链路是否可用。

第一版 MVP 可以验证用户是否需要通过自然语言生成界面，也能统计流式传输中的 Schema 解析失败率。

上线前应约定可接受的解析失败率、降级成功率和响应时延，并以真实流量验证。达到这些目标后，再按需求扩充组件白名单或把解析移到 Web Worker。