乡镇农产品电商这两年被提得很多，但真正落到乡镇实地，会发现需求和城市电商完全不同。农产品不是标准品，宣传和销售必须绑定在一起——光有商城没有产地故事，用户不信任；光有宣传页没有下单入口，流量就白费了。这个基于 SpringBoot + Vue 的农产品宣传与商城一体化系统，想解决的就是这件事：把乡镇风土人情、农产品溯源信息做成宣传内容，同时把商品浏览、购物车、下单支付跑通，形成从“看到”到“买到”的闭环。适合正在做毕业设计、接乡镇信息化项目、或者想从零搭一个前后端分离电商 demo 的开发者参考。我自己的项目也是在这个思路下逐步完善的，下面把设计过程和踩坑记录都摊开讲。
1. 乡镇农产品触网：这个系统到底解决了什么问题
1.1 乡镇农产品电商的痛点与需求拆解
乡镇农产品做线上销售，最难受的不是“没有货”，而是“没人信”。城里消费者打开一个商城，看到照片精美的水果、大米、土鸡蛋，第一反应往往是：这图是不是盗的？这货发出来还能新鲜吗？这个乡镇到底在哪？所以在真实项目里，宣传模块和商城模块是同等重要的，甚至宣传要先于商城。系统里必须有乡镇介绍、产地实拍、农户故事、种植/养殖过程的图文记录，让用户先建立信任，再点击“加入购物车”。
这个需求拆下来大概分四个角色：管理员维护商品、分类、轮播图和宣传内容；农户/商家在后台发布农产品、管理库存；普通用户浏览宣传页、下单选地址；游客只看不买。这里面“宣传内容管理”是很多通用电商系统忽略的，却是乡镇项目的灵魂。我把宣传模块落成了独立的文章/图集管理，支持富文本编辑和图片上传，字段包括标题、封面、正文、关联商品ID、发布时间。用户在宣传详情页看到某款农产品的故事，点“去购买”直接跳到商品详情页，这个转化路径比单纯摆商品列表自然得多。
1.2 系统功能边界：宣传站与商城如何一体化
设计初期我犯过一个大方向错误：想做一个“大而全”的平台，包括资讯、视频、直播、拼团、分销……后来发现对于乡镇级别的运营体量来说，功能太多反而是负担。最终明确的功能边界是：宣传端（乡镇风采、农产品故事、公告通知）+ 商城端（商品分类、商品列表、详情、购物车、订单、收货地址）+ 管理端（商品管理、宣传内容管理、订单处理、用户管理、轮播图配置）。
这里有一个关键判断：砍掉哪些功能？直播和视频是乡镇宣传的强需求，但实现成本高，而且对带宽和运维要求不低。我第一期选择用图片+文字+轮播图承载宣传，预留了视频字段但没做视频上传和转码。如果要做，可以走对象存储+播放器方案，但那是二期的事了。这个取舍很重要——很多项目死在“什么都要有”，而不是死在“功能不够”。
1.3 角色划分与使用流程
系统分三个端口，我自己用一张表把角色权限理清了：
| 角色 | 登录端 | 核心权限 |
|---|---|---|
| 游客 | Web端 | 浏览宣传页、查看商品列表、搜索 |
| 普通用户 | Web端 | 游客权限 + 下单、购物车、地址管理、订单查询 |
| 管理员 | 管理后台 | 用户权限 + 商品/分类/订单/宣传内容/轮播图/公告管理 |
用户主流程是：访问首页 → 看到乡镇介绍或轮播图 → 进入宣传文章 → 跳转商品详情 → 加入购物车 → 结算下单 → 填写地址 → 订单生成。管理端主流程是：登录 → 发布宣传内容/上架商品 → 处理用户订单 → 发货 → 完成。整个流程走下来，项目结构基本稳定，后续加功能都是在这些模块上扩展。
2. SpringBoot + Vue 前后端分离的技术底座选择
2.1 为什么是SpringBoot而不是SSH/SSM
如果放在五年前，SSH（Spring + Struts + Hibernate）或者 SSM（Spring + SpringMVC + MyBatis）还是主流，但现在新启动一个 Web 项目，SpringBoot 几乎是无脑选择。它对“配置”这件事做了彻底简化：内嵌 Tomcat、自动装配、starter 机制，三行代码就能起一个可运行的 Web 服务。对于乡镇项目这种需要快速交付、后续可能要交给别人维护的系统，SpringBoot 的优点是“样板代码少，出错概率低”。
这里面最有价值的思维是约定优于配置。SpringBoot 把 springmvc、jackson、tomcat、数据源等一大堆常用组件的默认配置都做好了，你只需要在 application.yml 里改关键项。我做项目时最明显的感受是：过去用 SSM 要花半天配 dispatcherServlet、视图解析器、事务管理器，现在一个 @SpringBootApplication 注解全部搞定。这不是说 SpringBoot 不需要懂原理，而是说它可以让你把精力集中在业务上。
2.2 为什么是Vue而不是JSP/Thymeleaf
同样，前端选 Vue 而不是直接用 Thymeleaf 模板渲染，核心原因是前后端分离带来的协作效率和体验提升。乡镇项目的页面虽然不算多，但宣传页、商城页对交互还是有要求的：购物车数量加减、商品筛选、图片轮播、表单验证。用 JSP/Thymeleaf 做这些东西要靠 jQuery 一把梭，页面一多，JS 逻辑就散落在各个模板里，维护成本直线上升。
Vue 的组件化在这里价值非常大：购物车列表抽成一个 CartItem 组件，商品卡片抽成一个 ProductCard 组件，管理员后台的表格页可以复用同一套分页逻辑。数据驱动视图的思路让我写页面时不再操作 DOM，而是维护 data 和 computed，页面的状态变化自动映射到视图。而且 Vue 的生态对中小项目很友好：Vue Router 管路由、Vuex/Pinia 管状态、Axios 管请求，链路清晰。
2.3 前后端分离给乡镇项目带来的实际收益
很多人觉得前后端分离是“为了技术而技术”，但对这个系统来说，分离带来的实际收益很实在：
- 部署灵活：前端构建成静态文件，可以丢到 Nginx，也可以由 SpringBoot 托管静态资源。后面我选了 Nginx 托管前端 + SpringBoot 只提供 API 的方式，压力分离。
- 并行开发：前端用 Vue 开发页面，后端用 Postman/Swagger 调试接口，两边互不阻塞。我和搭档同时干活的时候效率明显高。
- 多端复用：同样的后端 API，以后如果要做小程序端或者 App 端，前端直接用同一套接口，不需要动后端。
- 错误隔离：前端页面挂了不会影响后端服务，反之亦然。排查问题时，通过 Network 面板快速定位是接口问题还是渲染问题。
2.4 版本选型的坑：SpringBoot 2.x还是3.x，JDK版本怎么定
这个坑必须写一下。SpringBoot 3.x 发布之后，很多教程直接推荐最新版，但实际上 3.x 要求 JDK 17 起步，而且部分第三方 starter 还没完全跟上（尤其是某些老牌 mybatis-generator、代码生成工具）。我做这个项目时用的 SpringBoot 2.7.x + JDK 8，理由很直接：稳定、资料多、遇到问题网上随便搜就能解决。对于生产项目，技术不在于新，在于团队能否驾驭、生态是否成熟。
如果非要上 SpringBoot 3.x，你要确认：本地 JDK 版本是不是 17+；MyBatis 或者 MyBatis-Plus 是否用了支持 3.x 的版本；javax 包名是否要替换成 jakarta；第三方 SDK（比如文件存储、短信服务）的依赖是否兼容。我自己实测下来，2.7 到 3.0 的间隔对普通 CRUD 项目影响不大，但一旦踩到包名替换的坑，排查起来还是挺费时间的。建议初中级项目先用 2.7.x 跑通全流程，再评估升级。
3. 数据库设计：农产品、商城、订单的建模思路
3.1 核心表结构：商品、分类、轮播图、订单
数据库是整个系统的地基，我调试过程中有八成 Bug 都是表设计不合理引起的，后来重构过一次，表结构才稳定下来。核心表包括：
category商品分类表：id、parent_id（支持二级分类）、name、sort、create_timeproduct商品表：id、category_id、name、subtitle、main_image、detail_images、price、stock、unit、is_hot、status、create_timebanner轮播图表：id、image_url、link_url、sort、statusarticle宣传文章表：id、title、cover_image、content、related_product_id、status、create_timecart_item购物车表：id、user_id、product_id、quantity、checked、create_timeorder订单主表：id、order_no、user_id、total_amount、status、receiver_name、receiver_phone、receiver_address、create_time、pay_time、ship_timeorder_item订单明细表：id、order_id、product_id、product_name、product_image、price、quantityuser用户表：id、username、password、nickname、phone、avatar、role、create_timeaddress收货地址表：id、user_id、receiver_name、receiver_phone、province、city、district、detail、is_default
商品表的detail_images我用逗号分隔存多图，而不是另建一张图集表。原因是商品详情图片数量少且固定，查询时一次取回比 JOIN 更高效。数据量上来以后可以拆表，但乡镇项目这个体量，逗号分隔完全够用。
3.2 乡镇特色：地域标签、溯源信息、活动公告怎么设计
通用电商表结构不复杂，但乡镇项目有几个特色字段值得单独设计。第一个是地域标签。我在商品表加了origin_place字段，存“XX省XX市XX镇”，列表页根据地域做筛选，让用户一眼看到产地信息。第二个是溯源信息。这个不一定要单独建表，可以在宣传文章里绑定商品，用户从文章页跳过来时已经把信任感建立了；更严谨的做法是建trace表，记录农产品的种植/采摘/检测记录，但第一期我建议用宣传文章承载，成本低、效果好。
第三个是活动公告。乡镇项目经常会配合农事季节做活动，比如“王家村黄桃预售”“王家村蓝莓采摘节”，这些信息用一个notice表存储，首页公告栏轮播。注意公告要冗余一个product_id关联字段，这样公告不只是信息展示，还能直接导流到商城。
3.3 订单状态流转与库存扣减方案
订单状态我设计了五档：待支付（0）、已支付/待发货（1）、已发货/待收货（2）、已完成（3）、已取消（4）。后端用状态机思想处理，不是写死状态直接 set，而是提供changeOrderStatus(orderNo, fromStatus, toStatus)方法做状态流转校验，避免用户并发操作导致状态错乱。
库存扣减是电商系统最核心的并发问题。我的方案是：下单时先查库存，如果库存大于购买数量，执行 UPDATEstock=stock- 购买数量 WHERE id = ? ANDstock>= 购买数量，靠数据库行锁保证不超卖。这个 SQL 影响行数为 0 就说明库存不足，直接回滚订单。实测下来在乡镇项目这个并发量级（每秒几十单以内），这个方案完全够用，完全没必要上 Redis 分布式锁或者消息队列。
4. 后端核心实现：从接口设计到业务闭环
4.1 接口规范：RESTful 风格与统一返回体
后端接口我全部采用 RESTful 风格，资源用名词复数表示，操作通过 HTTP 方法区分。列表页接口设计如下：
@RestController @RequestMapping("/api/product") public class ProductController { @GetMapping("/list") public Result list(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize, @RequestParam(required = false) Long categoryId, @RequestParam(required = false) String keyword, @RequestParam(required = false) String originPlace) { PageResult<ProductVO> page = productService.pageQuery(pageNum, pageSize, categoryId, keyword, originPlace); return Result.success(page); } @GetMapping("/{id}") public Result detail(@PathVariable Long id) { ProductVO vo = productService.getDetail(id); return Result.success(vo); } }统一返回体是前后端协作的基础，我封装了一个Result<T>，结构为：code（200 成功，500 失败，401 未登录）、message、data。前端 Axios 拦截器统一判断 code，不需要每个接口单独做错误处理。接口路径统一加/api前缀，方便 Nginx 做反向代理时直接转发，避免后端路径暴露。
4.2 商品与轮播图管理接口的实现细节
商品管理是管理员后台的核心模块。列表查询用 MyBatis-Plus 的分页插件，条件查询通过 LambdaQueryWrapper 拼装，不手动写 SQL。这里有个技巧：关键字搜索中文时，如果商品名称没建全文索引，用 LIKE 查询在数据量小的时候没问题，但要注意 SQL 注入——用 MyBatis 的#{keyword}而不是字符串拼接。
轮播图管理相对简单，就是 CRUD，但它有一个排序需求。我加了一个sort字段，查询时ORDER BY sort ASC，管理员在后台可以调整排序值。不要为排序功能单独开发拖拽组件，输入数字排序足够满足乡镇运营人员的操作习惯。
4.3 购物车与订单接口的事务处理
购物车逻辑：加入购物车时，如果该用户购物车中已有同一商品，则数量累加，否则新增一条记录。接口设计为POST /api/cart/add，传入 productId 和 quantity，后端自动判断。购物车列表返回时，需要关联商品表查出最新的价格和库存状态，避免用户看到购物车中的价格时已经涨价/下架。
订单生成是整个系统事务要求最高的地方。创建订单要同时做：生成订单主表记录、生成订单明细记录、扣减商品库存、清空购物车对应条目。这四步必须在一个事务里执行，任何一个失败都要回滚。实现上用@Transactional(rollbackFor = Exception.class)，并且注意事务边界——Transaction 注解要加在 Service 方法上，而不是 Controller 方法上，因为事务是基于 Spring AOP 的，只有经过代理对象调用的方法才会被拦截。
订单号生成我用了时间戳 + 用户ID + 随机数，简单可靠，不用单独建流水表：
String orderNo = System.currentTimeMillis() + "" + userId + "" + (int)((Math.random() * 9 + 1) * 100000);4.4 文件上传：农产品图片存储方案与容量规划
农产品宣传特别吃图片质量，所以图片上传是刚需。我的方案是：前端用 Element UI 的 Upload 组件上传到后端，后端保存到服务器本地磁盘的/upload/images/目录，然后返回访问 URL。配合 Nginx 配置一个/upload/路径的静态映射，不用 SpringBoot 再输出图片流。
这里有几个坑要提醒。第一，SpringBoot 默认单次上传文件大小限制是 1MB，必须显式配置。第二，文件名不能直接用用户上传的原始名字，要重新生成 UUID 文件名，避免中文乱码和路径穿越攻击。第三，图片目录的读写权限要确认，Windows 部署和 Linux 部署的路径分隔符不一致，建议在配置文件中用变量指定上传根路径，代码里拼路径用Paths.get()而不是手动拼字符串。
spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB file: upload-dir: /data/web/upload access-prefix: /upload/**4.5 权限控制：JWT拦截器与角色鉴权
用户登录后签发 JWT Token，前端存到 localStorage，每次请求通过请求头Authorization: Bearer <token>带上。后端用一个拦截器AuthInterceptor统一解析 Token，解析成功就把 userId 放到 ThreadLocal 或 Request attribute 中，失败则返回 401。
管理端接口需要额外校验角色。我的做法是：在 Controller 方法上打一个@RequireAdmin注解，拦截器里如果发现该接口需要管理员权限，就检查用户 role 是否为 1，否则拒绝。注意拦截器配置要排除/api/user/login、/api/product/list、/api/article/list等公开接口，否则用户还没登录就访问不了商品列表，产品直接没法用。
安全上还有一个细节容易忽略：改了密码后要让旧 Token 失效。JWT 是无状态的，一旦签发无法撤销。简单方案是在用户表加一个pwd_update_time字段，签发 Token 时把时间戳放进去，拦截器校验时对比用户表的更新时间，不一致就拒绝。这个方案实现成本低，能覆盖掉大部分“修改密码后旧 token 仍有效”的问题。
5. 前端实现：Vue页面如何撑起宣传与商城双场景
5.1 项目初始化与目录结构设计
前端我用的 Vue CLI 创建的项目，选了 Vue 2.7 + Element UI。有人问为什么不直接用 Vue 3 + Element Plus，答案还是稳字当先：Vue 2 的生态和教程最多，Element UI 组件库和 Vue 2 配合最稳定，遇到问题随便一搜就有答案。如果你是新项目并且团队成员比较熟悉 Composition API，那 Vue 3 + Element Plus 完全没问题，但我这里分享的是我实际用的稳定方案。
目录结构：
src/ ├── api/ # 接口请求封装 │ ├── product.js │ ├── cart.js │ ├── order.js │ ├── user.js │ └── request.js ├── assets/ ├── components/ # 公共组件 │ ├── ProductCard.vue │ └── Pagination.vue ├── router/ # 路由配置 │ └── index.js ├── store/ # Vuex 状态 │ ├── index.js │ └── modules/ │ └── cart.js ├── views/ # 页面 │ ├── home/ │ ├── product/ │ ├── cart/ │ ├── order/ │ ├── user/ │ └── admin/ ├── App.vue └── main.jsapi/request.js是对 Axios 的二次封装，统一设置baseURL、请求头携带 Token、响应拦截器处理错误码。这一步强烈建议做，不然每个页面里都写一遍axios.get加headers，代码会非常丑陋。
5.2 路由设计：首页宣传、商品列表、购物车、个人中心
路由设计直接决定了用户体验。我的路由配置：
| 路径 | 组件 | 说明 |
|---|---|---|
/ | Home.vue | 首页，包含轮播图、乡镇风采、热销商品 |
/article/:id | ArticleDetail.vue | 宣传文章详情页 |
/product/list | ProductList.vue | 商品列表页，支持分类/关键词/产地筛选 |
/product/:id | ProductDetail.vue | 商品详情页 |
/cart | Cart.vue | 购物车 |
/order/confirm | OrderConfirm.vue | 确认订单页 |
/order/list | OrderList.vue | 订单列表 |
/login | Login.vue | 登录 |
/admin | AdminLayout.vue | 管理后台布局 |
/admin/product | AdminProduct.vue | 商品管理 |
/admin/order | AdminOrder.vue | 订单管理 |
/admin/article | AdminArticle.vue | 宣传文章管理 |
使用 Vue Router 的懒加载，component: () => import('./views/xxx.vue')，首屏只加载当前页面的 JS，否则打包出来的 chunk 会非常大，乡镇网络环境下加载体验很差。
5.3 商品展示组件与响应式适配
商品卡片是所有页面都会用到的组件，我抽成了ProductCard.vue。样式上用 flex wrap 布局，图片在容器里等比例裁剪，价格高亮显示。这里有一个被很多人忽略的细节：商品图片的alt属性和懒加载。
农产品图片往往比较大，一次性加载几十张图体验很差，我用v-lazy指令做图片懒加载，滚动到视口附近才加载，效果立竿见影。同时商品卡片上展示销量和产地标签，这是农产品不同于标准品的信任要素。
商品详情页我把“宣传”融进去了：详情顶部是商品主图轮播，下面跟“产地故事”模块，展示宣传文章摘要，点击可跳转到完整文章。这个交互设计让宣传和商城不是两个孤岛，而是互相导流。
5.4 购物车与结算流程的状态管理
购物车的选中状态、数量变化、总价计算用 Vuex 管理。这里我踩过一个坑：购物车数据后端存一份，前端也存一份，导致两边不一致。后来想明白，前端 Vuex 里的购物车只是“当前用户看到的购物车”，真正的数据源在后端。前端初始化时从接口拉取购物车列表，在用户勾选/改数量时调用后端接口更新，然后同步更新 Vuex 状态。不要做“前端算完总价后端再算一遍”的双轨制，统一以后端接口返回的金额为准。
结算流程是：购物车页 → 点击结算 → 确认订单页（选择地址、核对商品、显示优惠）→ 提交下单 → 后端生成订单返回订单号 → 跳转到支付页面（模拟支付）。我没接真实支付网关，因为在开发和 demo 阶段，接微信支付/支付宝需要商户号，审批周期长。我用一个/api/pay/mock接口模拟支付成功，正式上线时替换成真实支付 SDK。
5.5 前后端联调：跨域处理与API封装
前后端分离第一步就遇到跨域。开发环境下 Vue 跑在localhost:8080，SpringBoot 跑在localhost:8081，直接 Ajax 请求肯定被 CORS 拦截。我的做法是前端的vue.config.js里配置 devServer 代理：
module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } }这样开发环境前端请求/api/product/list，就会被代理转发到后端 8081 端口，浏览器感知不到跨域。生产环境部署时用 Nginx 做反向代理，前端静态文件监听 80/443 端口，/api路径转发到后端服务。我没有在后端开启 CORS 全局配置，而是靠 Nginx 和 devServer 解决跨域，因为后端开启 CORS 等于对所有来源开放，安全性差一些。
6. 部署上线与实测中踩过的坑
6.1 打包与部署：Vue构建产物交给SpringBoot还是分开部署
前端构建后生成dist目录，里面是纯静态文件。有两种部署方式：一是把dist目录丢到 SpringBoot 的resources/static下，重新打包成一个 jar，一键启动；二是把dist丢到 Nginx 的 html 目录，SpringBoot 只提供接口。
我最终选了第二种，原因很直接：静态资源和接口服务的升级互不干扰。前端页面改了只需要重新拷贝dist到 Nginx 并刷新缓存，后端改了只需要重启 jar。如果合在一个包，每次前端编译产物变化都要重新打整个 jar，而且 Nginx 还可以做静态资源缓存和 gzip 压缩，页面加载速度有明显提升。
Nginx 核心配置：
server { listen 80; server_name your-domain.com; location / { root /data/web/dist; index index.html; try_files $uri $uri/ /index.html; # Vue Router history 模式必须 } location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /upload/ { alias /data/web/upload/; } }try_files $uri $uri/ /index.html这行是 Vue Router 用 history 模式的关键，不然刷新/product/1这种二级页面时，Nginx 会直接返回 404。
6.2 数据库连接池与慢查询优化
上线之后发现一个性能问题：首页加载时，同时请求轮播图、热销商品、公告、推荐文章，四个接口每个都新建数据库连接，Servlet 线程一多，数据库连接数直接被打满。排查后确认是没有合理配置 HikariCP 连接池。
SpringBoot 默认内置 HikariCP，但配置项需要根据机器性能调整。最终配置：
spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000同时我给高频查询字段加了索引。商品表的category_id、status、is_hot，订单表的user_id、status，文章表的status都建了单列索引。商品列表页的排序字段create_time我也建了索引，避免大数据量下排序走全表扫描。实测前后，首页接口从平均 230ms 降到了 80ms 左右，效果明显。
6.3 上线前的安全检查：接口越权、SQL注入、文件上传校验
自己做的项目容易忽视安全，但上线前我专门过了一遍常见的入侵路径。
第一是越权问题。典型的例子：用户 A 访问/api/order/detail/10086，如果后端只查订单 ID 而没校验订单属于谁，就能看到别人的订单信息和地址。我的统一处理是：所有涉及用户数据的查询，Service 层第一个参数都传当前登录用户 id，SQL 条件里强制带上user_id = ?，多一层过滤。
第二是SQL 注入。我项目里用的全是 MyBatis-Plus 的 LambdaQueryWrapper 和 MyBatis 的#{}占位符，天然防注入。唯一要注意的是排序字段——如果前端传sortField让后端拼接 ORDER BY，这里最容易出现注入。我做了白名单校验，只允许create_time、price、stock这几个固定字段，用循环判断而不是直接拼接。
第三是文件上传校验。接收上传文件时不能只判断文件不为空，还要校验扩展名和 MIME 类型。我只允许jpg、png、jpeg、gif、webp这几种图片格式，同时做了文件大小限制和图片重命名。注意不能信任前端传的 contentType，要通过ImageIO.read()实际读取图片内容判断它是不是真的图片，防止上传带恶意脚本的文件伪装成图片。
6.4 上线后的日志监控与数据备份策略
系统上线后，日志和备份是要提前规划的。SpringBoot 默认只输出到控制台，重启后日志就没了。我在logback-spring.xml里配置了按天滚动的文件日志，保留 30 天。日志里不打用户的明文密码、Token 等敏感信息，只打订单号、用户 ID 等业务标记。
数据库备份我用了最简单的方案：Linux 服务器上配置 cron 定时任务，每天凌晨用mysqldump全量导出 SQL 文件，保留最近 7 天，再定期手动拷贝到异地存储。数据量不大，全量备份就够用，不需要做增量。这个方案土但可靠，即使服务挂了，也能从最新备份恢复数据。
0 2 * * * mysqldump -u username -p'password' village_mall > /data/backup/village_mall_$(date +\%Y\%m\%d).sql && find /data/backup -name '*.sql' -mtime +7 -delete7. 功能测试与真实使用中的细节打磨
7.1 用Postman做的接口回归测试清单
功能开发结束后，不能只靠前端点几下就认为没问题。我建了一份 Postman 接口测试集合，覆盖所有业务接口的正向和异常场景。重点测试项包括：
- 商品列表：无参数、分类筛选、关键词搜索、分页越界
- 购物车：添加新商品、添加重复商品、添加库存不足商品、未登录添加
- 订单：正常下单、库存不足下单、重复提交下单
- 管理员接口：未登录访问、普通用户访问、管理员访问
- 文件上传：非图片类型、超大图片、空文件
每轮后端改动后，我会先跑一遍 Postman 集合，确认没有破坏旧接口。这个习惯帮我抓住了不少问题，比如改了商品详情接口返回结构之后，没有同步更新前台，导致前端拿不到productImage字段，直接被前端同事找上门。
7.2 真实使用中的体验优化：图片压缩、骨架屏、地址回填
系统给乡镇运营人员用之后，收集到几个很真实的反馈。第一个是“上传图片太卡”。乡镇运营传一张手机实拍的照片动辄 5-8MB，网速又一般，传到一半就失败。我在前端加了图片压缩：使用 Canvas 把图片宽度限制到 1500px、质量调到 0.7 再上传，大小直接降到 300-500KB，上传速度明显改善。
第二个是“页面加载白屏时间长”。首屏优化我做了几件事：Vue Router 懒加载、Element UI 按需引入、首页图片懒加载、静态资源开启 gzip。对于农产品图片，我甚至可以先显示一张轻量缩略图作为占位，等大图加载完成再替换。
第三个是“填地址太麻烦”。乡镇用户很多是帮家里长辈代买，收货地址可能是村组级别的详细地址。我在地址表单里用了省市区三级联动组件，但“县/乡/村”这级数据省市区下拉组件覆盖不到，还是需要手填详细地址。最终我保留了详细地址输入框并加了“常用地址”保存功能，二段输入逻辑，实测用户反馈比默认组件好用。
7.3 扩展方向：小程序端、数据统计与营销工具
系统上线跑稳定后，可以往三个方向扩展。小程序端是目前最值得做的，微信小程序的用户触达比网页端强得多，后端接口如果从一开始就设计成 RESTful 风格，小程序端可以直接复用。数据统计方面可以加一个简单的运营看板，统计每日订单量、销售额、热门商品 Top10，让乡镇运营者能直观看到哪些农产品卖得好，指导来年的种植计划。营销工具方面可以做预售和拼团，预售对农产品特别适用——采摘前就先收订单，按需采摘，减少损耗。
不过不管是哪个方向，核心还是先把眼前的宣传 + 商城闭环跑稳。我的体会是，乡镇项目不需要花哨的技术，真正重要的是把每个环节做扎实：图片加载快一点、下单流程顺一点、后台维护简单一点，用户和运营人员都愿意用，系统才真正有了价值。
最后再分享一个小技巧：开发这类系统时，让乡镇运营人员参与测试很重要。我项目开发完让一个乡镇的工作人员试用，她把“轮播图”理解成“宣传照片滚动的地方”，把“SKU”理解成“不同斤数”，这些真实的反馈直接推动了界面文案的简化。技术实现到位是基础，但产品能不能在乡镇用起来，很多时候是这些细节决定的。
)
