1. 项目整体设计与思路拆解真正接触过生鲜配送项目的人都知道这类App和普通电商App在体验设计上有一个本质区别用户等不起。在淘宝买件衣服晚两天到没人找你麻烦但生鲜商品关乎一日三餐用户下单时就在等米下锅。所以我接手这个“生鲜配送商城APP前端功能版块”时的核心判断是这不只是把商品列表、购物车、结算页拼在一起而是要围绕“便捷采购闭环”这条主线把用户在碎片化时间里完成一次生鲜采购的路径做到最短。1.1 核心需求解析什么是采购闭环采购闭环听起来是个产品术语落到前端操作上其实就四个动作看到菜、选好菜、下完单、知道什么时候送到。任何一环出现断裂用户就会流失。比如用户半夜想下单明早的菜结果首页半天刷不出当日菜品或者购物车加了一堆东西结算时才发现满减条件看不懂再或者支付成功了却不知道订单状态从“已支付”到“配送中”需要多久。这些问题表面上是功能缺失本质上是前端没有把用户从“想买”引导到“买完安心”的状态。我在项目启动时专门花了一周时间梳理竞品的采购链路发现做得好的生鲜App都有一个共同点每一步都在减少用户的决策成本。首页用限时达标签告诉用户现在下单几点能到详情页用加购动画强化“装进篮子”的感知结算页默认选中最优优惠方案而不是让用户自己算账。这些设计背后都是对用户心理的精准把握。1.2 技术选型思考为什么采用跨端方案生鲜配送场景有一个很现实的需求小B端商户食堂、餐厅老板和C端家庭用户都在用这套系统。如果只做App原生端意味着要维护iOS和Android两套代码如果只做H5性能和体验又跟不上。所以我们前端组最终决定采用uni-app跨端框架一套代码同时输出iOS、Android、H5和小程序四个平台。选uni-app而不是React Native或Flutter主要考虑三点第一团队现有的Vue技术栈可以直接迁移学习成本低招人也容易第二DCloud生态里有很多现成的原生插件扫码、定位、推送这些高频功能不用自己写原生代码第三后续如果要拓展微信小程序渠道从uni-app转过去是零成本的。事实证明这个决策在项目后期帮了大忙产品经理中途提出要上支付宝小程序前端组用两天时间就完成了打包适配。1.3 核心建设思路从浏览到售后的全链路整个前端版块我分成六个子模块来建设首页与商品导购、商品详情与加购决策、购物车管理与批量操作、结算支付与优惠计算、订单中心与履约追踪、售后服务与评价体系。这六个模块不是简单的页面堆叠而是严格对应采购闭环的六个阶段触达、决策、确认、支付、等待、反馈。每个模块内部我会做减法模块之间我做加法。所谓的减法就是单个页面只保留和当前用户意图强相关的信息。比如商品列表页不展示库存单位换算500g和1kg的切换放在详情页购物车页面不做营销活动推送促销信息集中在结算页让用户感知。“模块间做加法”指的是数据流要打通用户在首页收藏的商品在购物车要有角标提醒用户申请退款后订单详情页的状态文案要实时更新。这种细节上的连贯性才是“闭环”二字的真正含义。2. 环境准备与项目初始化这部分我默认读者有前端基础但考虑到生鲜项目有一些特殊的环境要求还是把完整流程走一遍。项目开发环境基于Vue 3 Vite uni-app CLI搭建Node版本要求14.18以上建议直接上16或18的LTS版本避免后续装依赖报错。2.1 开发环境搭建与依赖安装我用的是HBuilderX 3.8作为主要开发工具但真正规范的项目建议用CLI方式创建方便团队协作和CI/CD集成。创建命令是npx degit dcloudio/uni-preset-vue#vite my-fresh-app cd my-fresh-app npm install npm run dev:mp-weixin # 小程序端调试 npm run dev:h5 # H5端调试依赖方面除了uni-app自带的运行时我额外引入了这几个关键库vuex状态管理比Pinia更成熟生态里生鲜电商模板多踩坑容易找到答案uni-simple-routeruni-app官方路由方案支持路由守卫权限控制必需uview-plusUI组件库它的商品卡片、数量步进器、支付键盘样式很贴合电商场景dayjs体积小用来处理配送时间段的格式化注意安装uview-plus时一定要用npm install uview-plus不要用uview后者是老版本对Vue3支持有问题。我团队里一个同事在这上面卡了一下午页面白屏查了半天才发现是组件库版本不兼容。2.2 目录结构与模块划分项目目录我按“功能模块 页面类型”双维度组织方便多人并行开发时不冲突src/ ├── api/ # 接口请求统一封装 │ ├── goods.js │ ├── cart.js │ ├── order.js │ └── user.js ├── components/ # 公共组件 │ ├── GoodsCard/ │ ├── Stepper/ │ ├── AddressPicker/ │ └── EmptyState/ ├── pages/ │ ├── index/ # 首页 │ ├── category/ # 分类页 │ ├── goods/ # 商品详情 │ ├── cart/ # 购物车 │ ├── checkout/ # 结算页 │ ├── order/ # 订单列表与详情 │ └── user/ # 个人中心 ├── store/ # vuex模块 ├── utils/ # 工具函数 └── static/ # 静态资源之所以用这种结构是因为我发现很多团队习惯用“pages目录按页面堆”结果pageA和pageB共用的一个商品卡片组件散落在各自目录里改一处漏一处。前端开发最怕的就是“同一个逻辑多处维护”特别是生鲜项目里商品价格、库存状态、促销标签这种高频变化的数据组件复用度直接决定了迭代效率。2.3 基础请求封装与拦截器设计生鲜App的前端请求有一个特点高并发、高频、对实时性要求高。用户从进入首页到完成结算大概会触发20-30个接口请求如果每个接口都裸写一遍uni.request后续维护简直是噩梦。我在utils/request.js里统一封装了请求拦截器// request.js export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { token: uni.getStorageSync(token), content-type: application/json, platform: app }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { // token过期处理跳转登录页 uni.navigateTo({ url: /pages/login/login }); reject(res.data.message); } else { uni.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }); reject(err); } }); }); }这里有两个容易被忽视的细节。第一是401的统一处理生鲜App的用户经常是隔几天才打开一次token大概率过期了前端不能在每个请求里都写一遍跳转逻辑第二是loading状态的全局管理生鲜首页的接口请求很密集如果每个模块弹一个loading体验会非常糟糕。我的做法是用一个计数器来控制全局loading的显隐所有并发请求中只要还有一个未返回loading就不消失。3. 核心功能模块设计与实现3.1 首页与商品导购如何让用户快速找到想要的菜生鲜商城的首页和3C数码、服饰电商的首页有明显差异。数码用户逛商城是一种“浏览型消费”漫无目的地刷配置、看评测而生鲜用户是“目标型消费”打开App那一刻基本就想好了今晚要做什么菜、买什么食材。基于这个洞察我把首页的信息架构设计为顶部搜索 左侧分类竖导航 右侧商品流。左侧分类竖导航是生鲜App的标配但菜品的分类逻辑有讲究。我没用传统的“蔬菜/水果/肉禽蛋”这种大分类而是拆成“时令蔬菜、叶菜类、根茎类、菌菇类、猪肉、牛肉、禽类、水产、豆制品”等细分品类。这样做的原因是用户搜索“菠菜”时要么通过搜索框直达要么在分类里快速定位到“叶菜类”减少滑动查找的时间。首页的核心技术难点是“高并发下的首屏秒开”。生鲜用户有个习惯早上7点到9点下单高峰期正好是上班前的时间窗口这批人没耐心等页面加载。我做了三项优化第一采用“首屏直出 页面骨架”策略。页面框架头部搜索框、分类导航栏、轮播图区域用静态骨架先行渲染数据从本地缓存或服务端下发后逐块填充让用户感觉秒开。第二接口请求并发控制。首页涉及5类接口banner、分类列表、推荐商品、限时抢购、配送公告。如果串行请求总耗时是5个接口的和用Promise.all并发请求总耗时只取决于最慢的那个接口。实测优化后首页首屏数据加载时间从1.8秒降到了0.9秒左右。// home.vue 首屏并发请求 async loadHomeData() { const [bannerRes, categoryRes, recommendRes, flashSaleRes, noticeRes] await Promise.all([ getBannerList(), getCategoryTree(), getRecommendGoods(), getFlashSaleList(), getDeliveryNotice() ]); // 依次赋值渲染 }第三首页必须做“区域性内容”适配。生鲜配送有很强的地域属性北京和上海用户在首页看到的推荐菜品应该完全不同。我们把位置信息作为所有首页接口的公共参数前端通过uni.getLocation获取经纬度后端根据LBS动态计算配送范围、推荐附近的生鲜仓库有货的商品。前端要在进入首页时静默请求定位权限并在用户拒绝授权时回退到默认城市。3.2 商品详情与加购决策用细节打消购买顾虑商品详情页是整个闭环里直接决定用户“加不加购”的页面。生鲜商品的详情页和其他品类有很大不同用户最关心的不是“参数配置”而是“新不新鲜、什么时候到、到手什么样”。所以我特意设计了三个核心模块商品实拍视频、限时达标签、售后保障说明。商品实拍视频是我坚持要加的功能虽然开发成本不小但效果立竿见影。生鲜商品是典型的“非标品”一斤西红柿用什么滤镜都拍不出真实形态用户看图下单的信任感有限。实拍视频展示的是商品在仓库打包台上的真实状态从不同角度拍外观看新鲜度。前端用video组件实现同时做了“只在WiFi环境自动播放移动网络下展示封面图”的优化避免浪费用户流量。限时达标签放在价格下方用醒目的颜色展示“最快30分钟达”或“明日达”。这个标签不是简单的一句话文案它的背后是一套配送时间计算逻辑。前端根据后端接口返回的送达时间字段动态计算“还剩X小时Y分钟可下单”并用倒计时组件实时刷新。当超过当日最晚下单时间时自动切换为明天的送达时段给用户明确的预期管理。关于加购决策我分享一个数据我们的商品详情页有一个“大家都在买”的推荐位放在详情和评价之间。实测有17%的用户在浏览推荐位后会追加加购。这个功能的技术实现很简单就是调一个关联商品接口但产品设计上要克制——只推荐同一菜品类的商品比如用户在看牛肉推荐的是土豆、洋葱、生姜这类炖牛肉搭档而不是推荐海鲜或者零食。3.3 购物车管理与批量操作购物车在生鲜App里有一个独特场景用户加购了10样菜最后结算前可能要做加减调整。这个操作的流畅度直接决定了用户体验。我在购物车页面重点做两件事批量操作和价格实时联动。批量管理包括批量选择、批量删除、批量移入收藏。用户在全选模式下可以对所有加购商品一键结算也可以用左下角的“清空失效商品”按钮处理已经下架或缺货的商品避免用户逐个删除。价格实时联动包含商品小计、选中商品总价、满减优惠进度、配送费预估。其中最核心的是“满减凑单提示”。比如我提供了“满59减10”的优惠用户购物车总额48元时页面顶部会显示一条提示“再买11元可减10元”点击提示按钮会跳转到“凑单推荐”页推荐当前购物车里相同分类下的低价商品。这个设计在生鲜场景下尤其有效因为用户买菜的客单价本身就比较低凑单动力很足。购物车还有一个前端开发容易忽略的点购物车列表的渲染性能。用户加购30件商品是常有的事如果每件商品都渲染完整的图片、标题、价格、步进器、勾选状态页面会明显卡顿。我用了几项优化手段图片使用懒加载只在进入可视区域时加载商品勾选状态用vuex管理而非组件内state避免单个勾选操作触发全列表重渲染步进器加减操作做了防抖处理连续点击时不会频繁调接口。3.4 结算支付与优惠计算结算页是整个闭环里前端逻辑最复杂的页面没有之一。一个标准生鲜结算页要处理的数据包括收货地址、送达时间、商品清单、优惠券、满减活动、会员折扣、配送费、包装费、积分抵扣最终算出一个实付金额。任何一项前端算错了轻则用户投诉重则资损事故。我先说前端优惠计算的原则前端展示后端兜底。前端可以把各种优惠组合都算给用户看给用户一个预期但最终生成订单时的实付金额以后端返回为准。这样即使前端算错也不会造成真实资金损失。我们在order接口里设计了一个amountVerify字段后端会返回标准金额前端拿到后与本地计算结果比对不一致时直接用后端的金额重新渲染。结算页的“送达时间选择器”是我觉得比较有意思的组件。它不是简单的下拉菜单而是结合了时间段、运费、时段剩余量的复合信息展示。用户选择一个配送时段时除了看到“今天 17:00-18:00”之外还能看到该时段是否已约满、是否需要额外支付“夜间配送费”。实现上我用自定义弹层组件做了一套时间轴控件支持左右滑动切换日期上下滚动切换时段。支付方式上生鲜场景比普通电商更依赖“先付款后配送”的付费模式因为货品是生鲜食材货到付款的拒收率太高。但考虑到部分老用户尤其老年人的习惯我们保留了余额支付和线下支付两种补充方式。前端接入支付时有一个坑支付结果回调的时延。客户端调起支付后用户完成支付的结果是异步返回的短则几百毫秒长则几十秒。前端需要做轮询等待确认订单状态变为“已支付”后再跳转到订单详情页。我设置了10秒的轮询周期超过30秒还未确认则提示用户“支付结果确认中请稍后在订单列表查看”。3.5 订单中心与履约追踪用户支付完成后的体验直接决定了这个闭环能不能“扣”住。用户在订单列表看到的状态变化顺序是待支付 → 待发货拣货中→ 配送中 → 已送达 → 待评价。前端要做的事是让这个状态变化过程“可视化”给用户明确的时间预期。订单详情页我设计了一个履约时间轴按时间顺序展示关键节点下单时间、支付时间、仓库拣货完成时间、配送员接单时间、订单送达时间。每个节点到达时前端会收到后端通过WebSocket推送的状态变更消息自动刷新页面并弹Toast提醒用户。WebSocket在跨端框架uni-app里支持情况略有差异App端和小程序端可以直接使用uni.connectSocket但不同平台的断线重连机制不一致。我封装了一个统一的socket管理工具处理连接建立、心跳检测、断线重连、消息分发等逻辑。// socketManager.js class SocketManager { constructor() { this.socketTask null; this.isConnected false; this.reconnectCount 0; } connect() { this.socketTask uni.connectSocket({ url: SOCKET_URL, success: () {} }); this.socketTask.onOpen(() { this.isConnected true; this.reconnectCount 0; // 发送心跳消息 this.startHeartbeat(); }); this.socketTask.onMessage((res) { this.dispatchMessage(res.data); }); this.socketTask.onClose(() { this.isConnected false; this.reconnect(); }); } reconnect() { if (this.reconnectCount 5) { setTimeout(() { this.reconnectCount; this.connect(); }, 3000 * this.reconnectCount); } } }地图追踪功能是配送中模块的亮点。我们用uni-app的map组件接入了第三方地图SDK展示配送员的实时位置和预计送达时间。这里有个技术细节地图SDK的原生插件在App端嵌入时要处理好与跨端框架的桥接层通信尤其是在iOS端涉及到UIView和原生地图控件的层级覆盖问题。实测下来最稳妥的方案是使用地图SDK官方提供的uni-app插件而不是自己封装社区维护的插件已经解决大部分兼容问题。3.6 售后服务与评价体系生鲜商品最大的售后痛点是“货不对板”和“品质问题”。用户收到一箱草莓发现有磕碰第一反应不是找客服而是打开App看怎么申请退款。所以售后入口必须做得极其显眼。我在订单详情页的底部固定了两个按钮“申请售后”和“再次购买”售后按钮采用高饱和色让用户一眼看到。售后流程前端要实现三个状态申请中、处理中、已完成。用户提交售后申请时最多可以上传3张图片作为凭证。我做了图片压缩处理单张图片超过2MB时前端先用canvas压缩到合适尺寸再上传这样既能保证清晰度又不至于因为上传时间过长让用户放弃操作。售后申请完成后用户最关心的是“钱什么时候退回来”。前端要展示退款进度的每一环已提交申请 → 商家审核中 → 退款处理中 → 退款成功。每个环节的预计耗时也要展示清楚减少用户焦虑。我的经验是在退款成功或失败的结果节点除了页面状态更新之外还要额外推送一条App消息通知。因为很多用户提交售后后就退出了App如果退款成功了一条Push通知能大幅提升用户好感度。4. 前端优化与性能调优性能调优这部分我放在最后写是因为它前面的功能开发要全部完成才看得出来瓶颈。生鲜App的用户场景和普通App有个显著区别用户打开App通常带着急迫情绪赶时间买菜、准备做饭所以性能优化优先级极高。我们内部定了一个指标从点击App图标到首页可交互时间不能超过2.5秒。4.1 首屏加载时间优化方案首屏加载的优化维度有三个网络请求数、资源体积、渲染效率。网络请求数方面首页的banner图、分类导航、推荐商品、公告信息全部合并为一个聚合接口后续想关闭某个模块时前端做数据分发即可。资源体积方面图片是主要瓶颈我的处理方式是使用WebP格式替代JPEG压缩率提升约30%按机型尺寸动态请求不同分辨率的图片比如2K屏和1080P屏请求图片URL的参数不同所有图片加懒加载页面初始只加载首屏可见区域的图片。渲染效率这个维度重点是减少setData的数据量。尤其在微信小程序端每次setData超过256KB会导致明显卡顿。购物车列表如果是整体setData30件商品的数据量很容易超限。我把列表拆成独立的子组件子组件内部自己维护购物车数量和勾选状态父组件只传递商品ID和基础信息、通过事件监听子组件的变更。这样每次数据更新只setData变更的那个子组件性能提升非常明显。4.2 缓存策略与离线可用性生鲜App有大量“低时效性”数据比如商品类目树、配送说明、帮助中心文案这些内容一周都未必变一次。如果每次启动都重新请求浪费流量也拖慢加载速度。我在uni.setStorage和uni.getStorage的封装基础上做了一层简单的缓存管理器// cache.js const CACHE_PREFIX fresh_cache_; const CACHE_EXPIRE 7 * 24 * 3600 * 1000; // 7天过期 export function getCache(key) { const cacheData uni.getStorageSync(CACHE_PREFIX key); if (!cacheData) return null; if (Date.now() cacheData.expireTime) { uni.removeStorageSync(CACHE_PREFIX key); return null; } return cacheData.data; } export function setCache(key, data, expireTime CACHE_EXPIRE) { uni.setStorageSync(CACHE_PREFIX key, { data, expireTime: Date.now() expireTime }); }商品详情页同样做了缓存。用户上次浏览过的商品再次打开时可以直接从缓存渲染同时后台静默拉取最新价格和库存进行校准。如果商品价格发生变化页面上会有一个小动画提示“价格已更新”这比单纯刷一个loading转圈好很多。4.3 骨架屏与用户体验细节骨架屏是我强烈推荐做的一个体验优化尤其是生鲜这种数据更新频率高的App。用户进入页面的前几百毫秒如果能看到一个有内容轮廓的页面骨架心理等待时间会大幅下降。相比之下一个空白的loading转圈页面在用户感知里仿佛过了一个世纪。骨架屏的实现方案我试过两种最终选了代码生成方式。第一种是手动写每个页面的骨架屏工作量大、样式容易和真实页面不一致第二种是用工具根据Vue模板自动生成骨架屏样式比如通过vue-skeleton-webpack-plugin构建时自动扫描页面结构生成对应的骨架屏占位图。这种方式维护成本低页面结构变化后重新构建即可。具体到生鲜场景骨架屏有几个区域需要特别设计分类导航可以做成圆角矩形块商品图片位置可以做成圆角方形标题栏做成渐变灰条。关于骨架屏的显隐逻辑我用的是“首帧渲染”方案页面挂载时先渲染骨架屏结构等接口数据返回后再用真实内容替换中间不需要额外的loading状态切换动画数据到了直接用v-if切换。5. 常见问题与排查技巧实录这部分记录了我在开发过程中遇到的几个典型问题每个都是花了不少时间踩坑才定位到根因的。整理出来给大家做个参考。5.1 商品数量步进器的数据状态不同步问题场景用户在商品详情页点击“加入购物车”然后进入购物车页面修改数量再返回详情页时详情页上的步进器显示的数量还是旧的。这个问题的根因是详情页和购物车页各自维护了一份商品数量状态没有做数据同步。解决方法是把购物车的数量状态提升到vuex中统一管理所有页面从store读取数量值、通过mutation修改。同时给store的购物车模块加上持久化方案用户杀掉App重新打开后购物车数据能正确恢复。// store/cart.js const cartStore { state: { items: [] // [{ id, name, price, qty, stock, selected }] }, mutations: { updateQty(state, { id, qty }) { const item state.items.find(i i.id id); if (item) { item.qty qty; this.commit(cart/persist); } }, persist(state) { uni.setStorageSync(cart_items, state.items); } } };5.2 分享功能在iOS端无法唤起App生鲜App做老带新活动时通常会把商品链接分享到微信用户点击后跳转App。但实测在iOS端从微信打开分享链接后无法直接唤起我们的App。排查原因有两点首先iOS的Universal Link需要后端配合配置apple-app-site-association文件并且前端调用uni.share时分享的URL必须是配置过Universal Link的域名其次App端需要在前端处理来自分享链接的参数比如App是冷启动还是热启动解析参数的方式不同。// App.vue 处理分享链接参数 onLaunch(options) { // 冷启动时通过scene拿到query if (options.query options.query.goodsId) { this.routeToGoodsDetail(options.query.goodsId); } }, onShow(options) { // 热启动时通过scene拿到query if (options.query options.query.goodsId) { this.routeToGoodsDetail(options.query.goodsId); } }这里有个经验App端唤起后给用户呈现的落地页要仔细设计。用户从微信分享链接进入通常是看到某个商品感兴趣所以直接跳转详情页是合理的。但如果链接是活动页落地页应该保留活动上下文让用户知道“我在参与一个什么活动”。5.3 支付结果回调丢失导致订单状态不更新这是我们上线后遇到的最严重的bug。用户支付成功了微信/支付宝的支付结果也返回了但App端订单状态一直停留在“待支付”。用户反复弹窗问为什么扣了钱没看到订单客服直接被问爆了。排查后发现问题出在支付回调通知的时延上。客户端的支付回调回调给服务端服务端更新订单状态后再通过WebSocket推送给前端。正常情况下这个链路很快但高峰期WebSocket推送会延迟几秒。用户支付成功后如果不等待直接杀掉App进程再打开时WebSocket还没来得及推送页面自然还显示“待支付”。解决方案是双保险前端在支付成功后主动轮询订单状态接口每2秒一次最多轮询5次轮询未果的情况下用户重新进入订单列表时强制刷新一次订单状态。同时服务端在订单状态变更时通过消息推送服务给App发一条通知前端收到通知后主动拉取最新订单状态。5.4 常见问题速查表问题描述可能原因解决方式首页分类无法点击分类导航组件z-index设置错误检查弹窗和菜单的z-index层级分类导航z-index需大于普通内容区域加购后购物车角标不更新角标数据来源是本地state而非vuex将角标数量接入购物车store统一更新iOS键盘弹起遮挡结算按钮输入地址时键盘高度未知监听键盘高度变化结算按钮位置动态调整商品图片加载缓慢使用了原图未压缩图片URL拼接压缩参数或使用WebP格式优惠券计算金额不一致前端算法与后端不一致以后端金额为准前端只做展示和比对App启动白屏入口页面渲染阻塞入口页使用骨架屏首屏内容分段渲染购物车大量商品滑动卡顿列表整体渲染拆分子组件减少无效setData配送时间选择器无法滑动触摸事件与页面滚动冲突给时间选择器区域设置catchtouchmove阻止冒泡6. 项目经验总结与扩展思考写到这里整个生鲜配送商城App前端功能版块的构建过程基本都过了一遍。我个人在实际操作中最大的感受是前端开发的难点从来不是“写出一个能用的页面”而是“把几十个页面串联成一个真正顺滑的采购闭环”。每个页面都只是一个节点节点之间的衔接是否顺畅、状态是否一致、反馈是否及时才是决定用户愿不愿意留下来的关键。如果让我给后来做类似项目的人一个建议那就是在开发前一定先把“闭环地图”画出来。把用户从进入App到完成采购的所有路径、每个路径上的关键动作、每个动作后的反馈都列清楚再进入编码阶段。这个习惯能帮团队避免超过一半的返工比任何技术方案都值钱。这个项目后续还有几个值得扩展的方向第一是智能推荐算法的前端呈现把用户的购买历史和浏览行为转化成更个性化的首页排序第二是多端联动的深度优化比如用户在小程序端加购、在App端结算这类跨端场景的数据同步要做专门的链路设计第三是大促高并发场景的前端降级方案包括限流页、排队提示、静态化首页的快速切换。开发还没结束生鲜这个赛道的用户对体验的要求只会越来越高前端要做的还有很多。以上是我个人在项目实践中的一些积累希望能给正在做或者准备做同类项目的朋友一些参考。