企业官网建设流程全解析

1. 项目概述：一个看似简单但坑不少的功能模块

做小程序开发这几年，我接触最多的需求除了登录注册、列表展示之外，就是“图片上传”和“意见反馈”这两个功能。很多人觉得这俩模块简单，不就一个选择图片、一个提交表单嘛，但实际上真正落地的时候，里面的细节多到能让你怀疑人生。尤其是当这两个功能组合在一起——用户要提交意见反馈，同时附带截图或者照片作为佐证——整个流程的体验和稳定性就成了一个需要仔细打磨的事情。

这个项目标题“微信小程序：图片上传--意见反馈”，本质上是一个典型的用户反馈闭环场景。用户在使用小程序时遇到问题，需要提交文字描述，同时希望上传相关截图让开发方能更快定位问题。这个场景几乎适配所有类型的小程序：电商类、工具类、内容类、企业服务类，但凡有用户运营的地方都用得上。

从技术栈来说，微信小程序提供了wx.chooseMedia（旧版是wx.chooseImage）来选图，wx.uploadFile来做文件上传，配合后端接口或者微信云开发能力，就能实现完整的图片上传链路。而意见反馈本身则涉及表单校验、内容提交、状态反馈、历史记录等几个环节。两者结合起来，核心要解决的不只是“能用”，还有“好用”“稳定”“不丢数据”这些实际问题。

先说清楚这个项目适合谁参考。如果你是要做小程序的新手开发者，这篇内容能帮你避开我踩过的那些坑。如果你是老手，可能里面有些排查思路和细节处理方式也能给你一些启发。我尽量把思路拆开讲，从设计到实现，从踩坑到优化，一条线走下来，争取让看完的人能直接照着写出一版可用性很高的反馈功能。

2. 整体设计与方案选型：先想清楚再动手

2.1 业务流程梳理

在动手写代码之前，先把业务流程在脑子里过一遍。一个标准的意见反馈加图片上传流程大概是这样的：

用户从“我的”页面或者“设置”页面进入意见反馈页 → 页面加载时先读取历史反馈记录（如果有这个需求的话） → 用户在文本框输入反馈内容 → 用户选择图片（可多选、可预览、可删除） → 点击提交 → 前端做内容校验和图片合法性校验 → 图片先上传到服务器/云存储，得到URL → 将反馈内容和图片URL一起提交给后端 → 提交成功后给出反馈成功的提示 → 用户可查看历史反馈和处理状态。

这个流程看起来顺畅，但在实际设计的时候有几个决策点需要提前定下来，否则后面会返工。

第一个决策点是图片到底什么时候传。有的开发者图省事，把图片和反馈内容一起通过一个接口提交，让后端去处理图片流。这种做法在小图片、低频次场景下勉强可行，但一旦图片数量多或者体积大，接口响应时间会非常感人，而且容易超时失败。所以我建议的通用方案是：先传图片，拿到URL列表，再提交表单数据。这样表单接口轻量、稳定，图片上传状态也能做细粒度的进度反馈。

第二个决策点是选图的实现方式。微信小程序里选图有旧版wx.chooseImage和新版wx.chooseMedia。如果你是2023年以后才开始做开发，直接无脑用wx.chooseMedia，因为旧接口已经进入了停止更新的状态，虽然还能用，但迟早要迁移。wx.chooseMedia支持从相册选图也支持直接调起相机，能配置最大选择数量，能指定媒体类型（图片或视频），能力上完全覆盖wx.chooseImage。

第三个决策点是用传统服务器还是微信云开发。如果你所在的项目组已经有完整的后端服务，那用wx.uploadFile对接自己的接口即可。如果没有后端资源，或者想快速上线验证需求，微信云开发的wx.cloud.uploadFile是效率很高的选择，直接把图片传到你自己的云存储空间，不需要自己搭建文件服务。后文我会把两条路都讲清楚，你可以根据自己的情况选。

2.2 为什么建议“图片先传、反馈后发”

这是我做这个功能时的一个核心决策，也是我认为最值得展开讲的点。

把图片上传和反馈内容提交解耦，主要基于三个考虑。第一，用户体验层面的考虑。如果用户选了三张图，每张图2MB，总共6MB，在上传带宽有限的环境下可能要等好几秒。如果这时候把反馈内容和图片一起提交，用户会一直卡在“提交中”的loading状态，不知道进展如何，体验很差。而拆分之后，我们可以先在图片选择区域显示每张图的上传进度，让用户明确知道“图正在传”，传完了再提交文字内容，整个过程更透明。

