企业官网建设流程全解析

这个项目做完之后我最大的感触是：如果只看"商城"两个字，很多人第一反应是单体就够用，甚至一个后端服务加一个管理后台就行。但当你真正处理农产品这个品类时，会发现订单、库存、营销、溯源、物流这些模块的诉求完全不一样，改动频率和发布节奏也完全不同。这也是为什么我最终选择了SpringBoot + SpringCloud微服务来支撑后端，用Vue做管理后台、微信小程序做C端售卖端的组合。这篇文章就把整个项目的设计与实现过程梳理一遍，包括为什么这么拆、每个服务怎么落地、小程序端怎么对接、部署时有哪些坑，希望能给正在做类似选题或真实业务的人一些参考。

1. 农产品商城的业务特点决定了架构不能拍脑袋

1.1 农产品和标品电商看着像，骨子里不一样

做技术的人容易犯一个毛病：看到"商城"两个字就往通用电商模板上靠，用户表、商品表、订单表、购物车表一建，觉得系统已经完成了一半。但农产品的业务模型和标品电商差距非常大，至少在下面几个维度上会直接逼你改表结构、改接口、改流程：

• 商品粒度复杂。一个西红柿，可以按产地分、按规格分（大果、中果、小果）、按批次分，同一商品不同批次可能进价不同、库存不同、检测报告不同。标品电商那种"一个SPU下面几个SKU"的模型能做，但会很勉强。
• 价格不是常量。产地直供模式里，价格受行情波动、当日供需、活动补贴影响，经常要支持"今日价""秒杀价""会员价"多层价格策略。价格逻辑如果和商品基础信息绑死在同一张表里，每次调价都要全表更新，很痛。
• 履约链路区域化。农产品销售不只是发货到家，还可能包含产地直发、同城配送、社区自提点、冷藏周转仓等。订单生成后，后续要派单给供应商、配送站，还要记录冷链节点温度。
• 溯源是信任核心。消费者买农产品，尤其高单价的水果、肉禽，很在意"这东西从哪来、有没有检测报告"。溯源数据要和订单关联、要能展示在小程序端，这又是一个独立领域。

说白了，这个系统不是一个简单的交易网站，而是"商品管理 + 交易 + 营销 + 履约 + 溯源"的复合系统。模块之间的逻辑复杂度、变更频率、数据私有关联度都很高，这为后面选择微服务拆分埋下了伏笔。

1.2 单体不是跑不动，而是改不动

说句公道话，以大部分农贸商城的日订单量，单体架构完全跑得动。数据库连接池撑个几千并发不难。真正的瓶颈不在性能，而在维护性和发布效率。

单体系统里，商品团队要改价格策略，订单团队要改售后流程，市场团队要加秒杀活动，这些代码可能散落在同一个工程里，改一个地方就要把整个应用重测一遍。而且只要某个模块出现内存泄漏或线程阻塞，整个商城都不可用，这叫"爆炸半径太大"。

微服务的好处不是把系统变快，而是把系统拆成"负责人明确的小单元"。订单服务挂了，商品浏览和秒杀还能继续；营销服务要发布新活动，不需要把支付服务一起重启。尤其是团队里有多个开发同时推进时，服务边界清晰能省掉大量沟通和冲突成本。

但也必须诚实：微服务不是银弹。对于一个三个人团队、一个月交付的项目，硬拆八个服务可能反而把自己拖垮。所以我在设计之前列了一个判断表，符合两条以上才考虑单独拆服务：

农产品商城这条业务链路里，"商品+营销+价格"是一个高频繁改动的域，"订单+支付+履约"是一个对一致性和可靠性要求极高的域，"用户+会员+会话"是一个相对稳定但访问量大的域，"溯源"是一个独立且数据来源多样的域。每一条都指向拆分。

1.3 我最终划分出的服务边界与数据边界

拆分服务最容易犯的错是按"页面"拆，比如把"首页服务""购物车服务""我的服务"拆出来，这种拆法毫无意义。真正的拆分要按业务能力和数据内聚来划分。我最终确定的边界是这样的：

