企业官网建设流程全解析

年初的时候，一个做园艺贸易的朋友找到我，说要给他们的直营花店和批发渠道搭建一套线上管理系统。需求不算复杂，但特别零散——既要管商品、库存、订单，又要管会员积分、促销活动，还得给老板看销售报表。技术栈他们没指定，只说希望开发快、后期好维护。我结合团队现有能力和运维成本，最后定了SpringBoot+Vue这套前后端分离方案。就是这套“植物销售管理系统”，从需求梳理到正式上线用了大概三个月，中间踩了不少坑，也沉淀了不少经验。如果你也正准备做类似的进销存或垂直电商系统，这篇文章应该能帮你少走几周弯路。

1. 为什么我选了SpringBoot+Vue而不是别的技术组合

1.1 需求里藏着的“非典型电商”属性

朋友的需求一开始听起来就是标准电商那套：商品上架、购物车、下单支付、后台管理。但聊深了之后发现，植物品类有几个很特殊的点，直接影响技术选型。

第一，植物商品不是标准SKU。同一棵绿萝，可能按盆径、高度、是否带盆分好几种规格，而且每个规格的进货价、库存数量、养护方式都不一样。第二，植物有“状态”属性。上架、预售、售罄、下架这几种状态之外，还有“季节性下架”，比如冬天不适合发货的品种。第三，销售渠道多。有门店自提、同城配送、外地快递。这些不同的履约方式对订单流程的要求完全不同。

说白了，这不是做一个花里胡哨的商城前端，而是要支撑一套灵活的进销存+OMS（订单管理）系统。这种系统最忌讳的就是业务逻辑和页面强耦合。所以“前后端分离”几乎是必然的选择，而后端如果用传统的SpringMVC加JSP模板，前端页面改个样式都要重启服务，后期维护成本会很尴尬。

1.2 SpringBoot和Vue到底赢在哪里

当时我在备选列表里放了四套组合：

• SSM(JSP) + Bootstrap：老牌Java方案，但前后端耦合太深，模板渲染吃力。
• SpringBoot + Thymeleaf：适合服务端渲染，但做后台管理界面树形菜单、动态表单很费劲。
• SpringBoot + Vue（前后端分离）：后端只出接口，前端完全独立，自动化构建，调试方便。
• Node.js(NestJS) + React：技术新，但团队对Java生态更熟，且甲方希望后续能自己招Java人维护。

实测下来，SpringBoot+Vue有几个很实际的优势：

开发效率上，后端只写REST接口，前端用Vue的组件化开发，两个人并行开发互不阻塞。调试方面，后端用Swagger自动生成接口文档，前端直接用Mock数据联调，等后端接口写完后再替换baseURL，整个过程非常顺畅。部署上，后端是一个可执行jar，前端是一堆静态文件扔到Nginx，整个上线动作可以控制在五分钟内。

如果换成JSP那套，一个页面要前后端来回改，遇到复杂交互（比如动态加减商品规格、实时计算库存）就会很痛苦。这是我在以往的项目里反复体会过的。

1.3 版本选择：谁的坑少用谁

这里必须说一下版本踩坑经历。项目启动时是2023年上半年，SpringBoot 3.0已经发布了，但身边好几个朋友在升级过程中都遇到了javax到jakarta命名空间迁移的连锁问题，部分老依赖又不兼容。对于这种业务管理系统，稳定压倒一切。

最终定下的版本是：

这里特别想提醒一句：新项目如果团队对Vue3熟悉，可以直接Vue3 + Element Plus。但我们当时的团队成员多为传统Java开发，平时写前端不多，Vue2的选项式API和ElementUI的文档对他们更友好。技术没有绝对好坏，让团队在最短时间内能上手的才是好技术。

2. 植物品类独有的业务痛点：属性、库存与状态变更

2.1 商品属性要能“长出腿来”

普通电脑、手机这类商品，规格无非是颜色、版本、内存，字段固定。植物不同，你很难用一张统一的商品表把所有属性塞进去。比如龟背竹要记录“耐阴程度”，多肉要记录“浇水频率”，蝴蝶兰要记录“花期季节”，有些还要加“养护难度”这种指数。

直接把所有可能性做成字段，表结构会臃肿到没法维护。我的做法是拆分成三块。

第一块：基础商品表，存SKU编号、名称、分类、价格、主图、状态、创建时间等，这些是所有商品共用的。

