乡镇农产品电商这两年被提得很多但真正落到乡镇实地会发现需求和城市电商完全不同。农产品不是标准品宣传和销售必须绑定在一起——光有商城没有产地故事用户不信任光有宣传页没有下单入口流量就白费了。这个基于 SpringBoot Vue 的农产品宣传与商城一体化系统想解决的就是这件事把乡镇风土人情、农产品溯源信息做成宣传内容同时把商品浏览、购物车、下单支付跑通形成从“看到”到“买到”的闭环。适合正在做毕业设计、接乡镇信息化项目、或者想从零搭一个前后端分离电商 demo 的开发者参考。我自己的项目也是在这个思路下逐步完善的下面把设计过程和踩坑记录都摊开讲。1. 乡镇农产品触网这个系统到底解决了什么问题1.1 乡镇农产品电商的痛点与需求拆解乡镇农产品做线上销售最难受的不是“没有货”而是“没人信”。城里消费者打开一个商城看到照片精美的水果、大米、土鸡蛋第一反应往往是这图是不是盗的这货发出来还能新鲜吗这个乡镇到底在哪所以在真实项目里宣传模块和商城模块是同等重要的甚至宣传要先于商城。系统里必须有乡镇介绍、产地实拍、农户故事、种植/养殖过程的图文记录让用户先建立信任再点击“加入购物车”。这个需求拆下来大概分四个角色管理员维护商品、分类、轮播图和宣传内容农户/商家在后台发布农产品、管理库存普通用户浏览宣传页、下单选地址游客只看不买。这里面“宣传内容管理”是很多通用电商系统忽略的却是乡镇项目的灵魂。我把宣传模块落成了独立的文章/图集管理支持富文本编辑和图片上传字段包括标题、封面、正文、关联商品ID、发布时间。用户在宣传详情页看到某款农产品的故事点“去购买”直接跳到商品详情页这个转化路径比单纯摆商品列表自然得多。1.2 系统功能边界宣传站与商城如何一体化设计初期我犯过一个大方向错误想做一个“大而全”的平台包括资讯、视频、直播、拼团、分销……后来发现对于乡镇级别的运营体量来说功能太多反而是负担。最终明确的功能边界是宣传端乡镇风采、农产品故事、公告通知 商城端商品分类、商品列表、详情、购物车、订单、收货地址 管理端商品管理、宣传内容管理、订单处理、用户管理、轮播图配置。这里有一个关键判断砍掉哪些功能直播和视频是乡镇宣传的强需求但实现成本高而且对带宽和运维要求不低。我第一期选择用图片文字轮播图承载宣传预留了视频字段但没做视频上传和转码。如果要做可以走对象存储播放器方案但那是二期的事了。这个取舍很重要——很多项目死在“什么都要有”而不是死在“功能不够”。1.3 角色划分与使用流程系统分三个端口我自己用一张表把角色权限理清了角色登录端核心权限游客Web端浏览宣传页、查看商品列表、搜索普通用户Web端游客权限 下单、购物车、地址管理、订单查询管理员管理后台用户权限 商品/分类/订单/宣传内容/轮播图/公告管理用户主流程是访问首页 → 看到乡镇介绍或轮播图 → 进入宣传文章 → 跳转商品详情 → 加入购物车 → 结算下单 → 填写地址 → 订单生成。管理端主流程是登录 → 发布宣传内容/上架商品 → 处理用户订单 → 发货 → 完成。整个流程走下来项目结构基本稳定后续加功能都是在这些模块上扩展。2. SpringBoot Vue 前后端分离的技术底座选择2.1 为什么是SpringBoot而不是SSH/SSM如果放在五年前SSHSpring Struts Hibernate或者 SSMSpring 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.xJDK版本怎么定这个坑必须写一下。SpringBoot 3.x 发布之后很多教程直接推荐最新版但实际上 3.x 要求 JDK 17 起步而且部分第三方 starter 还没完全跟上尤其是某些老牌 mybatis-generator、代码生成工具。我做这个项目时用的 SpringBoot 2.7.x JDK 8理由很直接稳定、资料多、遇到问题网上随便搜就能解决。对于生产项目技术不在于新在于团队能否驾驭、生态是否成熟。如果非要上 SpringBoot 3.x你要确认本地 JDK 版本是不是 17MyBatis 或者 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)方法做状态流转校验避免用户并发操作导致状态错乱。库存扣减是电商系统最核心的并发问题。我的方案是下单时先查库存如果库存大于购买数量执行 UPDATEstockstock- 购买数量 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) { PageResultProductVO 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); } }统一返回体是前后端协作的基础我封装了一个ResultT结构为code200 成功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/:idArticleDetail.vue宣传文章详情页/product/listProductList.vue商品列表页支持分类/关键词/产地筛选/product/:idProductDetail.vue商品详情页/cartCart.vue购物车/order/confirmOrderConfirm.vue确认订单页/order/listOrderList.vue订单列表/loginLogin.vue登录/adminAdminLayout.vue管理后台布局/admin/productAdminProduct.vue商品管理/admin/orderAdminOrder.vue订单管理/admin/articleAdminArticle.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:8080SpringBoot 跑在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 层第一个参数都传当前登录用户 idSQL 条件里强制带上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 -ppassword 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”理解成“不同斤数”这些真实的反馈直接推动了界面文案的简化。技术实现到位是基础但产品能不能在乡镇用起来很多时候是这些细节决定的。
乡镇农产品电商这两年被提得很多但真正落到乡镇实地会发现需求和城市电商完全不同。农产品不是标准品宣传和销售必须绑定在一起——光有商城没有产地故事用户不信任光有宣传页没有下单入口流量就白费了。这个基于 SpringBoot Vue 的农产品宣传与商城一体化系统想解决的就是这件事把乡镇风土人情、农产品溯源信息做成宣传内容同时把商品浏览、购物车、下单支付跑通形成从“看到”到“买到”的闭环。适合正在做毕业设计、接乡镇信息化项目、或者想从零搭一个前后端分离电商 demo 的开发者参考。我自己的项目也是在这个思路下逐步完善的下面把设计过程和踩坑记录都摊开讲。1. 乡镇农产品触网这个系统到底解决了什么问题1.1 乡镇农产品电商的痛点与需求拆解乡镇农产品做线上销售最难受的不是“没有货”而是“没人信”。城里消费者打开一个商城看到照片精美的水果、大米、土鸡蛋第一反应往往是这图是不是盗的这货发出来还能新鲜吗这个乡镇到底在哪所以在真实项目里宣传模块和商城模块是同等重要的甚至宣传要先于商城。系统里必须有乡镇介绍、产地实拍、农户故事、种植/养殖过程的图文记录让用户先建立信任再点击“加入购物车”。这个需求拆下来大概分四个角色管理员维护商品、分类、轮播图和宣传内容农户/商家在后台发布农产品、管理库存普通用户浏览宣传页、下单选地址游客只看不买。这里面“宣传内容管理”是很多通用电商系统忽略的却是乡镇项目的灵魂。我把宣传模块落成了独立的文章/图集管理支持富文本编辑和图片上传字段包括标题、封面、正文、关联商品ID、发布时间。用户在宣传详情页看到某款农产品的故事点“去购买”直接跳到商品详情页这个转化路径比单纯摆商品列表自然得多。1.2 系统功能边界宣传站与商城如何一体化设计初期我犯过一个大方向错误想做一个“大而全”的平台包括资讯、视频、直播、拼团、分销……后来发现对于乡镇级别的运营体量来说功能太多反而是负担。最终明确的功能边界是宣传端乡镇风采、农产品故事、公告通知 商城端商品分类、商品列表、详情、购物车、订单、收货地址 管理端商品管理、宣传内容管理、订单处理、用户管理、轮播图配置。这里有一个关键判断砍掉哪些功能直播和视频是乡镇宣传的强需求但实现成本高而且对带宽和运维要求不低。我第一期选择用图片文字轮播图承载宣传预留了视频字段但没做视频上传和转码。如果要做可以走对象存储播放器方案但那是二期的事了。这个取舍很重要——很多项目死在“什么都要有”而不是死在“功能不够”。1.3 角色划分与使用流程系统分三个端口我自己用一张表把角色权限理清了角色登录端核心权限游客Web端浏览宣传页、查看商品列表、搜索普通用户Web端游客权限 下单、购物车、地址管理、订单查询管理员管理后台用户权限 商品/分类/订单/宣传内容/轮播图/公告管理用户主流程是访问首页 → 看到乡镇介绍或轮播图 → 进入宣传文章 → 跳转商品详情 → 加入购物车 → 结算下单 → 填写地址 → 订单生成。管理端主流程是登录 → 发布宣传内容/上架商品 → 处理用户订单 → 发货 → 完成。整个流程走下来项目结构基本稳定后续加功能都是在这些模块上扩展。2. SpringBoot Vue 前后端分离的技术底座选择2.1 为什么是SpringBoot而不是SSH/SSM如果放在五年前SSHSpring Struts Hibernate或者 SSMSpring 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.xJDK版本怎么定这个坑必须写一下。SpringBoot 3.x 发布之后很多教程直接推荐最新版但实际上 3.x 要求 JDK 17 起步而且部分第三方 starter 还没完全跟上尤其是某些老牌 mybatis-generator、代码生成工具。我做这个项目时用的 SpringBoot 2.7.x JDK 8理由很直接稳定、资料多、遇到问题网上随便搜就能解决。对于生产项目技术不在于新在于团队能否驾驭、生态是否成熟。如果非要上 SpringBoot 3.x你要确认本地 JDK 版本是不是 17MyBatis 或者 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)方法做状态流转校验避免用户并发操作导致状态错乱。库存扣减是电商系统最核心的并发问题。我的方案是下单时先查库存如果库存大于购买数量执行 UPDATEstockstock- 购买数量 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) { PageResultProductVO 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); } }统一返回体是前后端协作的基础我封装了一个ResultT结构为code200 成功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/:idArticleDetail.vue宣传文章详情页/product/listProductList.vue商品列表页支持分类/关键词/产地筛选/product/:idProductDetail.vue商品详情页/cartCart.vue购物车/order/confirmOrderConfirm.vue确认订单页/order/listOrderList.vue订单列表/loginLogin.vue登录/adminAdminLayout.vue管理后台布局/admin/productAdminProduct.vue商品管理/admin/orderAdminOrder.vue订单管理/admin/articleAdminArticle.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:8080SpringBoot 跑在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 层第一个参数都传当前登录用户 idSQL 条件里强制带上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 -ppassword 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”理解成“不同斤数”这些真实的反馈直接推动了界面文案的简化。技术实现到位是基础但产品能不能在乡镇用起来很多时候是这些细节决定的。