• user-service：用户、会员等级、收货地址、认证授权信息（不包括微信登录的 code 换取逻辑，那个放在网关层做）。
• product-service：商品类目、SPU/SKU、规格批次、库存流水、价格策略。这个服务是最庞杂的一个，因为农产品商品模型复杂。
• order-service：购物车、订单主流程、订单状态流转、售后单。
• payment-service：支付渠道、支付单、退款单，所有和微信支付/其他渠道打交道的都在这里。
• marketing-service：优惠券、拼团活动、限时秒杀、积分。
• logistics-service：发货单、物流轨迹、自提点分配、配送节点。
• trace-service：溯源批次、检测报告、生产记录，这个服务数据来源很多，包括后台录入和供应商导入。
• gateway：统一入口、路由转发、鉴权、限流。

与之配套的是数据库的设计原则：每个服务至少独立一个库，绝不跨服务直接访问对方的表。比如订单表里有商品快照，这个快照字段是从商品服务同步过来的冗余数据，而不是每次下单实时去查询商品表。这样设计虽然带来了数据冗余和同步复杂度，但换取了服务之间彻底解耦，线上出问题时可以各自回滚，不会因为一条 SQL 把两个服务拖死。

服务间通信也做了区分：需要同步返回结果的调用（比如下单前校验库存）用 OpenFeign；不需要立即知道结果的（比如支付成功后通知订单服务改状态）用消息队列异步解耦。这个原则在后面订单链路里具体体现。

2. SpringCloud组件选型：不是用得越多越高级

2.1 这些组件真正被用上的只有六七个

SpringCloud 全家桶组件非常多，但从零搭建这个项目时，我刻意做了克制。网上很多教程喜欢把注册中心、配置中心、网关、熔断、限流、链路追踪、消息总线、分布式事务全塞进去，结果光配置就写了几百行，部署环境还要额外起四五个中间件，项目本身反而没写多少业务代码。

我的最终选型是这样的：

Nacos 选它的原因很直接：它同时干注册中心和配置中心两件事，中文文档和社区案例多，遇到问题基本都能搜到。早期版本有人诟病它 AP/CP 模式切换复杂，但对这个项目来说，用默认的 AP 模式服务发现就够了。配置中心的好处是每个服务连接 Redis、MQ、数据库的参数可以从配置文件集中管控，改完不用重新打包上线，Nacos 会推送刷新。

有一个小建议：如果你的团队以前没接触过微服务，第一步先把"注册中心+网关+两个业务服务"跑通，再逐步加 Sentinel、Seata 这些高级组件。一次到位往往意味着一次线上事故。

2.2 管理后台用Vue、C端用小程序是场景决定的

这个项目的两端产品形态差异其实很大，所以我没有尝试"一套代码到处运行"的激进方案。

管理后台的核心需求是复杂表格、多条件筛选、数据统计、商品上下架、价格调整、优惠券配置、溯源信息录入，用户是运营和客服，使用场景是固定电脑和浏览器。这种场景下 Vue 生态非常合适：Vue 3 + TypeScript + Element Plus + Pinia + Vite，组合式 API 写业务逻辑很顺手，Element Plus 的表单和表格组件能直接覆盖大部分后台诉求。

C端小程序则完全不一样。农产品的购买入口大量来自微信社群、朋友圈转发、拼团接龙，用户在微信里点开链接就能完成购买，这是 H5 很难替代的场景。微信小程序除了入口方便，还天然提供登录、支付、订阅消息能力。虽然 H5 也可以调起微信支付，但整体体验和转化率不如小程序。

小程序端我选了原生开发，没有上 Uniapp。原因是这个商城的 C 端页面不算多，首页、分类、购物车、订单、我的五个 Tab 就构成了主体，原生 WXML 开发调试更直接。如果以后要发布到支付宝小程序、抖音小程序，再迁移到 Uniapp 也不迟，因为接口层已经统一走网关，前端框架只是皮。

2.3 版本搭配和基础中间件

版本搭配是微服务项目第一个隐藏的大坑。SpringCloud 和 SpringCloud Alibaba 各版本之间有严格的对应关系，不对应就会出现依赖冲突或者组件无法注入。我整理了两条可行的路线：

• 稳妥路线：Spring Boot 2.7.x + Spring Cloud 2021.x + Spring Cloud Alibaba 2021.0.x + JDK 8。这套组合在网上的资料最多，很多生产项目还在用，踩坑容易搜到答案。
• 升级路线：Spring Boot 3.2.x + Spring Cloud 2023.x + Spring Cloud Alibaba 2023.x + JDK 17。新项目可以考虑，但注意部分旧版依赖不支持。