第二块：规格表，也叫SKU扩展表。每个商品可能有多个规格，规格名称（盆径25/35/45）、对应的价格、库存条码都放这张表。

第三块：动态属性表。采用JSON数组形式，比如：

[{"attrName":"光照需求","attrValue":"散光"},{"attrName":"浇水频率","attrValue":"7天一次"},{"attrName":"适合场景","attrValue":"客厅"}]

这样无论品类多特别，后台配置时只要把这些键值对填好，前端详情页通过v-for循环渲染就行，完全不用改表结构。

这种设计给后续带来的好处是：商城首页可以基于属性标签做筛选，比如用户勾选“耐阴”“好养活”，系统就能直接检索属性字段，效果很不错。

2.2 批次库存解决进销存对账难题

植物销售和标准工业品不同，同一款商品可能这个月从A市基地进货，下个月从B市基地进货，进价不一样，损耗率也不一样。如果在商品表里只存一个总库存数，财务查毛利时会非常痛苦。

所以我单独建了一张库存批次表，每次采购入库时生成一个批次，记录供应商、采购价、入库数量、已售数量、批次状态。当用户下单时，实际扣减的是某个批次的库存。查询商品可售库存时，把所有“已审核”批次的剩余量相加。

这里要注意一个业务细节：如果发货时指定了某个批次，那订单明细里最好也记录批次ID。不然售后或者退货时，你不知道该把库存回补到哪个批次上。我一开始忽略了这一点，后来财务要对账时才补上了关联字段。

2.3 订单状态机：避免“状态遍地开花”

植物订单的流程里有几个特殊节点：同城配送需要“拣货完成”才能进入配送，快递发货要生成物流单号；如果客户收到植物后养死了，还有售后补发流程。因此订单状态不能只用“待支付/待发货/待收货/已完成”这四态硬套。

我设计了如下状态流转：

状态迁移不是随便改个数值就行，每次变更都要记录日志。我建了一张订单状态变更表，把操作人、操作时间、旧状态、新状态、备注都存起来。这样一旦出现“订单明明已支付却显示待支付”的纠纷，可以直接翻日志定位是哪一步出了问题。实际运行中这条日志表帮了大忙，至少有三次排查问题都是靠它还原现场的。

3. 数据库设计：几张关键表的建表逻辑和索引策略

3.1 核心表的DDL思路

数据库设计这件事，方法其实很朴素：一个业务实体一张表，一对多关系加外键或关联表。这里给出几张核心表的精简结构，你可以直接参考。

商品表plant_product：

CREATE TABLE `plant_product` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `product_code` varchar(32) NOT NULL COMMENT '商品编码', `product_name` varchar(128) NOT NULL COMMENT '商品名称', `category_id` bigint(20) NOT NULL COMMENT '分类id', `main_image` varchar(255) DEFAULT NULL COMMENT '主图地址', `price` decimal(10,2) NOT NULL COMMENT '默认售价', `status` tinyint(4) NOT NULL DEFAULT 1 COMMENT '1上架 0下架 2售罄', `is_delete` tinyint(4) NOT NULL DEFAULT 0, `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `idx_product_code` (`product_code`), KEY `idx_category_id` (`category_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='植物商品表';

订单表plant_order：