第二，稳定性层面的考虑。小程序里的wx.uploadFile虽然底层也是HTTP请求，但在弱网环境下失败率并不低。如果表单和图片一起提交，一旦图片流传输中断，不仅图片没传上去，用户辛苦打的几百字反馈内容可能也得跟着重来。分开之后，表单提交失败只是重发一次文字请求，图片已经传上去了，不用重新传。

第三，后端开发层面的考虑。绝大多数后端框架处理JSON表单数据都很成熟，但处理multipart文件流的时候操作会更繁琐，尤其涉及到多文件上传时，服务器侧的临时文件管理和大小限制配置都更麻烦。图片先传到存储服务，后端拿到的只是一串URL字符串数组，处理起来简洁得多。

当然了，这个方案也有需要注意的地方：图片传上去了但用户最终没提交反馈，会产生一些“孤儿图片”占用存储空间。这个问题可以通过定期清理或回调通知删除来解决，在我看来，这点成本换来前端体验的稳定性，是完全值得的。

2.3 前端展示与交互设计要点

意见反馈页面的UI虽然不复杂，但几个交互细节直接决定用户愿不愿意把反馈写完整。

图片选择区域建议用网格布局，一般是3列或4列。每个格子显示缩略图，右上角给一个删除按钮，用户点删除可以移除已选图片。当选择的图片数量还没到上限时，最后一个格子显示“+”按钮，点击唤起选择器。这个交互模式已经是行业标配了，用户学习成本最低。

文本框需要做字数限制，一般反馈内容限制200到500字比较合理。为什么不建议太长？一方面用户打太多字本身就不现实，另一方面后端存太长文本意义也不大，真正的有效信息往往集中在前面几句话。我建议限制在200字，同时在输入框右下角实时显示“当前字数/最大字数”，字数到顶时阻止继续输入并给出轻提示。这个细节看起来小，但对用户体验的感知非常直接。

提交按钮的交互也值得说。用户在点击提交之后，按钮一定要进入loading状态并禁用，防止重复点击导致同一份反馈被提交两次。这个老生常谈的问题，在实际项目里出现的频率比你想的高得多。

这里我画一条前端逻辑流：进入页面 → 拉取历史反馈（若需要） → 用户输入 → 用户选图 → 本地校验（数量、大小、类型） → 逐张上传图片得到URL → 组装表单数据 → 提交反馈接口 → 成功跳转/清空页面 → 失败保留已传数据并提示重试。

3. 核心细节解析与实操要点

3.1 图片选择的参数配置细节

图片选择接口的参数配置，直接决定后面一系列逻辑的复杂度。我用wx.chooseMedia举例，把关键参数挨个说清楚。