我这里选的是稳妥路线。不是说新版本不好，而是交付项目时间紧张，稳定优先。另外建议整个项目用 Maven 的 BOM（Bill of Materials）统一管理依赖版本，父 pom 里锁死 SpringCloud 和 Alibaba 的版本号，子服务不需要再单独指定，避免某个子服务引入一个高版本依赖把全局弄崩。

中间件层面，MySQL 8.0 存核心交易数据，Redis 做缓存、分布式锁、秒杀预扣库存，RocketMQ 负责异步消息。Redis 的使用要提前规划好 key 前缀，比如商品缓存product:info:{skuId}，库存product:stock:{skuId}，会话user:token:{token}，这样排查问题和清理缓存时才能精准操作，不会误删业务数据。

3. 后端核心实现：骨架、统一响应、网关鉴权与订单状态机

3.1 多模块工程拆法：把接口定义和业务实现分开

后端工程结构我采用 Maven 多模块管理。很多人第一次做微服务时容易把 Feign 接口定义直接写在调用方服务里，导致服务间产生循环依赖。为了避免这个问题，我把所有 Feign 接口单独放在一个mall-api模块里，任何服务都可以依赖它，但不会因为接口定义产生双方互引。

mall-agriculture-parent ├── mall-common # 统一返回体、全局异常、常用工具类 ├── mall-gateway # 网关服务 ├── mall-api # Feign接口定义、DTO对象 ├── mall-modules │ ├── user-service │ ├── product-service │ ├── order-service │ ├── payment-service │ ├── marketing-service │ └── logistics-service

mall-common里的统一返回体是前后端联调的基础。这个类看起来简单，但几乎所有接口都依赖它，一开始必须定清楚：

