本系列导航
- 上一篇:第三十一章:技术架构总览
- 下一篇:第三十三章:后端 API 与任务架构
- 返回目录:Birdor 商业计划书目录
本章关键词
前端架构、工具页模板、编辑器、错误提示、相关工具、SEO、埋点、组件复用、性能优化、可访问性。
适合阅读的人
- 负责 Birdor 前端架构和工具页开发的技术负责人。
- 需要设计可复用工具页组件体系的前端工程师。
- 研究开发者工具 SaaS 前端最佳实践的技术决策者。
本章摘要
Birdor 的前端是用户第一接触点。工具页必须打开快、首屏可用、输入输出稳定、错误提示清楚,同时还能承载 SEO 内容、相关工具、AI 增强和 Pro 转化。
前端架构的核心不是做漂亮页面,而是建立一套可复用工具页模板,让 JSON、JWT、Regex、Log、Config 等工具都能用统一结构快速发布和维护。本章详细拆解工具页模板、组件划分、编辑器策略、错误模型、SEO 结构、埋点体系和性能优化。
32.1 工具页总览
每个 Birdor 工具页遵循统一信息架构:
工具页信息架构:
├── Hero/标题区(H1 + 简短描述)
├── 工具核心区(首屏必须可见)
│ ├── 输入区
│ ├── 操作按钮区
│ └── 输出结果区
├── 辅助区
│ ├── 错误提示面板
│ ├── 隐私说明
│ └── 相关工具推荐
├── AI/Pro 扩展区
│ ├── AI 增强入口
│ └── Pro 升级提示
└── SEO 内容区(工具下方)
├── 工具说明
├── 使用指南
├── 常见问题
└── API 说明
首屏优先工具,不要让长篇说明压住输入区。SEO 内容在工具下方,不影响任务完成。
32.2 核心组件体系
前端组件按职责分层:
布局层
| 组件 | 职责 | 复用度 |
|---|---|---|
| ToolLayout | 工具页整体布局、Grid 结构 | 100% |
| ToolHeader | 标题、描述、面包屑 | 100% |
| ToolFooter | SEO 内容容器、延伸阅读 | 100% |
| SplitPane | 输入/输出左右分栏(桌面端) | 80% |
输入层
| 组件 | 适用工具 | 特性 |
|---|---|---|
| CodeEditor | JSON/YAML/XML/SQL | 语法高亮、自动补全、错误标记 |
| TextInput | JWT/Base64/URL/Hash | 纯文本、大输入、粘贴友好 |
| RegexInput | Regex Generator | 目标描述 + 样例输入 |
| LogInput | Log Analyzer | 大文本 + 元数据字段 |
| FormInput | Config Generator | 表单 + 文本混合 |
| FileUploader | 图片/文件工具 | 拖拽上传、大小限制 |
输出层
| 组件 | 职责 | 特性 |
|---|---|---|
| OutputViewer | 通用输出展示 | 格式化、高亮、复制、下载 |
| DiffViewer | 对比类工具 | 差异高亮、行号、合并 |
| TableViewer | 表格类输出 | 排序、筛选、导出 CSV |
| JsonTree | JSON 结构化展示 | 折叠、路径、类型标注 |
| TestResult | 正则/测试类 | 匹配高亮、通过/失败标记 |
交互层
| 组件 | 职责 |
|---|---|
| ActionBar | 执行、清空、复制、下载、示例加载 |
| ErrorPanel | 错误展示、位置标记、修复建议 |
| PrivacyNotice | 本地/服务端/AI 处理说明 |
| RelatedTools | 相关工具推荐卡片 |
| AiAssistPanel | AI 增强入口、结果展示 |
| ProUpgradeHint | Pro 功能提示(非强制) |
32.3 编辑器策略
不同工具需要不同输入组件,但应遵循统一设计规范:
编辑器选型矩阵
| 工具类型 | 推荐编辑器 | 库选择 | 体积预算 |
|---|---|---|---|
| JSON/YAML/XML | 代码编辑器 | Monaco Editor / CodeMirror 6 | < 500KB (懒加载) |
| JWT/Base64/文本 | 文本域(增强版) | 自定义 TextArea | < 50KB |
| Regex | 结构化表单 | 自定义 React 组件 | < 30KB |
| Log | 大文本域 | 虚拟滚动 TextArea | < 100KB |
| Config | 表单 + 代码切换 | React Hook Form + CodeMirror | < 300KB |
| Markdown | 分屏预览 | CodeMirror + Markdown-it | < 400KB |
编辑器通用功能
所有编辑器必须支持:
- 粘贴自动检测:粘贴 JSON 后自动识别格式。
- 示例加载:一键加载典型示例(正常/错误/复杂)。
- 清空重置:快速清空并恢复初始状态。
- 历史回退:撤销/重做(至少 10 步)。
- 大小提示:实时显示输入字符/行数。
- 错误高亮:解析错误时标记位置。
- 移动端适配:虚拟键盘不遮挡操作按钮。
32.4 错误提示系统
错误提示是工具可信度核心。前端需要统一错误模型:
// 统一错误模型
interface ToolError {
code: string; // 错误码,如 "invalid_json", "jwt_malformed"
severity: 'error' | 'warning' | 'info';
title: string; // 简短标题
message: string; // 详细说明
location?: { // 错误位置(代码类工具)
line: number;
column: number;
length?: number;
};
suggestion?: string; // 修复建议
canFixWithAI?: boolean; // 是否可用 AI 修复
docLink?: string; // 相关文档链接
}
错误展示层级
| 严重程度 | 视觉处理 | 用户行动 |
|---|---|---|
| Error(红色) | 阻断操作,高亮位置 | 必须修复后才能继续 |
| Warning(黄色) | 非阻断,提示风险 | 建议检查但可继续 |
| Info(蓝色) | 提示性信息 | 了解即可 |
JSON、YAML、JWT、Regex 等工具可以用同一 ErrorPanel 展示不同错误,保持体验一致性。
32.5 SEO 与内容结构
工具页的 SEO 内容应在工具下方,采用结构化标记:
<!-- 工具页结构化数据示例 -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebApplication",
"name": "JSON Formatter",
"description": "Format and validate JSON online",
"applicationCategory": "DeveloperApplication",
"operatingSystem": "Any",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD"
}
}
</script>
SEO 内容区域结构
| 区域 | 内容 | 长度建议 |
|---|---|---|
| 工具说明 | 这是什么工具、解决什么问题 | 100-200 字 |
| 使用指南 | 步骤说明、示例、截图 | 200-500 字 |
| 常见错误 | 典型错误和修复方法 | 150-300 字 |
| 隐私说明 | 数据处理边界 | 100-200 字 |
| API 说明 | API 端点和基本用法 | 100-300 字 |
| FAQ | 3-5 个常见问题 | 300-800 字 |
页面 metadata 从工具配置生成,避免每个页面手写不一致。
32.6 埋点体系
前端至少记录以下事件:
工具使用事件
| 事件 | 触发时机 | 用途 |
|---|---|---|
| page_view | 页面加载 | SEO 流量分析 |
| sample_click | 点击示例 | 示例质量评估 |
| tool_run | 执行工具操作 | 工具活跃度 |
| tool_success | 操作成功完成 | 完成率 |
| tool_error | 操作失败 | 错误率 |
| copy_output | 复制结果 | 输出价值 |
| download_output | 下载结果 | 输出价值 |
| clear_input | 清空输入 | 使用模式 |
导航事件
| 事件 | 触发时机 | 用途 |
|---|---|---|
| related_tool_click | 点击相关工具 | 工作流连接 |
| ai_assist_click | 点击 AI 增强 | AI 功能采用 |
| pro_trigger_view | 看到 Pro 提示 | 商业化曝光 |
| pro_trigger_click | 点击 Pro 提示 | 商业化转化 |
| api_docs_click | 点击 API 文档 | API 需求 |
性能事件
| 事件 | 触发时机 | 阈值 |
|---|---|---|
| fcp | 首次内容绘制 | 目标 < 1.2s |
| lcp | 最大内容绘制 | 目标 < 2.5s |
| tti | 可交互时间 | 目标 < 3.5s |
| tool_exec_time | 工具执行完成 | 目标 < 50ms |
32.7 性能优化策略
工具页性能直接影响用户体验和 SEO。
关键优化点
| 优化项 | 策略 | 目标 |
|---|---|---|
| 首屏 JS 体积 | 路由级 Code Splitting | 首包 < 150KB |
| 编辑器懒加载 | 动态 import,非首屏工具延迟加载 | 首屏不含编辑器代码 |
| AI 面板懒加载 | 点击 AI 按钮后再加载 AI 组件 | 首屏不含 AI 组件 |
| 图片优化 | WebP/AVIF、懒加载、响应式 | LCP < 2.5s |
| 大输入处理 | Web Worker 处理大文本 | 避免主线程卡死 |
| 缓存策略 | Service Worker 缓存静态资源 | 二次访问 < 1s |
| SSR/SSG | 工具页预渲染 | 首屏可索引 |
性能预算
| 指标 | 预算 | 监控方式 |
|---|---|---|
| First Contentful Paint | < 1.2s | Lighthouse |
| Largest Contentful Paint | < 2.5s | Lighthouse |
| Time to Interactive | < 3.5s | Lighthouse |
| Cumulative Layout Shift | < 0.1 | Lighthouse |
| Total Blocking Time | < 200ms | Lighthouse |
| 工具执行耗时 P95 | < 50ms | 自定义埋点 |
32.8 移动端适配
开发者越来越多地在移动设备上使用工具页(查看日志、快速验证 JSON 等)。
移动端设计原则
| 原则 | 实现 |
|---|---|
| 单栏布局 | 输入在上,输出在下 |
| 大触摸目标 | 按钮最小 44x44px |
| 键盘友好 | 输入框聚焦时操作按钮不遮挡 |
| 横向滚动避免 | 所有内容垂直排列 |
| 快速操作 | 支持长按复制、滑动切换 |
32.9 可访问性(a11y)
| 要求 | 实现 |
|---|---|
| 键盘导航 | Tab 顺序合理,Enter 执行 |
| 屏幕阅读器 | 所有操作有 aria-label |
| 颜色对比度 | WCAG AA 标准(4.5:1) |
| 焦点可见 | 焦点状态清晰可见 |
| 错误 Announce | 错误出现时有 aria-live 通知 |
32.10 配置驱动页面生成
为提高效率,Birdor 工具页应使用配置驱动:
// 工具页配置示例
const toolConfig = {
id: 'json-formatter',
slug: 'json-formatter',
title: 'JSON Formatter',
description: 'Format and validate JSON online',
category: 'data-format',
inputType: 'code-editor',
outputType: 'json-tree',
languages: ['json'],
features: ['format', 'validate', 'minify', 'beautify'],
aiEnabled: true,
apiEnabled: true,
examples: [
{ name: 'Simple Object', input: '{"a":1}' },
{ name: 'Nested Array', input: '[{"name":"test"}]' },
{ name: 'Invalid JSON', input: '{a:1}', isError: true }
],
relatedTools: ['json-to-yaml', 'json-to-typescript', 'json-schema-generator'],
privacy: 'local-processing',
seo: {
keywords: ['JSON formatter', 'JSON validator', 'format JSON'],
faq: [
{ q: 'What is JSON formatter?', a: '...' }
]
}
};
配置驱动的好处:新增工具只需写配置,无需新建页面组件;SEO 内容自动从配置生成;A/B 测试可通过配置快速切换。
32.11 本章结论
Birdor 前端架构应围绕可复用工具页模板构建。统一布局、编辑器、错误提示、隐私说明、相关工具和埋点,可以让 Birdor 快速扩展工具矩阵,同时保持专业体验。
核心设计原则:首屏可用 > 视觉炫技;确定性响应 > AI 延迟;组件复用 > 独立开发;性能预算 > 功能堆砌。
32.12 开发落地清单
前端第一批任务可以拆成:
| 优先级 | 任务 | 时间估算 |
|---|---|---|
| P0 | ToolLayout 通用布局 + 路由 | 3 天 |
| P0 | Tool metadata 配置系统 | 2 天 |
| P0 | InputEditor(CodeEditor + TextInput) | 5 天 |
| P0 | OutputViewer + ActionBar | 3 天 |
| P0 | ErrorPanel + 错误模型 | 2 天 |
| P0 | PrivacyNotice | 1 天 |
| P1 | RelatedTools | 2 天 |
| P1 | Event tracking helper | 2 天 |
| P1 | AI Panel 懒加载 | 2 天 |
| P2 | 移动端适配优化 | 3 天 |
| P2 | a11y 审查 | 2 天 |
| P2 | 性能优化 + Lighthouse CI | 3 天 |
四个样板页覆盖后,后续工具页扩展会更稳定:
- JSON Formatter:数据格式工具样板。
- JWT Decoder:安全工具样板。
- AI Regex Generator:AI 增强工具样板。
- AI Log Analyzer:长文本分析工具样板。
32.13 前端技术栈建议
| 层级 | 技术选择 | 理由 |
|---|---|---|
| 框架 | Next.js 14+ (App Router) | SSR/SSG、API Routes、性能优化 |
| 语言 | TypeScript | 类型安全、可维护性 |
| 样式 | Tailwind CSS | Utility-first、Tree-shaking |
| UI 组件 | Radix UI + 自定义 | 可访问性 + 自定义样式 |
| 状态管理 | Zustand / React Context | 轻量、TypeScript 友好 |
| 编辑器 | CodeMirror 6 | 轻量、模块、移动端友好 |
| 图表 | 自定义 Canvas | 工具页无需重图表库 |
| 测试 | Vitest + Playwright | 单元测试 + E2E |
| 构建 | Next.js 内置 + SWC | 速度 |
FAQ
Q1: 为什么不用 Monaco Editor(VS Code 同款)?
Monaco 功能强但体积大(> 2MB)。对于 Birdor 大部分工具,CodeMirror 6 更轻量(< 500KB)、启动更快、移动端支持更好。只有需要高级 IDE 功能的工具才考虑 Monaco。
Q2: 工具页应该客户端渲染还是服务端渲染?
工具核心功能(输入输出)是客户端交互,但页面框架和 SEO 内容应 SSR/SSG。推荐 Next.js App Router:页面静态生成(SSG),工具交互在客户端水合(Hydration)。
Q3: 如何确保新增工具的页面 SEO 自动优化?
配置驱动。每个工具的配置中包含 title、description、keywords、faq 等 SEO 字段,页面渲染时自动注入 meta 标签和结构化数据。
Q4: 移动端体验是否值得投入?
值得。数据显示 20-30% 的开发者工具访问来自移动设备。虽然复杂任务在桌面完成,但查看、验证、分享等轻量操作在移动端很常见。移动端体验差会直接流失这部分用户。
Q5: 前端组件复用率目标多少?
新工具页开发时,自定义代码应 < 20%,复用组件 > 80%。如果新工具需要大量自定义组件,说明通用组件设计有缺陷,应该回滚到组件层优化。
延伸阅读
- AI 时代全球开发者工具平台目录
- 第三十一章:技术架构总览
- 第三十三章:后端 API 与任务架构
- 第三十六章:可观测性与 SRE 计划
- 第三十五章:隐私、安全与数据策略
- Birdor JSON Formatter 实现规格:页面结构与状态机设计
32.14 工具页性能基准测试方法论
Lighthouse 性能审计清单
每个工具页上线前应通过以下性能审计:
| 审计项 | 目标 | 工具 |
|---|---|---|
| Performance Score | > 90 | Lighthouse CI |
| First Contentful Paint | < 1.2s | Lighthouse |
| Largest Contentful Paint | < 2.5s | Lighthouse |
| Total Blocking Time | < 200ms | Lighthouse |
| Cumulative Layout Shift | < 0.1 | Lighthouse |
| Time to Interactive | < 3.5s | Lighthouse |
| 首包 JS 体积 | < 150KB | webpack-bundle-analyzer |
| 目标工具执行时间 | < 50ms | 自定义埋点 |
性能基准测试脚本
# Lighthouse CI 配置示例
# .lighthouserc.json
{
"ci": {
"collect": {
"url": ["https://birdor.com/tools/json-formatter"],
"numberOfRuns": 3
},
"assert": {
"assertions": {
"categories:performance": ["error", { "minScore": 0.9 }],
"first-contentful-paint": ["error", { "maxNumericValue": 1200 }],
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }]
}
}
}
}
32.15 工具页 SEO 实施细节
结构化数据完整示例
{
"@context": "https://schema.org",
"@type": "WebApplication",
"name": "Birdor JSON Formatter",
"description": "Format, validate and beautify JSON online with syntax highlighting",
"applicationCategory": "DeveloperApplication",
"operatingSystem": "Any",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD"
},
"featureList": [
"JSON syntax highlighting",
"Real-time validation",
"Minify and beautify",
"Error location marking",
"API access"
],
"screenshot": {
"@type": "ImageObject",
"url": "https://birdor.com/images/json-formatter-screenshot.png"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"ratingCount": "1250"
}
}
页面 metadata 模板
<!-- 工具页 metadata 应由配置自动生成 -->
<title>JSON Formatter - Format and Validate JSON Online | Birdor</title>
<meta name="description" content="Format, validate and beautify JSON online...">
<meta name="keywords" content="json formatter, json validator, format json, json beautifier">
<link rel="canonical" href="https://birdor.com/tools/json-formatter">
<meta property="og:title" content="JSON Formatter - Birdor">
<meta property="og:description" content="Format and validate JSON online...">
<meta property="og:type" content="website">
<meta property="og:url" content="https://birdor.com/tools/json-formatter">
<meta property="og:image" content="https://birdor.com/og/json-formatter.png">
<meta name="twitter:card" content="summary_large_image">
32.16 前端状态管理策略
工具页状态分层
// 全局状态(用户级别)
interface UserState {
isLoggedIn: boolean;
plan: 'free' | 'pro' | 'pro+';
aiCreditsRemaining: number;
apiQuota: number;
}
// 工具级别状态
interface ToolState {
input: string;
output: string;
error: ToolError | null;
isProcessing: boolean;
history: string[];
settings: ToolSettings;
}
// 临时 UI 状态(不需要持久化)
interface UIState {
activePanel: 'input' | 'output' | 'settings';
showExamples: boolean;
sidebarCollapsed: boolean;
}
状态持久化策略
| 状态 | 存储位置 | 持久化 | 同步方式 |
|---|---|---|---|
| 用户登录态 | localStorage | 是 | 应用启动时 |
| Pro 功能可用性 | 内存 + API 轮询 | 否 | 每次请求 |
| 工具输入/输出 | localStorage(最近3条) | 是 | 操作后 |
| 工具设置 | IndexedDB | 是 | 变更后 |
| 主题偏好 | localStorage | 是 | 即时 |
32.17 前端安全考虑
输入安全
| 威胁 | 防护 | 实现 |
|---|---|---|
| XSS(恶意输入) | 输出时转义 HTML | DOMPurify 或手动转义 |
| 原型链污染 | 安全 JSON parse | reviver 函数过滤 proto |
| 超大输入 | 大小限制 + 警告 | 前端 + 后端双重校验 |
| ReDoS(正则拒绝服务) | 正则执行超时 | Web Worker + 超时机制 |
| 敏感数据泄露 | 本地处理提示 | 明确的隐私说明 |
第三方依赖安全
# 定期扫描依赖漏洞
npm audit
# 或者使用更专业的工具
npx better-npm-audit audit
32.18 前端监控与告警
前端错误监控
| 监控项 | 工具 | 告警阈值 |
|---|---|---|
| JS 错误率 | Sentry | > 0.1% 请求 |
| API 错误率 | Sentry + 后端 | > 1% 调用 |
| 性能退化 | Lighthouse CI | Score < 85 |
| Core Web Vitals | Google Search Console | LCP > 2.5s |
用户行为监控
| 行为 | 用途 | 隐私 |
|---|---|---|
| 工具使用频次 | 识别热门/冷门工具 | 匿名,聚合 |
| 错误发生位置 | 定位 UX 问题 | 匿名,去标识 |
| 转化漏斗 | 优化 Pro 转化 | 匿名,漏斗级 |
| 热力图 | 优化布局 | 采样,匿名 |
32.19 前端到后端的接口契约
API 响应标准格式
interface ApiResponse<T> {
success: boolean;
data?: T;
error?: {
code: string;
message: string;
details?: unknown;
};
meta?: {
requestId: string;
processingTime: number; // ms
aiCreditsUsed?: number;
};
}
错误码规范
| Code | HTTP | 含义 | 前端处理 |
|---|---|---|---|
| invalid_input | 400 | 输入格式错误 | 显示错误面板 |
| quota_exceeded | 429 | 配额耗尽 | Pro 升级提示 |
| rate_limited | 429 | 速率限制 | 倒计时后重试 |
| server_error | 500 | 服务器错误 | 友好错误页 |
| ai_timeout | 504 | AI 处理超时 | 重试或降级 |
32.20 进阶 FAQ 补充
Q6: 前端如何处理超大 JSON(>10MB)?
使用 Web Worker 解析,避免阻塞主线程。超过 Pro 限制时提示升级。对于 >100MB 的文件,建议使用 API 端点处理。
Q7: 工具页是否支持离线使用?
核心格式化/转换工具可以通过 Service Worker 缓存实现离线使用。但 AI 功能和 API 调用需要网络连接。
Q8: 如何实现多语言国际化?
配置驱动的文本替换:每个工具配置包含多语言字段。英语为默认语言,中文为第二阶段。注意:SEO 内容建议单独路由(/zh/json-formatter)。
Q9: 前端如何处理 A/B 测试?
使用特征标志(Feature Flag)服务,或者简单的客户端随机分组。注意:A/B 测试分组需要在首次访问时确定并持久化。
Q10: 如何确保工具页在旧浏览器上的兼容性?
目标浏览器:Chrome 90+, Firefox 88+, Safari 14+, Edge 90+。使用 polyfill.io 按需加载 polyfill。核心功能(格式化)不应依赖现代 API。
32.14 实际工具站前端性能对比
为了设定合理的性能目标,参考以下真实数据:
| 工具站 | FCP | LCP | TTI | 首包大小 | 编辑器 |
|---|---|---|---|---|---|
| jsonformatter.org | 1.8s | 2.4s | 3.1s | 120KB | 无(纯文本) |
| jsoncrack.com | 2.2s | 3.8s | 4.5s | 350KB | 自定义 Canvas |
| regex101.com | 1.5s | 2.1s | 2.8s | 180KB | CodeMirror |
| jwt.io | 1.9s | 2.6s | 3.3s | 210KB | 自定义 |
| Birdor 目标 | <1.2s | <2.5s | <3.5s | <150KB | CodeMirror 6 |
Birdor 的性能目标应该比现有工具站更好,原因有二:一是开发者对性能更敏感,二是性能直接影响 SEO 排名。Google 的 Core Web Vitals 已成为搜索排名因素。
32.15 组件状态管理策略
工具页的状态管理看似简单(输入、输出、状态),但随着功能扩展会变得复杂:
| 状态类型 | 管理方案 | 示例 |
|---|---|---|
| 本地 UI 状态 | React useState / useReducer | 当前 tab、展开/折叠 |
| 工具数据状态 | Zustand Store(按工具隔离) | 输入、输出、历史 |
| 全局用户状态 | React Context / Auth Store | 登录状态、Pro 等级、额度 |
| 服务器状态 | SWR / React Query | API 调用结果、用户配置 |
| 表单状态 | React Hook Form | AI 生成参数、配置表单 |
关键原则:避免把所有状态都放到全局 Store。工具页数据应该按工具隔离,防止一个工具的状态污染另一个工具。
32.16 主题与品牌化
Birdor 需要一套统一的设计系统:
| 元素 | 规范 | 说明 |
|---|---|---|
| 主色调 | #0F172A(深 slate) | 稳重、专业、减少视觉疲劳 |
| 强调色 | #3B82F6(蓝) | 操作按钮、链接 |
| 成功色 | #10B981(绿) | 验证通过、复制成功 |
| 错误色 | #EF4444(红) | 解析错误、校验失败 |
| 警告色 | #F59E0B(黄) | 非致命提示 |
| 字体 | Inter / system-ui | 英文 + 中文回退 |
| 代码字体 | JetBrains Mono / Fira Code | 等宽、可读性好 |
| 圆角 | 工具区 8px,按钮 6px | 现代但不夸张 |
| 阴影 | 轻量级,用于层级区分 | 不用于装饰 |
主题系统应支持深色模式。开发者工具在夜间使用频率高,深色模式不是"可选"而是"必须"。
32.17 深色模式实现要点
| 要点 | 浅色 | 深色 |
|---|---|---|
| 背景 | #FFFFFF | #0F172A |
| 卡片 | #F8FAFC | #1E293B |
| 边框 | #E2E8F0 | #334155 |
| 正文 | #1E293B | #F1F5F9 |
| 次要文字 | #64748B | #94A3B8 |
| 输入区 | #FFFFFF | #0F172A |
| 代码背景 | #F1F5F9 | #1E293B |
使用 CSS 变量或 Tailwind 的 dark 模式,确保切换时无闪烁。
32.18 错误恢复机制
前端错误不应导致整个页面崩溃:
| 错误场景 | 恢复策略 |
|---|---|
| JSON 解析失败 | 保留输入,显示具体错误位置 |
| 网络超时(AI) | 显示"AI 响应超时,请重试",保留输入 |
| 浏览器兼容性 | 降级为纯文本输入,提示"建议升级浏览器" |
| 内存不足(大文件) | 提示"文件过大,建议使用批量处理或 API" |
| 复制失败 | 提示手动选择复制 |
| 编辑器加载失败 | 降级为 textarea,提示"基础模式" |
每个工具页都应该有一个 Error Boundary,捕获未预料的 React 错误并显示"出现意外错误,请刷新或联系我们"的友好提示。
FAQ 补充
Q6: Monaco Editor 和 CodeMirror 6 到底选哪个?
最终建议:Birdor 的统一编辑器用 CodeMirror 6。理由:体积更小(基础 < 200KB vs Monaco > 2MB)、移动端支持更好、模块更灵活。只有当某个工具确实需要 Monaco 的 IntelliSense、Debugger 等 IDE 级功能时才考虑 Monaco,且应懒加载。
Q7: 工具页需要支持 PWA 吗?
建议第二阶段支持。PWA 的好处是"添加到主屏幕"后可以离线使用基础工具(JSON format、Base64 等本地处理工具)。但 PWA 不等于 App 替代,它的价值在于减少每次访问的加载时间。
Q8: 前端如何处理多工具共享状态?
使用 URL 参数和 localStorage 组合方案:当前工具状态存在 URL query 中(便于分享),用户偏好(主题、默认缩进)存在 localStorage 中,登录用户的数据存在服务端。不要所有状态都堆到全局 Store。
Q9: 是否需要服务端渲染(SSR)?
建议用 Next.js 的 SSG(静态生成)而非 SSR。工具页的内容相对静态,SSG 可以得到 SSR 的 SEO 好处,同时避免了 SSR 的复杂性和成本。只有用户特定的动态内容(如历史记录)才在客户端获取。
Q10: 前端架构和性能优化的投入回报率怎么衡量?
直接指标是 Core Web Vitals 评分和搜索排名变化。间接指标是工具完成率和回访率。如果一个性能优化让 LCP 从 3s 降到 1.5s,但完成率没有提升,说明性能不是当前瓶颈。优先做"性能差到影响使用"的修复,而不是"锦上添花"的优化。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。