去年团队要上线一个用户问卷需求很直接扫个码就能填、微信里直接打开支持必答、跳题、单选多选填空后台最好还能看统计。市面问卷平台大多能做到但数据在别人那边想二次定制也各种受限干脆自己做一个。这个项目就是基于UniApp开发的微信小程序问卷调查系统核心是前端跨端后端接口独立。这套实现不只跑在微信小程序同一套代码还能编译到H5和App对多端投放来说是实打实的性价比。这篇不是从零带读文档而是把一个完整问卷项目的设计思路、数据结构、关键代码和踩坑记录整理出来。适合手里有同类需求、想快速搭一套问卷前端的中级开发者也适合刚学UniApp的人看看真实项目是怎么把页面、交互、接口串起来的。问卷看起来是“几个选择题”真落地的时候题型渲染、逻辑跳题、草稿暂存、提交防抖这些细节每个都会冒出来正文里都会提到。1. 项目概述与技术选型为什么用UniApp而不是微信原生开发1.1 问卷调查系统到底要做哪些事先把这个系统的边界讲清楚。问卷调查系统的核心闭环是创建问卷、发布问卷、用户填写、提交数据、后台统计。前端小程序主要负责“用户填写”这一环再带上问卷列表、填写页、提交成功页三个核心页面管理端的创建和统计可以单独走后台或Web管理台小程序里不需要全部承担。从业务角色拆分三类人用这个系统创建者配置题目和规则填写者扫码进入并作答管理员查看回收数据和导出CSV。前端小程序面向的是填写者也顺带承担一部分“问卷浏览入口”的功能比如查看当前开放中的问卷、往期问卷的填答记录。题目类型是设计的重点。基础题型必须覆盖单选、多选、填空、评分。跳题逻辑是问卷调查区别于普通表单的加分项比如“你是否有小孩”选择“否”则跳过后面三道育儿类题目。必填校验是所有表单类应用的地基没做必填的问卷回收数据往往缺斤少两。草稿暂存则是微信场景下的刚需用户填一半退出聊天窗口几小时后回来发现草稿还在体验完全不一样。1.2 技术选型背后的取舍逻辑做这个项目之前我把三条技术路线都过了一遍。纯微信原生小程序官方支持最好生命周期、组件、调试都很顺。代价是只能跑微信团队如果后续需要支付宝小程序、抖音小程序、H5版本代码得重写一套。对于问卷这种“表单逻辑一大堆”的项目重写成本不低。纯H5倒是跨端放浏览器里跑没问题但集成到微信里就用不顺手。获取微信用户信息、分享给好友、扫码打开这些能力H5要走JSSDK体验、转发链路都比小程序弱一截。尤其是用户从聊天里点卡片进入H5中间时常有加载等待感。UniApp走的是Vue语法一套代码编译到多端。实际开发中核心页面写一套条件编译处理平台差异省下的工作量非常可观。问卷场景本身是表单密集型应用题目动态渲染、答案实时收集、跳题条件计算这些恰好是Vue响应式数据的强项。在UniApp里data驱动视图更新是直觉操作比小程序原生setData到处调用要自然得多。后端接口独立设计不绑定前端框架。我当时用的是Java后端提供RESTful API小程序端全部走uni.request封装两边通过JSON交换数据。这个架构后续把小程序换成别的端或者新增一个管理后台后端完全不用动。2. 数据结构与接口设计先把底座打好2.1 问卷、题目、答案三张核心表问卷系统的数据结构不复杂核心就三块问卷、题目、答案。问卷表承载基本信息标题、说明文案、状态草稿、发布中、已结束、发布时间、截止时间。状态字段很重要前端列表页靠它决定显示“可填写”还是“已结束”不要让用户点进去才发现填不了。题目表是问卷的骨架字段包括所属问卷ID、题目顺序、题型、题干、选项列表、是否必填、跳题规则。这里需要注意我把选项直接以JSON数组形式存在题目里而不是单独建一张选项表。对于一个问卷几十道题的规模这种方案简单直观前后端联调时省掉一层拼接查询性能也没有压力。如果未来做复杂的题库管理、题干顺序随机、选项乱序再拆单独选项表也不迟。答案表则是提交记录。每次提交生成一条主记录带一个提交时间明细数据以JSON格式存下用户每道题的答案。这样做统计的时候可以按题目ID聚合某个选项被选了多少次。下表是三个核心数据结构的精简对照直接按这个结构去建后端模型或数据库表都没问题。数据结构关键字段说明surveyid、title、desc、status、deadline问卷主体status 控制前端展示questionid、survey_id、type、title、options、required、jump_ruleoptions 存 JSON 数组jump_rule 存跳题配置answerid、survey_id、submit_time、contentcontent 存 JSON映射 question_id 到答案值跳题的实现我建议把规则揉进选项里。一个选项除了id和文案还可以带一个jumpTo字段表示选中该项后跳到第几题。这样前端拿到题目列表时无需再单独请求跳题配置直接解析选项数据即可。2.2 接口约定与请求层封装接口设计遵循简单明确的风格。小程序端主要用三个问卷列表接口、问卷详情接口、提交答案接口再加一个可选的“提交记录查询”用于回填草稿。统一返回结构是后端接口设计里最容易被忽略但收益最大的点。我的后端所有接口返回固定结构code为0表示成功非0是业务错误码message是错误提示data承载真实数据。前端request层集中判断code避免每个业务页面重复写错误处理。小程序端把uni.request封装一层request函数统一处理BASE_URL、请求头、超时、错误弹窗。下面是一个实际使用中的封装// utils/request.js const BASE_URL https://api.your-domain.com export function request({ url, method GET, data {} }) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL url, method, data, header: { Content-Type: application/json }, timeout: 10000, success: (res) { const body res.data || {} if (res.statusCode 200 res.statusCode 300 body.code 0) { resolve(body.data) } else { uni.showToast({ title: body.message || 请求失败, icon: none }) reject(body) } }, fail: (err) { uni.showToast({ title: 网络异常请稍后再试, icon: none }) reject(err) } }) }) }开发阶段调试时微信开发者工具有一个专属小坑本地请求http接口默认被拦截需要在“详情-本地设置”中勾选“不校验合法域名”。上线前务必把后端换成https域名然后在微信公众平台配置request合法域名否则线上版本接口全会挂。3. 前端核心模块的实现与踩坑3.1 问卷列表页加载、分页与状态展示列表页是用户进入小程序后的第一落点。页面上展示所有可见问卷卡片形式呈现标题、说明、截止时间之外一定要有一个状态标签。状态标签直接影响点击率用户看到“进行中”会更有意愿点进去“已结束”的卡片基本不用点。数据加载用上拉刷新加触底分页的组合。uni-app提供了onPullDownRefresh和onReachBottom两个页面生命周期监听后分别调加载函数即可。注意一点在自定义导航栏或者特定布局下onReachBottom触底的距离需要适配页面滚动高度不够时就无限触发可以通过在页面配置中设置onReachBottomDistance调整。分页逻辑用页号加每页条数的方式核心代码参考这一段const page ref(1) const pageSize 10 const hasMore ref(true) const list ref([]) async function loadList(reset false) { if (reset) { page.value 1 hasMore.value true list.value [] } if (!hasMore.value) return const data await request({ url: /api/surveys, data: { page: page.value, pageSize } }) list.value list.value.concat(data.list || []) hasMore.value list.value.length data.total page.value 1 } onPullDownRefresh(async () { await loadList(true) uni.stopPullDownRefresh() }) onReachBottom(() { loadList() })列表页一个容易被忽略的细节是缓存策略。用户可能多次进入小程序问卷列表却没有经常变化。我用uni.setStorageSync把问卷列表缓存十分钟下次进来先读缓存同时后台静默请求最新数据。这样既保证首屏秒开又不会让用户老看到过期数据。3.2 动态渲染一套模板适配多种题型问卷填写页是整个项目的核心页面。难度不在于某个题型有多复杂而在于要让一套模板动态处理多种题型。题目数据结构里type字段就是渲染分流的开关单选、多选、填空、评分各自对应一套UI和交互逻辑。一开始我直接用微信小程序的radio-group和checkbox-group做单选、多选原型跑得很快。但一进真机调试问题就冒出来了原生radio和checkbox的样式非常难定制圆点大小、选中颜色、整体布局想调成符合产品设计的风格要写一堆样式覆盖还会受到组件内部结构限制。实际项目里我换成用view自己模拟单选和复选控件。选中状态通过class属性控制数据绑定上完全不受原生组件的限制UI想做成什么样子都可以。下面给出核心模板片段view v-ifq.type radio classoption-list view v-foropt in q.options :keyopt.id classoption-item :class{ active: answers[q.id] opt.id } clickhandleRadioChange(q.id, opt.id) view classradio-circle view v-ifanswers[q.id] opt.id classradio-dot/view /view text{{ opt.text }}/text /view /view view v-else-ifq.type checkbox classoption-list view v-foropt in q.options :keyopt.id classoption-item :class{ active: (answers[q.id] || []).includes(opt.id) } clickhandleCheckboxChange(q.id, opt.id) view classcheckbox-box view v-if(answers[q.id] || []).includes(opt.id) classcheck-mark/view /view text{{ opt.text }}/text /view /view对应的事件处理函数里面单选直接赋值一个选项ID多选维护一个数组function handleRadioChange(questionId, optionId) { answers.value[questionId] optionId } function handleCheckboxChange(questionId, optionId) { const current answers.value[questionId] || [] const index current.indexOf(optionId) if (index -1) { current.splice(index, 1) } else { current.push(optionId) } answers.value[questionId] [...current] }评分题我用的是slider组件或者5个星星点击。项目里用的是5星评分点击第几颗星就赋几分交互直观用户理解成本低。需要注意控制分数范围别在边界条件下出现6分这种脏数据。填空题的坑在textarea组件上。微信小程序里的textarea属于原生组件层级天然比普通view要高在页面滚动或弹层出现时容易盖在其他元素上。我的处理方式是不让textarea跟其他组件重叠避开复杂定位场景如果需要弹窗内嵌输入框就得考虑用cover-view或者换自定义弹层方案。3.3 逻辑跳转与必填校验的实现思路问卷系统的进阶能力就是跳题。实现思路采用的是配置驱动每个选项带有jumpTo字段表示选择该项后要显示的第几道题。存储上不额外建表前端通过遍历题目列表计算当前对用户要展示哪些题。计算可见题目的核心逻辑如下function computeVisibleQuestions(questions, answers) { return questions.filter(q { // 题目被某个前置跳转隐藏则不可见 for (const prev of questions) { if (prev.jumpRule prev.jumpRule.questionId q.id) { const answer answers[prev.jumpRule.questionId] if (prev.jumpRule.optionId ! answer) { return false } } } return true }) }每次用户答案变化后重新跑一遍这个函数得到一个可见题目数组页面循环渲染这个数组。被跳过的题目自动消失在页面里同时把对应的答案清掉避免后端收到“未看到题目却填了答案”这些脏数据。必填校验放在提交按钮的点击事件里。校验逻辑要覆盖所有题型的取值方式单选是数字ID多选是数组填空是字符串评分也是数字。不能只用if判断空值需要分类型判断。下面是整理过的校验函数function validate(visibleQuestions, answers) { for (const q of visibleQuestions) { if (!q.required) continue const val answers[q.id] if (q.type text typeof val string) { if (!val.trim()) return { ok: false, msg: q.title } } else if (Array.isArray(val)) { if (val.length 0) return { ok: false, msg: q.title } } else if (val undefined || val null || val ) { return { ok: false, msg: q.title } } } return { ok: true } }校验不通过时除了弹toast提示最好再滚动定位到第一道未填写的题目。uni-app里可以通过uni.pageScrollTo配合节点信息查询实现体验比单纯弹提示好很多。我是在项目后期补的这个功能用户反馈明显改善。提交的时候我做了一个状态锁处理用户连点提交按钮的情况。state里的isSubmitting在提交中置为true提交按钮显示loading请求结束后再复位。这个坑当时是真实遇到的连点两下提交会生成两条几乎一样的记录后端对账时头大。const isSubmitting ref(false) async function handleSubmit() { if (isSubmitting.value) return const check validate(visibleQuestions.value, answers.value) if (!check.ok) { uni.showToast({ title: 请完成必答题 check.msg, icon: none }) return } isSubmitting.value true try { await request({ url: /api/surveys/ surveyId /submit, method: POST, data: { content: JSON.stringify(answers.value) } }) uni.redirectTo({ url: /pages/result/success }) } finally { isSubmitting.value false } }草稿暂存方面我在onHide和onUnload生命周期里把当前答案写入本地缓存键名是surveyIdonHide(() { uni.setStorageSync(survey_draft_${surveyId}, answers.value) })用户再次进入问卷页时读取缓存回填提交成功或放弃填写后清除该缓存。这个功能投入产出比极高尤其对于问卷这种单向操作中断后再进来能续填流失率会低不少。4. 常见问题速查与调试实录4.1 真机与模拟器的表现差异做小程序开发模拟器里一切正常、一上真机就出问题这种事我遇到太多回了。问卷页面最常见的几类差异模拟器上textarea输入时键盘弹出后页面布局正常真机上键盘会顶起整个页面部分机型的toolbar区域甚至会被遮挡。处理方法是给页面加adjust-position适配或者用uni.pageScrollTo在聚焦时滚动到输入框可见位置。原生组件层级问题在真机上更严重。文本域盖在弹窗上层、地图或视频组件覆盖普通view这些在模拟器里基本复现不出来。我做问卷页时评分说明文字用了固定定位的底部气泡真机上一测textarea直接戳穿了气泡。后面统一用自定义弹层组件替代原生控件才彻底解决。页面上拉加载的行为在模拟器和真机也有细微差异。模拟器窗口高度和真机屏幕比例不一致onReachBottom触发时机可能提前或延后。调试时要分别在iPhone和安卓上确认加载到底的体验别只在开发者工具里看完就算。4.2 性能、分包与缓存策略问卷规模大起来性能问题就藏不住了。一场大型调研可能有几十道题每道题几个选项如果一次性把完整题目列表setData到页面上小程序的渲染性能会明显下降。我的处理策略分两层。第一层是接口层面详情接口把questions和options完整返回这是必须的因为跳题计算需要全量数据。第二层是渲染层面visibleQuestions计算过后只返回当前可见题目的数组模板只渲染这个数组题目多的时候用户视角永远是精简的页面不会被一堆隐藏节点拖累渲染。小程序主包大小是有限制的图片、字体这些资源能走CDN就不要本地打包。问卷配图、富文本说明这类内容上传后存入对象存储小程序端通过url访问主包体积可以降下来。本地缓存上草稿是必须频繁读写的我把草稿和问卷列表分开存储避免相互影响。草稿容量没必要限制用户填写的内容一般不会很大。需要留意的是题目版本更新后旧草稿里可能存了已经不存在的题目ID提交前做一次过滤丢弃无效题目答案。4.3 提交失败与重复提交处理调查问卷这种场景提交失败的影响比一般表单更严重。用户花了几分钟填完结果点击提交时网络抖动一下答案全没了换成谁都会骂人。我做了三重保障。第一重是提交状态锁防止连点重复提交。第二重是提交失败时数据不丢后端返回非200状态或网络异常就把答案继续保存在草稿缓存里并提示用户“提交失败请检查网络后重试”。第三重是给提交接口加了一个本地生成的requestId作为幂等标识后端根据这个标识去重。即使前端状态锁失效导致同一请求发了两次后端也只会落一次数据。实际运营中问卷在截止时间附近访问量会突然上涨。后端我做了一个简单的限流策略同一问卷下同一openid每分钟最多提交两条。前端不需要感知这些但接口返回限流错误码时页面要给出友好提示不能直接白屏。结尾一点个人体会做这个项目最大的收获不是代码本身而是理解了表单类应用的核心其实在数据流。把题目数据结构、答案对象结构、接口返回结构提前定义清楚页面UI只是数据的映射而已后面加新题型、加跳题规则都是配置层面的小改动。UniApp在跨端场景确实省了不少事但框架不是万能的真机调试、原生组件层级、包体积这些老问题一个都跑不掉。如果你正准备做类似的项目我建议先把题目数据结构设计得可扩展一点再动手写页面顺序反了会返工得很痛苦。最后再分享一个小技巧问卷发布后一定要自己填一遍用真机、走完整流程你会发现很多设计时根本想不到的体验问题。