摘要（Auto）

• 生成时间：2025-12-20
• 简历中出现的项目标题（提取）：大疆用户中心重构 / 大疆售后 RMS 系统重构 / 跨平台公告插件系统 / 大疆 DevOps 平台维护 / XDR 系统 - 魔方大屏 + 报表
• 面试大纲关键词（提取 Top10）：1）大疆用户中心重构：性能优化 + HTTP 原理 + Webpack 架构 / 性能指标与方法论 / 简历可落地点（结合你的“优化四板斧”） / HTTP 常考点（从“为什么变快”倒推） / Webpack 架构（工程化面试常考） / 按优化顺序，把方案“串起来”（排查 → 定位 → 选择 → 验证） / 0. 排查与基线（先把问题“量化”） / 1. 先保“可见”——骨架屏预渲染（直接拉低 LCP） / 2. 再减“阻塞”——关键渲染路径（CRP）梳理：CSS/字体/首图优先级 / 3. 再降“下载与解析成本”——更小的包体与更少的无效代码

建议追问（Auto）

• 你为什么在该项目/场景里选择这个方案？替代方案为何不选？
• 最大一次事故/踩坑是什么？如何定位与回滚？
• 如果重做：架构/边界/工程化会怎么调整？

关联卡片

• 项目：
  • project__dji-rms
  • project__xdr-dashboard-report
• 技术：
  • tech__react
  • tech__typescript

在我项目中的角色与使用场景

• 典型约束：
  • 中后台表单复杂（联动/校验/动态字段/权限字段），手写维护成本高且容易出错。
  • 希望把“表单能力”平台化：schema 驱动、可配置、可复用，同时还要保证性能与可调试性。
• 我做选型时关注：
  • 表达能力（联动/校验/布局/动态渲染）
  • 可维护性（schema 可读性、调试工具、扩展点）
  • 性能与体积（运行时成本、bundle 影响）
  • 迁移成本（与现有 UI 库/数据模型/权限体系的适配）

原理简述

三个方案的本质差异：

• Formily：
  • 更偏“表单领域框架”，表达能力强（联动/响应式字段/模型驱动），适合复杂中后台。
  • 代价：心智成本更高，需要团队掌握其 schema/响应式模型与最佳实践。
• RJSF（react-jsonschema-form）：
  • 基于 JSON Schema 驱动渲染，规范化强，适合“表单配置化/标准化”场景。
  • 代价：复杂联动/布局定制可能需要大量自定义，体验受限于 schema 能力。
• 自研无依赖表单：
  • 核心是“最小运行时 + 可控 DSL”，只覆盖你最常见的 80% 场景。
  • 代价：长期维护成本与功能边界要守住，否则会变成“半套 Formily”。

对比表格

维度	Formily	RJSF	自研无依赖表单
表达能力	强（联动/校验/动态）	中（受 JSON Schema 限制）	可定制但需控制边界
开发体验	中-高（但需学习）	中（配置直观）	取决于你设计的 DSL
性能/体积	中（引入框架成本）	中	可最小化
生态成熟度	高	中-高	取决于团队
迁移成本	中	中	中-高（要写很多基础设施）
风险与回滚	可控（按版本）	可控	风险在“需求膨胀导致维护失控”

模拟问答

• [ ] Q1：为什么最终选这个？反例是什么？
  • 推荐回答结构：Context → Problem → Solution → Outcome → Learnings

<<<<<<< Current (Your changes) <<<<<<< Current (Your changes)

• [ ] Q2：复杂联动/动态字段/权限字段，你怎么建模？为什么“schema 驱动”更适合平台化？

  • 口径：把“字段定义/校验/联动/可见性/权限”统一表达为 schema + rules，业务只写配置与少量扩展。
  • 好处：可复用、可审计、可做可视化编辑；联动逻辑不再散落在组件里。
  • 风险：schema 过度复杂会变成“另一种代码” → 必须有约束（DSL 设计、最佳实践、调试工具）。

• [ ] Q3：类型（TS）和运行时校验怎么配合？为什么只靠 TS 不够？

  • TS 只保证编译期；真实数据来自接口/用户输入仍是 unknown。
  • 方案：API 边界做运行时校验（zod/io-ts/自研）→ 把 unknown 收敛成 domain type，再进入表单/业务层。

• [ ] Q4：性能怎么治理？大表单为什么容易卡？你怎么定位与优化？

  • 常见瓶颈：字段多导致 render 频繁、联动触发链过长、校验同步阻塞主线程。
  • 定位：Profiler/Performance 看 commit 与 Long Task；记录联动触发链路与频率。
  • 优化：按域拆分表单、局部订阅（selector）、分片渲染/虚拟化、校验异步化与节流。

• [ ] Q5：迁移与回滚怎么做？如何避免“一次性替换导致大面积回归”？

  • 迁移：先从高复用场景（公共表单/简单表单）试点；保留旧方案旁路一段时间。
  • 回滚：表单引擎走开关（按页面/按模块），出现问题可快速切回旧实现。
  • 验证：用一组“表单用例集”（联动/校验/权限/回填）做回归矩阵。

Incoming (Background Agent changes)

Incoming (Background Agent changes) 可直接复述的回答（示例：选 Formily）：

• Context：中后台表单联动复杂、字段多、复用需求强。
• Problem：手写表单维护成本高、联动逻辑散落、回归难。
• Solution：Formily 提供更强的表单领域能力与扩展点；同时把 schema/联动规则沉淀为可复用资产。
• Outcome：交付更快、bug 更少、复杂联动可配置化（用口径描述即可）。
• 反例：表单很简单或团队不愿承担学习成本，RJSF 或轻量自研更合适。

手写代码区

（如适用：给出“最小概念验证”代码片段）

一个“无依赖表单 DSL”的最小思路（schema → 渲染 + 校验）：

type Field =
  | { name: string; type: 'text'; required?: boolean }
  | {
      name: string
      type: 'select'
      options: { label: string; value: string }[]
    }

type Schema = { fields: Field[] }

export function validate(schema: Schema, values: Record<string, any>) {
  const errors: Record<string, string> = {}
  for (const f of schema.fields) {
    if (f.required && (values[f.name] == null || values[f.name] === '')) {
      errors[f.name] = '必填'
    }
  }
  return errors
}

我的补充（Manual）

（不会被脚本覆盖：真实约束、组织因素、踩坑）

复盘与反思（Learnings）

• 如果重做会怎么改？

面试官追问（面试官视角）

• [ ] 为什么选这个方案？替代方案为什么不选？
• [!] 最大一次事故/踩坑是什么？如何定位与回滚？
• [ ] 如果重做会怎么改？