public class Result<T> { private Integer code; // 20000 成功，非20000 失败 private String message; // 提示信息 private T data; // 数据体 public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 20000; r.message = "success"; r.data = data; return r; } public static <T> Result<T> fail(String message) { Result<T> r = new Result<>(); r.code = 50000; r.message = message; return r; } }

配合@RestControllerAdvice做全局异常捕获，业务代码里只需要抛业务异常，由统一异常处理器转换成 Result 返回，避免每个接口都写try/catch。前端也可以只在请求封装层统一判断code，不用每个页面各自处理错误逻辑。

3.2 网关层的路由、鉴权和限流

网关是这个系统所有流量的总入口。小程序端、Vue 管理后台的所有请求都先打到这里，再按路径前缀转发到对应服务。路径前缀我做了一个约定：

• /api/admin/**转发到管理后台相关服务，要求管理员权限
• /api/wx/**转发到小程序端相关服务，要求普通用户登录
• /api/public/**允许匿名访问，比如商品列表、轮播图、公告

网关配置核心部分大致如下：

spring: cloud: gateway: routes: - id: product-service uri: lb://product-service predicates: - Path=/api/wx/product/**,/api/admin/product/**,/api/public/product/** - id: order-service uri: lb://order-service predicates: - Path=/api/wx/order/**,/api/admin/order/** - id: user-service uri: lb://user-service predicates: - Path=/api/wx/user/**,/api/admin/user/**

网关里我做两件业务相关的事情：JWT 鉴权和基础限流。所有非/api/public/**的请求，先解析 token，把用户 ID、角色信息解析出来放到请求头里，再转发给下游服务。下游服务不再关心 token 怎么解析、session 怎么校验，直接从请求头拿用户信息，这是一个很实用的设计。

限流我用 Sentinel 做了网关级别的规则，比如某商品详情接口每秒钟最多放行多少请求，超出直接返回"系统繁忙"。秒杀活动时这个规则非常重要，它能把压力挡在网关之外，保护后端的商品服务和订单服务不至于被打挂。但注意网关不要做太重的事情，比如不要在网关里查询数据库、做复杂的业务校验，否则网关反而会变成新的瓶颈。

3.3 商品与库存：缓存预检 + 数据库乐观锁兜底

农产品商品信息变化频繁，频繁查数据库不现实。商品详情、首页推荐这些读多写少的数据放 Redis 缓存，配合缓存过期策略。但库存不能只靠缓存，因为它是强一致数据。

下单减库存的核心逻辑是这样的：

1. 用户提交订单，order-service 通过 Feign 调用 product-service 的校验库存接口。
2. product-service 先查 Redis 库存，如果库存不足直接返回失败，减少无效 DB 请求。
3. 通过缓存校验后，执行数据库扣减，使用乐观锁防止超卖：

UPDATE product_sku_stock SET stock = stock - #{num} WHERE sku_id = #{skuId} AND stock >= #{num}

stock >= #{num}这个条件很关键，如果库存已经被别人扣完，这个 SQL 的受影响行数为 0，程序检查到影响行数为 0 就知道扣减失败，然后回滚订单。这种方式不需要给整行数据加锁，是并发扣库存最常采用的方案。

扣减成功后，库存变更通过 MQ 发送一条消息，异步更新 Redis 缓存中的库存数字。这里不要等数据库事务提交后再同步更新 Redis，而是采用"先更新缓存、再发消息、最终由数据库流水做对账"的方式。这样即使消息丢失，只要第二天做个对账任务扫描数据库流水修正缓存即可，不至于超卖。

3.4 支付回调与订单状态机：把强一致变最终一致

支付环节最常见的错误是把支付回调里要做的事情都在回调接口里同步完成：更新支付单、更新订单状态、扣减库存、发短信。回调一旦处理超时，微信会重复调用，接口没有幂等保护，就会出现重复发货、重复发券。

我的做法是把支付回调做成轻量入口：

1. payment-service 收到微信支付回调，先校验签名，确认支付金额和订单号对应。
2. 更新支付单状态为"已支付"，然后立刻给微信返回成功响应，告诉微信"我已经收到了"。
3. payment-service 向 MQ 发一条"支付成功"消息。
4. order-service 消费消息，更新订单状态为"已支付"，再发消息触发物流服务创建配送单、触发营销服务发放积分。

通过消息队列把一次回调拆成了多个异步步骤，每个步骤都能单独重试。消费者里做幂等：消息里带orderId和eventId，处理前先查本地表是否已经处理过这个事件，处理过就直接返回，不会重复执行。

订单状态流转我设计成明确的状态机：待支付 -> 已支付 -> 配货中 -> 已发货 -> 已完成，中间分支有已取消、退款中、已退款。状态变更的 SQL 语句都要带上当前状态条件，比如从"待支付"变"已取消"的 SQL 必须写WHERE order_id = ? AND status = 待支付。这样能避免用户同时操作取消订单和管理员误发货时，后写的状态把先写的覆盖掉。

4. 小程序端设计与实现：不只是套一个模板

4.1 页面骨架与农产品商城的特色设计

小程序的页面框架走的是经典 TabBar 五页面：首页、分类、购物车、订单、我的。但针对农产品这个品类，首页不能做成普通电商的"简单 Banner + 商品瀑布流"，那样没有辨识度。

首页我加了这几个模块：产地直供推荐、今日秒杀、农产品溯源检测入口、热门产地标签。特别是溯源检测入口，点进商品详情页就能看到该批次的产地、采摘日期、检测报告，这个功能对建立信任感帮助极大。后端对应的就是 trace-service 提供的溯源数据接口，商品详情页通过skuId或者batchNo查询。

页面布局上，因为要展示大量商品图片和溯源证书图，图片压缩很关键。管理后台在商品上传时就把图片压缩成多尺寸（缩略图、列表图、详情图），小程序端按场景加载对应尺寸，避免首屏加载一堆原图导致白屏时间过长。

4.2 列表滚动加载与防重复请求

"小程序页面列表加载更多"是网上问得非常多的问题，这个项目的首页商品推荐、分类页商品列表、订单列表都会用到。核心逻辑是onReachBottom触发下一页加载，但必须加锁防重。

Page({ data: { list: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onReachBottom() { if (this.data.loading || !this.data.hasMore) return; this.loadMore(); }, async loadMore() { this.setData({ loading: true }); try { const res = await request({ url: '/api/wx/product/list', data: { page: this.data.page, pageSize: this.data.pageSize } }); const list = this.data.list.concat(res.data.records); this.setData({ list, page: this.data.page + 1, hasMore: res.data.current < res.data.pages }); } finally { this.setData({ loading: false }); } } })

loading这个标志位是防止用户快速滚动时连续触发多个请求。hasMore的判断用分页接口返回的current < pages，比records.length < pageSize更可靠。加载完成后展示"已经在底部"或"没有更多了"的提示，这个小细节能明显改善用户体验。

4.3 微信登录、request 封装与支付对接

小程序登录我采用静默登录方案：用户打开小程序时，调用wx.login拿到临时code，发给后端，后端用 code 向微信接口换取openid，生成自己的token返回给小程序。之后所有请求在 header 里带上 token。

const request = (options) => { return new Promise((resolve, reject) => { wx.request({ url: baseUrl + options.url, method: options.method || 'GET', data: options.data || {}, header: { 'Content-Type': 'application/json', 'X-Access-Token': wx.getStorageSync('token') || '' }, success(res) { if (res.data.code === 20000) { resolve(res.data.data); } else if (res.data.code === 40100) { // token 过期，重新静默登录后再请求 reloginAndRetry(options).then(resolve).catch(reject); } else { wx.showToast({ title: res.data.message, icon: 'none' }); reject(res.data); } }, fail(err) { reject(err); } }); }); };

注意 401 的处理逻辑。用户使用到一半 token 过期是常见情况，不能把用户一脚踢回登录页，尤其农产品商城的很多用户是中老年群体，让他们重新授权一次很容易直接放弃下单。这里我在 401 时自动重新登录并重放原请求，用户基本无感知。

支付流程是前端调wx.requestPayment，所需参数由后端统一下单接口返回：

timeStamp: 时间戳 nonceStr: 随机字符串 package: prepay_id=xxx signType: RSA/MD5 paySign: 签名

这里有个经验：用户调起支付后，哪怕微信返回"支付成功"，也不要立刻在前端页面展示"已支付"。微信支付的回调是异步的，以后端确认支付成功再更新订单状态为准。所以支付成功跳转后，页面应该轮询订单状态接口（每 2 秒查一次，最多查十次），拿到已支付状态后再展示成功页。这样能避免用户支付成功但网络回调延迟时，页面显示"待支付"造成的恐慌和重复提交。

5. 从本地到服务器：双端联调与部署的完整链路

5.1 本地联调的跨域与代理设置

微服务项目本地联调比单体麻烦很多，因为浏览器或小程序直接访问多个服务端口肯定有跨域问题。我的做法是统一走网关。Vue 管理后台在本地开发时用 Vite 的 proxy 代理，把所有/api请求转到网关地址，浏览器看到的始终是同源的，自然没有跨域问题。

// vite.config.js export default { server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', // 网关地址 changeOrigin: true } } } }

小程序端本地调试更方便，微信开发者工具可以在"详情 -> 本地设置"里勾选"不校验合法域名"，这样就能直接请求http://localhost:8080。但注意这个做法只在开发环境有效，真机预览和正式发布时必须配置https合法域名，否则请求会被微信拦截。

联调时建议给小程序端和管理后台分配不同的接口前缀（/api/wx/**和/api/admin/**），这样网关能区分入口做不同权限校验，前端团队也能在日志里快速分清楚请求来自哪个端。

5.2 Docker Compose：别在一台服务器上手动跑八个 jar

项目部署时最痛苦的事情就是运维要手动启动八个服务，每个人启动顺序不一样，Nacos 还没就绪业务服务就启动，结果服务注册不上，排查半天。所以我把整套后端环境用 Docker Compose 编排，一条命令启动所有依赖。

services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 volumes: - ./mysql/data:/var/lib/mysql redis: image: redis:7-alpine ports: - "6379:6379" rocketmq: image: apache/rocketmq:5.1 nacos: image: nacos/nacos-server:v2.2.3 environment: MODE: standalone ports: - "8848:8848" - "9848:9848" gateway: build: ./mall-gateway depends_on: - nacos ports: - "8080:8080" product-service: build: ./mall-modules/product-service depends_on: - nacos - mysql - redis

这里有一个关键配置：服务之间互相调用不能再用localhost，因为每个容器是独立的网络命名空间。要让业务服务注册到 Nacos 时使用容器内网地址，比如nacos容器名和product-service容器名就是它在 Docker 内网里的 hostname。如果写成localhost:8848，容器里找不到 Nacos，服务会一直注册失败。

5.3 Nginx 反向代理与微信小程序对 HTTPS 的硬要求

小程序正式环境有一个强制要求：所有接口请求必须是 HTTPS，并且域名要在小程序后台配置为request合法域名。这意味着服务器上光有服务和数据库不够，还要有一个入口做 HTTPS 终结。

我的做法是在最前面加一层 Nginx，配置大概如下：

server { listen 443 ssl; server_name api.example.com; ssl_certificate /etc/nginx/ssl/api.example.com.pem; ssl_certificate_key /etc/nginx/ssl/api.example.com.key; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

管理后台的静态文件则由另一个 Nginx server 块提供服务，Vue 打包后的dist目录直接指向站点根目录。管理后台也做成 HTTPS，魔法上避免浏览器地址栏的"不安全"提示影响运营同事使用。

部署上线前我踩过的几个比较典型的坑整理成表格：

6. 经验复盘：微服务项目最容易翻车的三个决策点

6.1 分布式事务别硬上，能异步就异步

刚做微服务的人第一反应往往是"跨服务更新数据必须分布式事务"，于是引入 Seata 的 AT 模式，把下单、扣库存、生成履约单包进一个全局事务。但全局事务有代价：事务范围越大，锁持有的时间越长，并发性能越差，而且任何一个参与方网络抖动，整个事务就要回滚，用户体验极差。

我的建议是：把强一致的需求先梳理一遍，能通过业务设计转成最终一致的，尽量转成最终一致。

比如下单扣库存，其实并不需要订单服务和商品服务在同一个数据库事务里。完全可以先扣库存（本地事务），扣成功再创建订单（另一个本地事务），创建订单失败发消息冲正库存。虽然有一个短暂的时间窗口可能出现"库存扣了但订单没建"，但通过消息队列的重试和补偿机制，最终会收敛到正确状态。对商城这种业务来说，最终一致完全够用，用户不会感知到中间状态。

Seata 只在极少数真正需要强一致的场景用，比如"用户余额扣减 + 积分增加"这种同一账户体系内绝对不能出现一边成功一边失败的操作。其他地方，优先考虑状态机 + 消息 + 对账任务。

6.2 版本依赖要锁定，别信网上的老配置

SpringBoot、SpringCloud、SpringCloud Alibaba 三者之间的版本对应严格到让人抓狂。网上很多文章年代久远，照着复制下来，SpringCloud 2021 的依赖配到 Spring Boot 3.2 上，直接项目起不来，报错还千奇百怪。

建议项目一开始就在父 pom 里用官方 BOM 锁版本：

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>2021.0.8</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2021.0.5.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

只要版本锁死，后面加任何依赖都先检查有没有同组件不同版本的冲突。被最坑的一次是子服务单独引入了高版本的 hutool，它传递依赖的某个包和 SpringCloud 组件冲突，导致网关路由一直不生效，查了整整半天。

6.3 小程序的体验优化比后端更影响成单率

很多做后端出身的人容易忽视小程序端的体验，觉得接口通、页面能点就算完成。但实际上在农产品消费场景里，用户往往是四五十岁的群体，页面响应稍慢、操作步骤多了，转化率掉得很明显。

几个我后来专门补的优化点：

• 商品第一屏只加载轮播图和价格信息，详情大图用懒加载，不要所有图片一次性请求。
• 购物车图标上的角标数字要本地实时更新，不用等接口刷新。
• 下单页的默认地址要自动填充最新使用过的地址，不要让用户重新选。
• 把"显示商品产地、检测报告、物流节点"放在显眼位置，这类信息能显著降低售后咨询量。
• 针对长列表，分页大小设为 10 到 15 条，太多会卡，太少用户不停滑动触发请求反而更耗流量。

小程序端还有一个容易被忽略的问题：接口请求失败时不要只弹 toast，要区分"网络失败可以重试"和"服务异常请联系客服"，给出对应的操作按钮。老年人用户遇到报错经常会直接退出小程序，我们要尽量把错误页面做得更友好。

说实话，把微服务完整跑通并不难，真正难的是让每个环节都能被运维、测试和运营同事理解。后端接口规范、网关路由规则、订单状态机、小程序请求封装，每一块都要有文档和日志可查。架构不是炫技，它是为了回答"明天上线谁负责、出故障影响多大、改需求多久能发版"这些问题。如果你也正在做一个类似的商城类项目，在纠结要不要拆微服务，我的建议是先把业务边界和状态流转图画清楚，再决定技术栈，会少走很多弯路。