CREATE TABLE `plant_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单号，业务规则生成', `user_id` bigint(20) NOT NULL, `total_amount` decimal(10,2) NOT NULL COMMENT '订单总额', `pay_amount` decimal(10,2) NOT NULL COMMENT '实付金额', `freight_amount` decimal(10,2) NOT NULL DEFAULT 0, `status` tinyint(4) NOT NULL DEFAULT 0, `address_snapshot` varchar(512) DEFAULT NULL COMMENT '收货地址快照，JSON', `pay_time` datetime DEFAULT NULL, `send_time` datetime DEFAULT NULL, `finish_time` datetime DEFAULT NULL, `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `idx_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_status_create` (`status`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';

订单明细表plant_order_item，存商品快照：

CREATE TABLE `plant_order_item` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_id` bigint(20) NOT NULL, `product_id` bigint(20) NOT NULL, `sku_id` bigint(20) NOT NULL, `product_name_snapshot` varchar(128) NOT NULL COMMENT '商品名称快照', `product_image_snapshot` varchar(255) DEFAULT NULL, `price_snapshot` decimal(10,2) NOT NULL, `quantity` int(11) NOT NULL, `batch_id` bigint(20) DEFAULT NULL COMMENT '库存批次id', PRIMARY KEY (`id`), KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细';

3.2 订单快照为什么必须做

第一次做电商系统时，我并没有做快照，订单明细直接关联商品表的实时数据。后来遇到一个情况：某个商品被管理员误删了，数据库里关联不到商品信息，历史订单后台一直报错。

从那以后，所有订单相关页面都不能直接依赖商品主表。商品名称、图片、销售价格、规格描述在下单那一刻就复制一份到订单明细里。哪怕以后商品改名、下架、清空数据库，历史订单依然能完整呈现用户当时购买的内容。

这个设计对于植物销售尤其重要。植物的市场价格波动大，可能同一个品种春夏季是一个价，秋冬季又是另一个价。如果没有快照，三个月前的订单价格显示会对不上账。

3.3 库存扣减的并发安全：用版本号防超卖

高并发场景不是这套系统的重点，但促销活动时也可能发生几十个用户同时抢限量绿植的情况。最初我的扣库存写法是：

UPDATE plant_stock SET stock = stock - 1 WHERE product_id = ?

这条SQL在高并发下存在严重超卖风险。两个事务同时读到stock=1，而后各自减1，最终导致库存变成负数而不自知。

我的解决方案是引入乐观锁，给库存表加一个version字段：

// 每次扣减时带上版本号 boolean success = this.update( new LambdaUpdateWrapper<PlantStock>() .eq(PlantStock::getSkuId, skuId) .eq(PlantStock::getVersion, stock.getVersion()) .setSql("stock = stock - {0}", quantity) .set(PlantStock::getVersion, stock.getVersion() + 1) ); if (!success) { throw new BizException("库存不足或已更新，请重试"); }

这样如果同一时间有两个请求读到相同版本号，第一个更新成功后，第二个的version匹配不到任何行，就会更新失败并提示用户重新尝试。对于这个体量的系统，用它比引入Redis分布式锁更简单，也足够可靠。

4. 后端实战：SpringBoot接口设计里的几个关键取舍

4.1 统一返回体和全局异常处理的“坑”与“解”

接口返回格式，我从第一天就统一成：

{ "code": 0, "msg": "success", "data": {} }

这里有个小经验：code为0表示成功，其他为失败，另外单独用HTTP状态码表示网络层错误。这样做是为了让前端代码简单，response拦截器里只需要判断body.code即可，不需要每次try-catch。

全局异常处理用@RestControllerAdvice，但要记得分类：业务异常、参数校验异常、未知异常。尤其要注意，不要所有异常都直接给前端堆栈信息，隐藏掉Server Internal Error的具体细节，但要把完整日志打印到本地文件里。我之前遇到过把数据库连接串泄露到异常消息里的情况，相当危险。

4.2 文件上传：选了半天，先用本地磁盘

植物商品需要多角度图片，有个需求是富文本编辑里还要上传种植说明图。文件上传是绕不开的。当时对比了FastDFS、OSS、MinIO和本地磁盘存储。

考虑到部署环境是单台服务器，图片量每天几十张，最终用了最直接的本地磁盘+映射URL方式。在后端配置类里加一个虚拟路径映射：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath = fileProperties.getUploadPath(); if (!uploadPath.endsWith("/")) { uploadPath += "/"; } registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath); }

同时上传图片时用UUID重命名，避免中文文件名和重名问题。我还会等比例压缩超过1MB的图片，减少带宽占用。如果后期量级上来，可以平滑切换到MinIO或OSS，因为上传接口只在Controller层做适配，存储路径改动不影响业务逻辑。

4.3 订单超时未支付自动关闭：定时任务版

用户下单后15分钟未支付，系统要自动取消订单并回补库存。这个功能实现方案不少，可以用延迟消息队列，也可以用Redisson延迟队列，但都引入了额外组件。我这里选择了Spring的@Scheduled扫描表，每分钟执行一次，把“超过15分钟未支付”的订单状态改为“已取消”，同时恢复库存。

代码大致是这样：

@Scheduled(cron = "0 * * * * ?") @Transactional(rollbackFor = Exception.class) public void closeExpiredOrders() { List<PlantOrder> expiredOrders = orderMapper.selectList( new LambdaQueryWrapper<PlantOrder>() .eq(PlantOrder::getStatus, 0) .le(PlantOrder::getCreateTime, LocalDateTime.now().minusMinutes(15)) .last("limit 200")); for (PlantOrder order : expiredOrders) { order.setStatus(6); orderMapper.updateById(order); // 回补库存 stockService.restoreStock(order.getOrderNo()); } }

注意，不要让定时任务一次处理太多数据，limit 200是防止堆积后占满事务时间。另外，多实例部署时一定要加分布式锁（比如ShedLock），否则两台机器会同时跑同一条订单，导致重复回补库存。当年我把项目部署在两台服务器上，忘了给定时任务加锁，结果线上出现了三单重复回补库存的问题，排查了好久才定位到。

4.4 JWT鉴权：用拦截器而不是Security全家桶

许多教程推荐Spring Security + JWT，但对这种内部管理系统来说，Security的过滤器链配置复杂，学习维护成本高。我选择了更直接的方式：写一个HandlerInterceptor，在preHandle方法里解析请求头中的token，校验签名和有效期，然后查询Redis确认token未注销，再把用户信息写入ThreadLocal供业务代码使用。

角色权限上，采用注解+AOP的方式。自定义一个@RequirePermission注解，标注在需要特定权限的Controller方法上，AOP切面里判断当前用户是否有这个权限，没有就抛异常。

这样做最大的好处是逻辑直观，团队成员接手时很快能理解。如果以后需要接入OAuth2或更复杂的认证体系，可以再引入Spring Security，但当前阶段够用就好。

5. 前端Vue实战：后台管理系统从零搭建的思路

5.1 目录结构、路由与状态管理的“规范化”

前端部分，我习惯这样组织目录：

src/ ├── api/ // 按模块拆分的接口调用 ├── assets/ // 静态资源 ├── components/ // 通用组件 ├── layout/ // 后台整体布局（侧边栏、头部、面包屑） ├── router/ // 路由表 ├── store/ // Vuex状态 ├── utils/ // axios封装、公共方法 └── views/ // 页面级组件

路由这里要特别讲一个坑：后台管理界面的侧边栏菜单和路由表有依赖关系。如果前端直接写死一份静态路由表，后台增加新菜单就要重新打包发版，很不合适。我最后把菜单和权限绑定，从后端动态返回用户可访问的菜单列表，前端用router.addRoutes动态挂载路由，这样管理员不需要动前端代码就能配置不同角色的可见菜单。

5.2 商品表单里的动态属性组件

因为前面提到植物属性是动态的，所以商品编辑页面必须是动态表单。我用ElementUI的el-form配合v-for渲染属性数组：

<div v-for="(attr, index) in form.attrs" :key="index"> <el-input v-model="attr.attrName" placeholder="属性名" style="width: 150px" /> <el-input v-model="attr.attrValue" placeholder="属性值" style="width: 200px" /> <el-button @click="removeAttr(index)">删除</el-button> </div> <el-button @click="addAttr">添加属性</el-button>

在提交前要注意校验：属性名不能为空、属性名不能重复、属性值不能包含HTML标签（防止XSS）。这个动态表单在管理后台里用得非常频繁，如果前期用静态表单项，后面加属性就要改前端代码，那会非常痛苦。

5.3 数据可视化：让老板一眼看到销售情况

老板看后台，最关心的是“卖得怎么样”“哪些植物好卖”“哪些积压了”。我用ECharts做了三个页面：

第一个是销售趋势折线图，展示近30天订单金额和订单数量双轴曲线。第二个是分类占比饼图，按植物大类（观叶、观花、多肉、盆景）汇总销售占比。第三个是滞销品表格，列出连续30天库存周转率为0的商品。

这里有个数据接口设计的细节：趋势图和饼图的数据，不需要每次从订单明细里去实时聚合，那会很慢。我建了一张每日销售汇总表，每天凌晨用定时任务统计昨天的数据并写入。ECharts查询这张汇总表，一秒内就能返回结果。这种用空间换时间的思路，在后台报表里很实用。

5.4 axios封装与接口联调中的跨域问题

联调时最烦的就是浏览器控制台一片红。跨域问题我在后端做了全局CORS配置，开发环境允许来自localhost的请求，生产环境只允许Nginx域名。

axios封装上，我统一做了请求拦截器（自动带token）和响应拦截器（统一处理code，当code为401时跳转登录页，当code为业务错误时Message.error展示msg）。这里有个细节：后端返回201时，前端也要读data，而不是只读response.status，否则容易漏掉正确数据。

还要提一个防重复提交的优化：所有提交按钮在点击后loading置为true，并且在axios的请求拦截器中用pendingMap记录请求地址，如果同一个地址在上一个请求未完成时又被发起，直接丢弃新请求。这样虽然后台系统并发不高，但遇到网络慢时用户狂点按钮也不会产生重复订单。

6. 从开发机到上线环境：部署、备份和线上问题排查

6.1 Nginx反向代理和前端路由刷新404的处理

后端打包为jar包后，部署命令很简单：

nohup java -jar plant-system.jar --spring.profiles.active=prod > app.log 2>&1 &

前端执行npm run build生成dist，然后放到Nginx的html目录下。关键配置在于把接口请求反向代理到本机8080端口：

server { listen 80; server_name plant.example.com; root /opt/plant/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 解决前端history路由刷新404 location / { try_files $uri $uri/ /index.html; } # 图片上传目录 location /upload/ { alias /data/plant-upload/; } }

如果没有try_files这行，刷新某个子页面时会出现404，因为Nginx在磁盘找不到对应的静态文件路径。这是几乎所有前后端分离项目都会遇到的坑，配置好就稳了。

6.2 数据库备份：一天都不能断

系统的核心资产是订单和库存数据。我写过一个备份脚本：

#!/bin/bash BACKUP_DIR=/data/backup/mysql DATE=$(date +%Y%m%d%H%M) mysqldump -uroot -p*** plant_system > $BACKUP_DIR/plant_$DATE.sql find $BACKUP_DIR -type f -name "*.sql" -mtime +7 -delete

用crontab每天凌晨执行一次。注意mysqldump命令放在脚本里时不要直接暴露密码到命令行，可以用配置文件写[mysqldump]段。这个脚本虽然简单，但好几次系统出问题时都靠它恢复了数据，属于“平时不起眼，关键时救命”的东西。

6.3 线上问题实录：三起典型的性能故障

系统上线第二周，后台商品列表打开要卡五六秒。排查后发现列表查询用了多表关联再排序，而且没有用覆盖索引。优化方案很简单，先查主键，再回表取详情：

SELECT p.* FROM plant_product p INNER JOIN (SELECT id FROM plant_product WHERE is_delete=0 AND category_id=? ORDER BY update_time DESC LIMIT 0,20) t ON p.id=t.id;

查询速度直接降到200毫秒以内。

另一次是高峰期MySQL连接数飙满，原因是某接口在循环里反复查询数据库，连接不释放。我用Druid监控一看，一个请求最多开了几十次连接。这是典型的N+1问题，用MyBatis-Plus的batch查询一次性把关联数据查出，再在内存中组装，问题就解决了。

第三次是文件上传大图时前端等待时间过长。原因是图片没有压缩，原图可能十几MB。后来在后端使用Thumbnailator对图片进行压缩，超过800KB一律等比缩到800px宽再保存，上传耗时从十几秒降到了一两秒。

6.4 给管理员的权限管控建议

系统里有一个风险点：普通管理员如果拥有商品编辑权限，同时也有订单查看权限，那他会不会用商品改价功能去操作订单金额？为降低内部风险，我把角色权限细分到按钮级别。比如“商品编辑”和“订单改价”是两个完全独立的权限点，只有财务主管才被授予订单改价权限。

前端根据权限码控制按钮显隐，后端在接口方法上用@RequirePermission("order:price:edit")做二次校验。不要只做前端隐藏，那样别人直接调用后端接口就绕过了。这是我反复强调的一件事：权限控制的核心在后端，前端只是体验优化。

7. 做完整套系统后，我留下的几个总结性经验

当然，如果非要收个尾，我想说几个细节习惯，它们在这次项目里让我省了很多事。

一是接口文档从第一天就用Swagger生成，并且要求所有字段必须写注释。因为前端和后端不是一个人写，接口字段命名不统一的话，联调会浪费大量时间。二是所有列表查询必须做分页，哪怕现在数据量只有几百条。三是日志里不要记录用户身份证、手机号这类敏感信息，一旦日志文件泄露就是安全事故。

最后分享一个小技巧：生产环境的数据库密码不要明文写在application-prod.yml里。我用了jasypt加解密组件，配置文件里只有一串密文，启动时通过环境变量传入解密密钥。这样即使代码仓库泄露，别人也拿不到真正的密码。

这套植物销售管理系统，严格来说不算高并发、高流量的复杂项目，但它把业务需求、技术选型、工程设计、上线运维从头到尾串了一遍。做完之后，我对全栈系统的理解深了不少，也踩过不少“看起来没问题，实际运行才炸”的坑。如果你也在规划这类管理系统，希望这篇文章能成为你的避坑地图。