企业官网建设流程全解析

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-router：uni-app官方路由方案，支持路由守卫，权限控制必需
• uview-plus：UI组件库，它的商品卡片、数量步进器、支付键盘样式很贴合电商场景
• 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会导致明显卡顿。购物车列表如果是整体setData，30件商品的数据量很容易超限。我把列表拆成独立的子组件，子组件内部自己维护购物车数量和勾选状态，父组件只传递商品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 常见问题速查表

6. 项目经验总结与扩展思考

写到这里，整个生鲜配送商城App前端功能版块的构建过程基本都过了一遍。我个人在实际操作中最大的感受是：前端开发的难点从来不是“写出一个能用的页面”，而是“把几十个页面串联成一个真正顺滑的采购闭环”。每个页面都只是一个节点，节点之间的衔接是否顺畅、状态是否一致、反馈是否及时，才是决定用户愿不愿意留下来的关键。

如果让我给后来做类似项目的人一个建议，那就是在开发前一定先把“闭环地图”画出来。把用户从进入App到完成采购的所有路径、每个路径上的关键动作、每个动作后的反馈都列清楚，再进入编码阶段。这个习惯能帮团队避免超过一半的返工，比任何技术方案都值钱。

这个项目后续还有几个值得扩展的方向：第一是智能推荐算法的前端呈现，把用户的购买历史和浏览行为转化成更个性化的首页排序；第二是多端联动的深度优化，比如用户在小程序端加购、在App端结算，这类跨端场景的数据同步要做专门的链路设计；第三是大促高并发场景的前端降级方案，包括限流页、排队提示、静态化首页的快速切换。

开发还没结束，生鲜这个赛道的用户对体验的要求只会越来越高，前端要做的还有很多。以上是我个人在项目实践中的一些积累，希望能给正在做或者准备做同类项目的朋友一些参考。