在开发心理普查系统时，前端工程师需要处理不同规模的问卷渲染。对于几十道题的基础问卷，常规的列表渲染方式能够很好地工作；但当面对专业的临床心理评估工具，例如包含五百多道题目的明尼苏达多项人格测验（MMPI）时，数据量和 DOM 节点数会发生质变。
如果将数百道题目的数据作为一个完整的对象或数组交由 Vue 的 data() 管理，并在视图层进行双向绑定渲染，整个页面的响应速度会显著下降。用户在点击选项时，可能会遇到明显的延迟。
本文将探讨在长列表表单场景下，如何利用 Vue3 的 Composition API 和一些常见的优化策略来改善前端性能。
性能瓶颈：深度响应式的开销
在 Vue 默认的 ref 或 reactive 实现中，框架会递归地遍历对象的所有层级。如果传入一个包含数百道题目及选项的 JSON 数组，Vue 会为每一道题的 id、title 以及每个选项的 value 和 label 挂载 getter 与 setter（在 Vue3 中为 Proxy 代理）。
这个过程在初始化阶段会产生较大的计算开销，同时会在内存中保留大量的依赖关系。更为严重的是，由于整个对象树被深度监听，当用户仅仅修改某一道题的选中状态时，可能会触发比预期更大范围的响应式更新计算，这也是导致页面卡顿的核心原因之一。
浅层响应（ShallowRef）的应用
在橙星云的问卷引擎设计中，为了应对大规模题目的渲染，技术团队遵循了一个基本的原则：对静态数据避免使用深度响应式。
在题目数据中，“题目内容”和“选项文字”在加载后是不会发生变化的静态只读数据，唯一发生改变的是受测者的“选中答案”。基于这个特征，Vue3 提供的 shallowRef 成为了理想的选择。
“`javascript
import { shallowRef, ref } from ‘vue’;
// 题库配置：使用 shallowRef 避免内部属性被递归劫持
const questions = shallowRef(hugeScaleData);
// 答题状态：单独提取出来，用普通的 ref 对象存储
// 数据结构类似于：{ "q1": "A", "q2": "B" }
const answers = ref({});
function onSelectOption(questionId, optionValue) {
// 仅触发极其轻量的状态更新
answers.value[questionId] = optionValue;
}
“`
通过物理上分离“大体量的静态题库数据”和“轻量级的读写状态”，前端应用能够有效规避 Proxy 深度劫持带来的性能开销。
虚拟列表（Virtual List）的配合
除了响应式系统本身，大量的 DOM 节点也是拖累性能的关键因素。几百道题目意味着数以千计的 DOM 元素，将它们一次性全部挂载到渲染树中，在配置较低的移动设备上容易引发内存告警甚至页面崩溃。
为此，引入虚拟列表技术是必要的。虚拟列表的核心思路是：无论数据源有多少项，只在浏览器的可视区域内渲染所需的 DOM 节点。当页面发生滚动时，前端代码通过监听滚动事件并结合计算，复用已存在于 DOM 树中的节点去更新对应的新数据。
开发者可以选择集成 VueUse 库中的 useVirtualList，或者根据项目需求定制化开发偏移量计算逻辑。这样一来，浏览器底层的 DOM 节点数量被严格控制在一个安全的区间内，保证了长篇量表在各类设备上的流畅滑动与填答体验，实现了框架便利性与运行性能的良好平衡。