wx.chooseMedia({ count: 9, // 最多可选9张，根据需求定 mediaType: ['image'], // 只允许选图片，不允许选视频 sourceType: ['album', 'camera'], // 相册和相机都可以，也可以指定只从相册选 sizeType: ['original', 'compressed'], // 原图和压缩图都允许 camera: 'back', success: (res) => { // res.tempFiles 是一个数组，每一项有 tempFilePath、size 等字段 const files = res.tempFiles.map(item => item.tempFilePath); // 这里把 files 加到你的待上传列表里，同时检查总数是否超限 }, fail: (err) => { console.error('选择图片失败', err); // 用户取消选择时也会走fail，需要区分错误类型，避免误提示 } });

count参数最大是9还是多少？微信官方文档里写的是“最多可选的个数，默认是9”。也就是说，一次最多9张，如果你希望超过9张，那就得引导用户分批选择，或者重新评估需求——一个反馈附带超过9张图，其实已经不太合理了。再说了，本地图片选择虽然能选9张，但wx.uploadFile是逐张上传的，9张图的上传时间和后端存储压力都不能小看。

还有一个细节是图片大小判断。选完图之后，tempFiles数组里的每一项都有size字段，单位是字节。我建议在本地就对单张图片大小做限制，比如超过10MB就不允许上传。为什么要限制？因为微信小程序的上传在部分安卓机型上对大文件的处理并不稳定，而且大图上传消耗的流量和时间会让用户直接放弃反馈。虽然真实场景里反馈截图通常不会超过5MB，但加一道防线总没错。

图片选择完成后，页面上的临时预览怎么处理？我建议直接用tempFilePath做本地预览，不需要额外转成base64或者复制文件。只有在上传成功之后，才把临时路径替换成服务器返回的URL。这样做的原因是tempFilePath在本次小程序运行期间是有效的，够用来做缩略图和预览，没必要多此一举去wx.getFileSystemManager().saveFile做持久化——既增加代码复杂度，又可能踩到存储空间限制的坑。

3.2 上传时机的选择与实现

前面提到图片先传，那具体什么时候触发上传？两个方案：一是所有图片选完之后统一上传，二是每选一张立刻上传。我建议用方案一，也就是用户把所有要传的图选好、删好，最终确认了再一起传。

为什么？因为用户选图的过程是一个反复调整的过程，可能先选了3张，又删掉1张，然后又加2张。如果每选一张就立刻上传，删掉的那张已经在服务器上了，还得额外调删除接口去清理，既浪费请求又增加了出错的概率。统一在提交时上传，图片列表是最终状态，传上去的都是确认要用的，逻辑上最干净。

具体到代码实现，我在提交时遍历图片列表，逐张调用上传函数。这里有几个要点需要特别注意。

第一，上传成功之后要保存返回的fileID或者URL，并且把本地临时路径和服务器URL做一个映射，便于后续表单提交时使用。第二，一定要处理“上传过程中用户退出页面”的情况。如果用户上传到一半切走了，前端必须有abort机制或者通过onUnload清理上传任务，否则后台会一直跑着上传，浪费流量且产生无效图片。第三，多张图片上传建议串行而不是并行。很多人喜欢用Promise.all一把梭并行上传所有图片，看起来更快，但实际在弱网环境下，并行上传多个大文件很容易触发微信的并发限制或者导致部分文件失败难排查。串行上传配合进度提示，整体体验反而更可控。

来看一个串行上传的实现思路：

async function uploadImages(filePaths) { const uploadedUrls = []; for (let i = 0; i < filePaths.length; i++) { try { const url = await uploadOneImage(filePaths[i]); uploadedUrls.push(url); // 更新进度：已上传 i+1 / total } catch (err) { // 单张失败，记录失败原因，中断后续上传或跳过 throw err; } } return uploadedUrls; }

这里没有用递归而是用了async/await的for循环，代码可读性好，也容易在中间插入进度回调。实际项目里我还会给每张图加上状态标记（等待中/上传中/成功/失败），失败的那张允许用户点击重试，不用整批重新传。这个细节对用户体验的提升很直接。

3.3 云开发与传统服务器的双轨方案

图片上传的目标地址，取决于你的后端架构。我分别说下两条路怎么走。

如果用的是微信云开发，那上传就简单很多。初始化云环境之后，直接调wx.cloud.uploadFile：

wx.cloud.init({ env: 'your-env-id' }); async function uploadOneImage(filePath) { const cloudPath = `feedback/${Date.now()}-${Math.random().toString(36).slice(-6)}.jpg`; const res = await wx.cloud.uploadFile({ cloudPath, filePath, }); return res.fileID; // 这就是云存储中的文件ID，可以直接传给后端 }

cloudPath的命名规则建议带上业务前缀和日期，方便后续排查问题。这里有个小坑：wx.cloud.uploadFile默认上传的是原文件，不会自动压缩。如果你不想传原图，得在上传之前自己用wx.compressImage压缩一遍再传。

如果用的是传统服务器，那就得用wx.uploadFile。这个接口大家应该不陌生，但有几个参数容易搞错。name是后端接收文件的字段名，必须和后端接口约定一致。formData里可以带一些鉴权信息，比如token等。上传之前要拿到服务器地址，注意必须是HTTPS且在小程序后台配置了合法域名，否则真机上一调就报错。

function uploadOneImage(filePath) { return new Promise((resolve, reject) => { wx.uploadFile({ url: 'https://your-server.com/api/upload', filePath: filePath, name: 'file', formData: { token: getToken() }, success: (res) => { // res.statusCode 必须判断是否为2xx if (res.statusCode >= 200 && res.statusCode < 300) { const data = JSON.parse(res.data); resolve(data.url); } else { reject(new Error('上传失败')); } }, fail: (err) => reject(err), }); }); }

一个容易踩的坑是res.data的类型。在wx.uploadFile的success回调中，res.data是字符串，不是对象。你必须要先JSON.parse才能取到里面的字段。很多新手在这里直接res.data.url拿不到值，查半天才发现是类型问题。

3.4 意见反馈表单的校验与提交细节

反馈文字内容的校验，比图片校验要微妙一些。一方面要防止用户提交空内容，另一方面也要防止后端被塞入无意义的噪声数据。我的做法是前端做三层校验：第一层，内容非空，去掉首尾空格后长度必须大于0；第二层，内容长度不超过200字；第三层，图片列表和文字内容至少要有一样，也就是说如果用户没打字但传了图，也允许提交（这种场景很常见，用户可能只是传个截图不想多解释）；如果打了字没传图，同样允许提交。

前端在校验通过之后，组装提交数据：

const feedbackData = { content: content.trim(), images: uploadedImageUrls, // 数组形式，后端直接存JSON或者单独表关联 contact: contact || '', // 联系方式，可选 page: currentPage, // 当前页面路径，方便定位问题 };

这里我想特别说一下contact字段。很多意见反馈页面会加一个“联系方式”输入框，让用户留个手机号或微信号方便回访。这个功能看起来很贴心，但实际上用户留的联系方式往往没人跟进，反而让用户产生“反馈了没人理”的负面感受。如果你确定团队有客服人员会跟进反馈，可以留联系方式；如果只是把反馈内容存下来供内部查看，我不建议要联系方式，省得用户期望落空。

提交接口的返回处理也得细致。成功之后，不能无脑wx.showToast一下“提交成功”就完事。比较好的做法是：提示成功、把页面表单清空、图片列表重置，然后返回上一页或者跳转到“我的反馈”列表页。如果不想做反馈列表页，至少也要在提示里告诉用户“我们会在N个工作日内处理”，让用户知道反馈已经进入了处理流程。

提交失败的情况更要处理得仔细。失败原因可能是网络问题、后端5xx、token过期等。前端不能只弹一个“提交失败”就拉倒，要尽可能把可重试的失败和不可重试的失败区分开。比如网络错误和5xx可以直接提示“网络异常，请稍后重试”，保留用户已填内容和已传图片。如果是token过期这种鉴权失败，则引导用户重新登录再提交。

4. 实操过程与核心环节实现

4.1 页面结构与样式拆解

一个完整的意见反馈页面，我习惯把结构分成几个清晰的区块：反馈类型选择区（可选）、问题描述输入区、图片上传区、联系方式区（可选）、提交按钮区。

反馈类型选择区对于复杂产品来说很有价值。比如一个电商类小程序，用户遇到的问题可能是“订单问题”“支付问题”“商品质量问题”“其他”，让用户先选类型，后端就能自动给反馈打标签，处理效率高很多。实现上用radio-group或者标签式选择都行，看产品风格。

问题描述输入区用textarea组件，maxlength属性可以直接限制输入长度。不过要注意，textarea在部分安卓机型上会有原生组件层级问题，容易盖住其他元素。解决方法是给它设置fixed属性为false，或者用接近的样式来规避层级问题。

图片上传区用view加image组件实现网格布局。核心代码如下：

<view class="upload-grid"> <view class="upload-item" wx:for="{{imageList}}" wx:key="index"> <image src="{{item}}" mode="aspectFill" bindtap="previewImage"></image> <view class="delete-btn" catchtap="removeImage">Page({ data: { content: '', imageList: [], // 本地临时路径列表 uploadedUrls: [], // 上传成功后的URL列表 maxCount: 9, submitting: false, }, onUnload() { // 页面销毁时，如果有正在进行的上传任务，需要清理 if (this.uploadTask) { this.uploadTask.abort(); } }, chooseImage() { const remain = this.data.maxCount - this.data.imageList.length; if (remain <= 0) { wx.showToast({ title: '最多上传9张图片', icon: 'none' }); return; } wx.chooseMedia({ count: remain, mediaType: ['image'], sourceType: ['album', 'camera'], success: (res) => { const newPaths = res.tempFiles.map(item => item.tempFilePath); this.setData({ imageList: this.data.imageList.concat(newPaths), }); }, }); }, removeImage(e) { const index = e.currentTarget.dataset.index; const imageList = [...this.data.imageList]; imageList.splice(index, 1); // 同步移除对应的已上传URL，避免索引错位 const uploadedUrls = [...this.data.uploadedUrls]; uploadedUrls.splice(index, 1); this.setData({ imageList, uploadedUrls }); }, previewImage(e) { const index = e.currentTarget.dataset.index; wx.previewImage({ current: this.data.imageList[index], urls: this.data.imageList, }); }, async submitFeedback() { if (this.data.submitting) return; const content = this.data.content.trim(); if (!content && this.data.imageList.length === 0) { wx.showToast({ title: '请填写反馈内容或上传图片', icon: 'none' }); return; } this.setData({ submitting: true }); wx.showLoading({ title: '提交中...' }); try { // 第一步：上传所有图片（如果有） let uploadedUrls = this.data.uploadedUrls; if (this.data.imageList.length > 0) { uploadedUrls = await this.uploadImages(this.data.imageList); } // 第二步：提交反馈数据 await this.submitFeedbackApi(content, uploadedUrls); wx.hideLoading(); wx.showToast({ title: '提交成功', icon: 'success' }); setTimeout(() => { wx.navigateBack(); }, 1500); } catch (err) { wx.hideLoading(); console.error('提交反馈失败', err); wx.showToast({ title: '提交失败，请检查网络后重试', icon: 'none' }); this.setData({ submitting: false }); } }, async uploadImages(filePaths) { const urls = []; for (let i = 0; i < filePaths.length; i++) { wx.showLoading({ title: `上传图片 ${i + 1}/${filePaths.length}`, mask: true, }); const url = await this.uploadOneImage(filePaths[i]); urls.push(url); } return urls; }, });

这里有两点要提醒。第一，我在示例里把wx.showLoading放进了循环里，实际体验中频繁切换loading文案其实不好看，更好的做法是把进度做到图片缩略图上，但作为基础版代码，这样写够用了。第二，submitting这个标志位非常重要，防止用户在提交过程中疯狂点按钮。

4.3 后端接口接收与处理建议

反馈接口的后端实现，前端开发者往往就看个大概，但我还是想多说一句，因为前后端约定的质量直接决定功能是否稳定。

后端接收反馈数据时，建议的字段设计是：

接口要做的基本校验包括：content长度限制、images数组大小限制（最大9个）、source来源合法性等。存储层面，建议把图片URL直接存成JSON数组字段，不要去搞关联表。大部分反馈的查询场景是“查一个人的历史反馈列表”或者“查所有未处理反馈”，分开存没有意义。

4.4 历史反馈记录的实现思路

“我的反馈”列表页面，是这个功能闭环里容易忽略但用户其实很在意的一个模块。用户提交了反馈之后，通常希望知道这个反馈有没有被看到、有没有被处理。

实现上很简单：就是调用一个查询接口，返回当前用户的历史反馈列表。列表项展示反馈摘要、状态（待处理/处理中/已解决）、时间，以及图片缩略图。状态流转一般由后台客服手动更新，前端只需要正确展示。

如果不想做完整的“我的反馈”页面，至少要在提交成功后给用户一个明确的反馈编号或者“已收到，将尽快处理”的提示，让用户知道东西没有丢。我在做多个项目之后发现，很多用户对反馈功能的不满，并不是因为问题没解决，而是因为反馈之后石沉大海、毫无回音。所以哪怕只是状态字段的展示，对用户体验的提升都是巨大的。

5. 常见问题与排查技巧实录

5.1 真机预览时图片上传失败

这是反馈功能上线后最常遇到的问题。模拟器上一切正常，一上真机就报 “uploadFile:fail” 或者 “url not in domain list”。

第一个排查点是域名白名单。小程序后台的“开发管理-服务器域名”里，必须配置uploadFile合法域名。注意：wx.uploadFile的合法域名配置的是“request合法域名”还是“uploadFile合法域名”？很多新手在这里搞混。实际是：uploadFile要配在“uploadFile合法域名”里，request要配在“request合法域名”里，两者不能混用。如果你用的是云开发，则不需要配域名，因为云开发有独立的访问通道，这也是云开发的一个优势。

第二个排查点是HTTPS证书。小程序的正式环境要求所有请求必须是HTTPS，且证书链要完整。有些测试环境的证书是自签的，模拟器上可能不校验，真机上直接挂。

第三个排查点是IPv6问题。部分安卓真机在纯IPv6网络环境下，访问只有IPv4的服务器会超时。这个不常见，但如果域名没问题、证书没问题、代码也没问题，不妨查一下服务器是否支持IPv6访问。

5.2 图片选择后预览但上传数量对不上

这个问题在开发中经常出现：用户选了3张图，但最后提交时只上传了2张，或者图片顺序乱了。

原因大多是索引错乱。当你删除或者新增图片时，如果imageList和uploadedUrls两个数组没有同步维护，就会导致索引对不上。比如用户先传了第1张，然后删掉第1张，此时uploadedUrls数组没有同步splice，后面提交时拿到的URL列表就和图片对不上了。

解决方式很直接：维护一个单一数组，每一项是一个对象，包含localPath、remoteUrl、status等字段。删除和新增都基于这个数组操作，提交时遍历数组，取有remoteUrl的项。这样就不会出现两个数组同步问题。

自动检测方案也可以加：上传完成后，比对imageList.length和uploadedUrls.length，如果不一致，就提示“部分图片上传失败，请重试”。

5.3 上传大图片时内存溢出或卡顿

在小程序里选高清原图，尤其是iPhone拍的1200万像素照片，一张可能好几MB。如果用户连续选9张，加载到页面上的预览图如果直接用原图路径，内存占用会非常高，低端安卓机上甚至直接白屏。

解决方式是做两层处理。第一层是选图时用sizeType: ['compressed']，让微信在选图阶段就帮你压缩一版，虽然压缩后的图可能只有几十KB到几百KB，但对反馈场景来说足够了。第二层是预览图用mode="aspectFill"并且image组件的尺寸不要太大，同时不要给所有图片一次性渲染大图。如果真的需要原图上传（比如某些业务需要高清图片），那就不能偷懒，得用wx.compressImage先压缩到合理大小再传。

5.4 提交反馈后提示成功但数据没入库

这种问题最让人头大，前端看着完全正常，后端也返回了200，但数据库里就是找不到记录。排查思路是：

先看后端日志，确认请求是否真的到达了服务端。如果到了，确认返回的200是业务成功还是HTTP层成功。很多后端框架在没有捕获异常的情况下，HTTP状态码也可能返回200，但业务逻辑实际走到了catch分支，事务回滚了。所以前端不能只看状态码，还要在响应体里定义业务状态码，比如code: 0表示成功，code: 40001表示参数错误，前端根据业务码做判断，而不是把HTTP 200当成成功。

另一个常见原因是数据库事务提交失败或者字段长度超限。比如content字段在数据库里是varchar(500)，但前端校验只做了200字限制，理论不会超，但如果有内容里带了特殊字符导致长度计算偏差，就可能失败。排查这类问题最有效的手段就是看后端完整日志，不要猜。

5.5 弱网环境下的使用体验保障

弱网是移动端产品的常态，在小程序里尤为明显。用户可能在电梯里、地铁上提交反馈，网络状况差是常态而不是例外。

针对弱网的优化，我做了这几点：第一，把wx.uploadFile的timeout设置合理值，不要太短，30秒是常见的配置；第二，上传图片失败时不要立刻全部放弃，而是允许用户单独重试失败项，代码里表现为给每张图一个上传失败标记，点击该图时触发重传；第三，表单提交如果失败，把用户输入的内容和已上传的URL缓存到wx.setStorageSync，下次进入页面时自动恢复，避免用户打完几百字因为一次网络抖动就全部白费——这个体验真的太伤人了。

5.6 常见问题速查表

6. 写在最后的实操体会

这个项目做完之后，我最大的一个感触就是：越简单的功能越要在细节上较劲。图片上传加意见反馈，看起来是个人人都能做的模块，但真正决定它好不好用的，恰恰是那些不写在需求文档里的细节——图片上传失败要不要提示、提示了之后能不能重试、用户打了半天的字网络断了还没不还没？这些才是用户能直接感知到的东西。我在实际开发中，会先把“用户在这一步可能会遇到什么故障”列出来，再反推代码设计，这样出来的功能才不是那种“只在理想网络下能用”的演示版。

最后分享一个小技巧：如果你做的是企业内部使用的小程序，反馈功能可以再加一个“系统信息自动附带”的能力，通过wx.getSystemInfo拿设备型号、微信版本、屏幕尺寸等数据，跟随反馈内容一并提交。这样客服在处理反馈时不需要反复问“你用的什么手机”，很多问题光看设备信息就能定位个七七八八。这个功能实现成本几乎为零，但对反馈处理效率的提升是非常明显的。下次你接到这个需求的时候，不妨在方案里直接带上这个设计。