前端框架面试里，生命周期、响应式、虚拟 DOM 这些基础会被问，但项目面更常见的追问是：这个页面组件怎么拆？状态放在哪里？表单为什么这么复杂？为什么一次输入导致整页重渲染？接口加载中和失败状态怎么处理？
如果回答只停留在框架概念，面试官很难判断你的工程能力。前端项目真正复杂的地方，往往是页面长期迭代后仍然能维护。
组件拆分先看变化原因
组件不是越小越好，也不是按页面视觉随便切。一个实用原则是看变化原因：这块 UI 是否独立复用，状态是否独立，业务规则是否独立，未来是否会单独变化。比如筛选区、表格、分页、批量操作、详情抽屉，通常可以拆出边界。
但如果只是为了拆而拆，父子组件之间传大量参数，反而会增加理解成本。面试里可以讲你如何在复用和可读性之间取舍。
状态归属是高频追问
状态应该放在哪里，取决于谁使用它。只影响单个输入框的状态，放在组件内部；多个兄弟组件共享的筛选条件，可以提升到共同父组件；跨页面共享的用户信息、权限、主题，可以放在全局状态；接口缓存则可以用专门的数据请求层管理。
很多项目变复杂，是因为所有状态都往全局塞。全局状态看似方便，实际会让依赖关系变得模糊，任何页面都可能影响任何页面。面试里能主动讲这个风险，会显得更成熟。
表单复杂度要讲校验和联动
后台系统面试经常会问复杂表单。难点不只是输入框多，而是字段联动、动态校验、权限控制、草稿保存、提交前二次确认和错误回显。回答时可以讲如何拆分表单模块、统一校验规则、处理异步选项、避免重复提交。
如果项目里有多步骤表单，还要说明每一步的数据如何保存，用户返回上一步会不会丢失，提交失败后能否保留输入内容。这些细节很贴近真实工作。
渲染性能要回到具体页面
前端性能不是只说缓存和懒加载。在框架项目里，常见问题是状态变化范围太大、列表渲染太多节点、计算属性过重、组件重复请求接口。面试里可以讲如何定位：看组件渲染次数、浏览器性能面板、接口请求记录和用户操作耗时。
一段项目表达可以是：我负责的管理后台列表页最初把筛选、表格、弹窗状态都放在父组件，导致输入筛选条件时整页频繁重渲染。后来把弹窗和表格行操作状态下沉，筛选输入做防抖，列表改分页并缓存查询条件，同时把接口加载、失败和空状态统一处理。这个改动不是追求框架技巧，而是降低页面维护成本和用户等待感。
前端框架面试的重点，最终会回到你能不能把页面复杂度控制住。
组件和状态要讲变化来源
前端框架题不要只讲生命周期和响应式。项目面更常问的是：为什么这样拆组件，状态放父组件还是子组件，哪些状态进全局，哪些只是局部交互。
组件怎么拆：判断依据是变化原因和复用边界，常见错误是按视觉区域硬拆，更稳做法是按职责和状态边界拆。状态放哪里：判断依据是谁读取、谁修改，常见错误是所有状态都全局化，更稳做法是尽量靠近使用方。
- 表单怎么管理：判断依据是校验、联动、异步选项，常见错误是每个字段散写逻辑，更稳做法是统一模型和校验规则。
- 渲染性能：判断依据是哪些变化导致重渲染，常见错误是盲目 memo，更稳做法是先定位再优化。
面试里可以补一个页面例子，比如筛选表单、列表和详情抽屉如何共享查询条件。具体页面比抽象概念更能证明你做过复杂交互。