做鲜花电商这个项目之前我其实有点轻视它——市面上商城类的开源项目一抓一大把换个商品类目而已能玩出什么花真正把需求理完、把代码写起来之后我才发现自己错得离谱。鲜花的商品属性跟数码、服饰、图书完全是两套逻辑库存有时效配送有温度要求用户买的不是一件商品而是一种情绪。这些业务上的特殊性会直接逼着你把SpringBoot后端、Vue前端、AI大模型能力重新做一轮针对性设计。这篇文章把整个「在线鲜花电商平台系统」的从0到1全过程拆开讲覆盖业务建模、技术选型、数据库设计、订单状态机、AI大模型集成、四项创新扩展功能以及我在开发过程中踩过的坑。适合正在做SpringBootVue毕业设计的同学、想转型电商开发方向的从业者以及想了解AI大模型怎么跟业务系统真实结合的团队参考。整个项目技术栈围绕标题里的三个关键词展开SpringBoot负责后端服务与AI接入Vue负责用户端与商家端界面AI大模型则嵌进货架推荐、花语助理、库存预警和质检四个具体场景里。1. 为什么鲜花电商和普通商城项目根本不是一回事1.1 鲜花SKU的“时令性损耗”直接改变库存设计普通电商的商品可以屯在仓库里慢慢卖一件羽绒服放三年不会坏。鲜花不行。切花从花田采下来之后寿命以天计算玫瑰通常7天左右百合5到7天绣球和郁金香更短有时3天就开始打蔫。这就带来一个普通商城完全不需要考虑的问题库存不仅仅是“有没有”的数字还是一个“还剩多久会报废”的倒计时。这个特性直接决定了几个后端设计决策。第一库存表不能只存总数还要记录每一批花材的入库时间和预计失效日期第二前端商品列表需要根据剩余生命周期动态打标比如“今日空运到店”和“花期还剩2天特价处理”其实是同一种商品在不同时间点的两种展示第三下单时的锁库存策略要支持批次优先——系统先扣寿命最短的那批货把新鲜货留到后面卖。这个“近效期优先”的库存策略我把它实现成了SpringBoot里一个独立的StockAllocator组件它接收花材SKU和数量返回具体扣哪些批次这样订单模块和库存模块的职责就分清楚了。1.2 配送时效为什么是鲜花电商的命门鲜花的典型消费场景是当天送生日订一束、纪念日订一束、约会前订一束。用户从下单到收货心理预期是按小时算的不是按天。所以这个系统的配送模块不能沿用普通电商的“下单后48小时发货”逻辑而要拆成两类同城即时配送接单后2到3小时内送达和预约配送指定未来某天某个时段送达。在代码层面我做的第一件事是给订单表增加了两个关键字段期望送达时间段和配送类型。预约单在用户下单那一刻不会立刻推送给门店而是进入一个延迟队列在送达时间前2小时自动触发“备货配送”流程。同城单则直接进入门店工作台的待处理列表。这套机制看起来不复杂但它决定了整个订单状态的流转节奏也是后面AI助手的配送类知识库必须覆盖清楚的内容。1.3 用户买的不是花是“被正确表达的心意”鲜花是典型的情感消费品。用户在商品详情页停留时间长、犹豫率高经常反复比较送女朋友和送妈妈选的花不一样生日花束和道歉花束风格不一样预算100和预算500的搭配逻辑也不一样。如果系统只能提供“搜索-加购-下单”这条冷冰冰的路径转化率一定会很难看。这一点是我决定引入AI大模型的核心原因。系统的兜底体验不是靠更细的商品分类而是靠一个能听懂自然语言的推荐助手用户输入“闺蜜搬家想送一束明亮点的花预算200以内”大模型结合花语知识库返回推荐结果和解释。这个能力在普通商城里是加分项在鲜花场景里几乎是刚需——因为大多数用户根本不知道自己该买什么花。1.4 需求清单先弄清楚要给谁做、做哪些端我把系统拆成三个端口来规划功能边界用户端小程序风格H5、门店端商家管理与接单、管理后台平台运营与数据看板。用户端核心流程是浏览花束、按场景筛选、AI花语助手、下单支付、订单追踪、售后申请门店端包括商品上下架、花材库存管理、接单出餐、上传配送信息管理后台负责全局商品审核、订单总览、营销活动配置、AI知识库管理、保鲜损耗统计。这么一分开发顺序就清晰了先用户端主流程打通下单闭环再门店端接单履约最后管理后台兜底。AI能力则穿插在用户端的推荐、售前问答以及门店端的文案生成和损耗预警里不单独做成一个孤零零的“AI聊天页面”。2. 技术选型的底层逻辑SpringBoot Vue 的组合为什么是这个项目的最优解2.1 单体架构 模块化包结构而不是一上来就拆微服务很多同学做毕设或者个人项目时有个误区听到“平台系统”四个字就想上微服务注册中心、网关、配置中心全套安排上。我的观点很明确这个项目的业务复杂度远没到需要分布式拆分的地步。鲜花电商的核心链路是商品、订单、库存、配送、支付这些模块强耦合拆成独立服务反而引入网络开销和数据一致性问题。更现实的一点是单体能跑明白的同学拆微服务的坑往往不是技术问题而是运维成本和调试成本。所以我选择SpringBoot单体工程但包结构按业务域做模块化隔离controller层只负责任务分发service层承载业务逻辑domain层统一放实体和值对象。具体包划分是core通用工具与配置、user用户与认证、product商品与花材库存、order订单与购物车、ai大模型接入与知识库、marketing营销与优惠券、admin后台管理接口。这么一摆代码结构跟微服务一样有边界但部署还是一个大Jar包省心得多。技术版本上我用了SpringBoot 3.x配合JDK 17——这个组合已经是当前主流而且SpringBoot 3全面支持虚拟线程后续要做并发性能优化有空间。数据库用MySQL 8ORM选了MyBatis-Plus。可能有人会问为什么不用JPA我的理由很实际MyBatis-Plus的分页和条件构造器写起来直接国内相关教程和方言支持也完善团队新成员上手成本低而且后面复杂SQL需要手写XML时MyBatis体系本来就比JPA好控制。2.2 Vue 3 Element Plus Pinia前端为什么不选 React前端选了Vue 3全家桶具体是Vite构建、Vue Router管理路由、Pinia管理状态、Element Plus做管理后台的UI组件库。用户端H5部分没有用重型组件库而是自己写了一套轻量样式保证页面在手机端加载快。选择Vue而不是React纯粹从项目匹配度考虑Vue的模板语法对后端开发者更友好上手曲线平缓而且Element Plus这种开箱即用的后台组件库能大幅缩短管理端的开发时间。如果你是一个人同时写前后端Vue的性价比明显高于React。前端架构分两层用户H5端和管理后台。用户端路由为懒加载模式图片走MinIO的预签名URL状态管理用Pinia存购物车和登录态。管理后台直接站在Element Plus的表格、表单、弹窗组件上搭很多页面其实就是配置化的增删改查开发效率极高。2.3 前后端交互协议与认证方案无状态JWT为什么合适前后端分离后认证方案我选了JWT而不是Session。原因不复杂H5端可能同时对接微信公众号和小程序端未来还可能要出App服务端无状态认证天然适配多端场景JWT把用户ID和角色直接编码在Token里网关或拦截器解析即可不需要依赖Redis保存会话配合过期时间和刷新Token机制安全性也够用。具体实现上后端用拦截器统一校验Authorization头解析出的用户信息放入ThreadLocal业务代码里直接通过UserContext.getUserId()取当前操作人不用每个Controller重复解析。文件存储这块我选了MinIO而不是直接把图片丢服务器硬盘或云OSS。MinIO是开源的对象存储Docker一条命令就能起起来兼容S3 API上传下载走预签名URL可以避免把AccessKey暴露在前端。商品图、花材图、用户头像、质检照片统一都放这里。后面在踩坑部分我会专门讲MinIO的一个大坑——预签名URL的有效期问题。2.4 技术选型没写进PPT但必须知道的事这里补几个选型时容易被忽略的点。定时任务用的是Spring自带的Scheduled没引入Quartz原因是项目里的定时任务场景都比较简单——每天凌晨算库存损耗、每10分钟清一次过期订单单机部署下Spring自带的定时器足够稳定。消息推送没有引入RocketMQ或Kafka直接在订单状态变更时保存站内消息同时用WebSocket给门店端推送新订单。AI大模型的流式输出走了SSEServer-Sent Events没有用WebSocket全双工因为AI回复是单向推流SSE实现更简单、断线重连机制也更成熟。技术组件选型选择理由后端框架SpringBoot 3.x JDK17主流稳定虚拟线程与jakarta生态升级ORMMyBatis-Plus分页与条件构造器开发效率高SQL可控前端框架Vue3 Vite Pinia上手快生态完善配套管理后台组件齐全数据库MySQL 8通用稳定事务支持可靠对象存储MinIO私有化部署可控S3协议兼容学生项目友好认证JWT无状态、多端适配、部署简单AI接入云厂商大模型API SSE流式生成质量高接入成本低实时推送WebSocket SSE新订单用WSAI回复用SSE各取所长3. 数据库设计与订单状态机先把地基的每一块砖看清楚3.1 核心表结构普通商城表 四张AI专属表项目表数量最终是22张。普通电商必备的user、order_master、order_item、cart_item、address、product_sku、product_category、banner、coupon这些都有但有几个表设计跟普通商城不一样需要重点说明。第一张是flower_batch也就是花材批次表。它记录了某次采购入库的花材SKU、数量、入库时间、预计失效时间、存储条件冷藏还是常温。它的存在让“库存”这个概念从静态数字变成了动态批次队列。第二张是delivery_slot配送时段表把每天按小时切成若干可预约的时段保证用户在前端选配送时间时不会出现门店无法履约的情况。第三张是bot_conversation和bot_message这是AI对话的会话表和消息表用来落地上线后的多轮会话。第四张是knowledge_docAI知识库文档表存花语、配送政策、售后规则这些语料的原始文本和向量化状态。普通商城可能会忽略的一个字段是order_master里的intended_time和delivery_type前者存用户期望送达时间后者区分即刻送和预约送。这两个字段承载了整个鲜花履约的核心逻辑。3.2 订单状态机的流转与边界处理订单状态流转是这个项目里业务逻辑最密集的地方。我定义的状态包括待支付、已支付待备货、备货中、配送中、已完成、已取消、售后申请中。其中待支付订单超时30分钟自动关闭备货中状态只有门店端可以操作确认出餐配送中状态需要同城配送人员上传送达时间才能翻转到已完成。状态机的实现没有引入复杂的工作流引擎就在OrderService里用一组状态流转方法加状态校验来处理。关键点有两个第一每个状态变更操作必须是幂等的防止前端重复点击或接口重试导致重复处理第二所有状态变更都写入一张order_status_log表记录操作人、操作时间和变更前后状态。这张日志表在产品上线后排障时价值极高用户说“我订单怎么莫名其妙取消了”查一下日志立刻定位是超时关闭还是门店拒单。关于库存扣减我是放在支付成功后执行的。用户下单但未支付时只锁定Redis里的预占数量支付回调成功后才真实扣减MySQL里对应花材批次的数量。如果扣减失败订单回滚并触发退款。为了防超卖扣减SQL写成条件更新UPDATE flower_batch SET quantity quantity - #{need} WHERE id #{batchId} AND quantity #{need}受影响行数为0就说明批次库存不足返回友好提示。3.3 前端路由与页面结构H5和后台分开跑前端工程两个一个是用户H5mobile-web一个是管理后台admin-web。H5的主路由包括首页、分类页、商品详情、购物车、下单确认、订单列表、订单详情、AI花语助手对话页、个人中心。管理后台的路由按权限分两块门店角色的路由有接单台、花材库存、商品管理平台角色的路由有全局商品审核、订单总览、知识库管理、营销配置、损耗报表。路由级别的权限控制用了Vue Router的全局前置守卫配合动态路由注册。用户登录后拿到角色信息前端基于角色动态添加对应权限路由没有权限的路由即使手动输入URL也会被拦截回登录页。这里踩过的坑后面会讲history路由模式在刷新页面时如果后端没配回退规则会出现404。3.4 数据库索引与事务边界的一点实操心得写电商项目最容易被忽略的就是索引和事务。我在订单表建了复合索引user_id, status支撑“我的订单”列表按状态过滤flower_batch表建了sku_id, status, expire_time索引支撑近效期优先的库存分配查询。事务边界上我的原则是“一个业务用例一个事务”比如说创建订单方法加Transactional但里面如果调用了远程AI接口绝对不能放在同一个事务里——AI响应的延迟会长时间占用数据库连接高并发下连接池直接被打爆。我的做法是把AI调用放到事务提交之后的业务事件里或者干脆在Controller层先调AI再进Service层落库事务。4. AI大模型集成不是接个API就完事得先想清楚模型能力边界4.1 大模型在这个系统里该干什么、不该干什么AI大模型接入项目之前最重要的一件事是画清楚能力边界。我的划分方式是这样大模型只处理文本理解和生成类任务包括售前的花束推荐对话、售后的客诉应答辅助、商品描述的批量改写、配送问题的语义理解而所有数值预测和强逻辑判断比如库存损耗率计算、销量趋势预测、优惠券门槛校验都交给传统算法和业务规则不让大模型碰。举个具体的反例。最开始我试过让大模型根据历史销量预测未来一周哪种花材需要补货效果非常不稳定同一个问题不同轮次会给出差异很大的答案而且模型不具备时间序列计算能力给出来的补货量完全不可信。后来我把这个功能改成用加权移动平均算法做基于近30天销量和花材寿命基线计算建议补货量结果稳定又可控。所以做AI集成时一定要认清大模型是“语义引擎”不是“计算引擎”把这两者的边界擦清楚项目才不会翻车。4.2 云端API还是本地部署论32G内存能不能跑起来标题里提到了AI大模型本地部署。说实话我也认真评估过本地部署方案。本地部署的核心优势是数据不出域、没有按量计费但代价是硬件门槛和推理速度。一台32G内存的机器用Ollama跑7B或14B参数量级的量化模型是可行的Q4量化后7B模型大概占5GB左右内存能流畅做对话生成。但换成更大的模型比如34B甚至70B32G内存就比较吃力了要么换更激进的量化策略牺牲质量要么干脆靠CPU慢速推理用户体验很差。结合这个项目的实际场景我最终的方案是开发调试阶段用云端API选择国产大模型服务商的API主要是质量稳定、接入快如果团队有内部部署需求再在Linux服务器上用Ollama部署一套Qwen系列的量化模型作为备选推理通道。在SpringBoot代码里我把模型调用封装成一个ChatModelClient接口云端和本地是同一套接口的两套实现切换时只改配置项不需要动业务代码。4.3 RAG架构落地知识库让模型不再胡编乱造直接扔一个大模型接口给用户问“这个花多久能送到”它大概率会编一个答案出来因为模型没有你系统的实时数据。所以必须用RAG检索增强生成架构先把系统里的静态知识——花语大全、配送政策、退换货规则、不同花材生命周期——切块后向量化存起来用户提问时先从知识库里检索出最相关的片段拼进Prompt再交给大模型生成回答。我采用的向量库是开源的Milvus Lite本地文件模式Embedding用的BGE中文模型文本块按300字左右切分、重叠50字目的是保住段落语义的完整性。SpringBoot端做了一个KnowledgeService知识文档上传后自动解析、切片、向量化入库对话时先向量检索TopK5的候选片段加上系统提示词一起发给大模型。这套流程跑通之后AI助手的回答准确率明显提升涉及配送时效的问题会引用配送政策原文而不是凭空发挥。4.4 SSE流式输出的一个完整实现从浏览器到SpringBoot再到模型APIAI对话体验的关键是流式输出。用户发完问题后如果界面等3秒才一次性吐全部文字感知上会非常卡流式输出能做到字字蹦出用户从心理上觉得响应很快。前端实现用Fetch API读取ReadableStream解析SSE数据格式逐片追加到对话界面的消息气泡里。这里的核心SSE后端实现我用SseEmitter封装PostMapping(/api/ai/chat-stream) public SseEmitter chatStream(RequestBody ChatRequest request, HttpServletResponse response) { SseEmitter emitter new SseEmitter(120000L); // 2分钟超时 // 异步执行避免阻塞Tomcat线程 CompletableFuture.runAsync(() - { try { // 1. 检索知识库拿到参考片段 ListString contexts knowledgeService.search(request.getQuestion()); // 2. 构造Prompt String prompt buildPrompt(request.getQuestion(), contexts); // 3. 调用大模型接口拿到流式响应 chatModelClient.streamChat(prompt, new StreamCallback() { Override public void onToken(String token) { emitter.send(token); } Override public void onError(Throwable t) { emitter.completeWithError(t); } Override public void onComplete() { emitter.complete(); } }); } catch (Exception e) { emitter.completeWithError(e); } }); return emitter; }SSE要正常穿透网关和代理服务器有几个关键配置要处理好。开发阶段我用Vite的代理转发SSE流需要在proxy里配置关闭缓冲生产环境如果放在Nginx后面必须把proxy_buffering设为off否则流式内容会被Nginx缓冲到全部结束后才一次性推给浏览器流式效果直接失效。4.5 Prompt模板怎么设计才稳定Prompt模板设计是AI集成中投入产出比最高的环节。我总结的经验是系统级提示词负责定角色和边界对话期提示词负责任务和上下文两者分开管理。系统提示词我放在SpringBoot的配置中心里大致内容就是“你是鲜花电商平台的花语助手你的任务是帮助用户选购合适的花束。回答要简洁、专业、有温度。只能基于提供的知识库内容回答未知信息明确说明不确定。推荐花束时需提供花材构成、参考价格区间和花语含义。”对话期Prompt的核心是让大模型通过JSON结构输出推荐结果方便前端结构化渲染。我会要求模型在回答中携带一个建议花束列表格式为JSON数组每个元素包含name、flowers、meaning、priceRange四个字段。效果稳定之后前端对话页会展示推荐卡片点击直接跳转对应商品详情页整个推荐链路就闭环了。5. 四项创新扩展功能的完整拆解5.1 鲜花保鲜时间轴让每束花都有自己的“倒计时”这是我觉得整个项目最有区分度的功能。用户在订单详情页能看到一个时间轴上面标注了这束花的期望送达时间、最佳观赏期起始、预计凋谢时间不同时间段的卡片背景色会从鲜绿渐变到淡黄再偏暗直观传递“花正在老去”的信息。它解决的是鲜花消费中一个很微妙的需求用户想在最合适的日子收到最饱满的花。实现逻辑分两块。第一块是计算服务每束花的预计凋谢时间 送达时间 花材寿命基线天数 × 环境系数冷藏配送环境系数1.2常温配送系数0.8夏季高温系数再打七折。花材寿命基线存在flower_batch表的expire_time里。第二块是展示服务用户端订单详情页和商品详情页通过一个FlowerLifespanService实时计算剩余花期天数如果剩余花期不足2天商品卡片自动打上“临期特惠”标并调整价格展示。刚开始我准备把这段逻辑塞进大模型里做“智能预测”后来想明白了——固定的规则计算能做的事情永远不要交给随机性强的模型。5.2 AI花语助理多轮对话里的推荐闭环AI花语助理是用户端的核心交互入口入口放在首页的悬浮按钮和商品分类页顶部的搜索框旁。用户典型的提问方式是“明天是情人节想给女朋友送花她喜欢郁金香预算300左右。”系统会走一遍RAG检索查花语知识库、查当前在售商品列表、查配送规则然后生成一个带推荐卡片的结构化回答。这里有个关键设计推荐的商品必须来自数据库实时数据不能由模型凭空生成。所以我的Prompt里会拼接一段当前在售且库存充足的商品摘要列表ID、花束名、价格、花材构成明确要求模型只能从这个列表中选择推荐。这样模型负责语义理解和文案生成商品真实性和库存有效性由系统把关既保证了体验又避免了推荐出不存在的商品。5.3 门店智能备货助手大模型生成文案算法决定数量门店端有一个“智能备货”面板做两件事。第一件事是补货建议用加权移动平均算法算每种花材未来三天的建议备货量算法输入是近30天销量和花材寿命系数输出是一个带置信度区间的数字。第二件事是自动生成促销文案针对即将进入近效期的花材批次大模型会根据剩余花期、当前库存和基础促销规则生成类似“还剩3天花期的香槟玫瑰原价129现价79适合追求性价比的自用客户”这样的说明文案门店一键确认后直接推送到用户端特惠专区。这个组合的好处是算法给了数字的依据大模型给了文字的温度各干各擅长的活。5.4 收货质检照片分析把视觉模型用在不显眼但实用地方鲜花电商的售后纠纷很多时候是“公说公有理”用户说收到的花蔫了门店说发货时候明明是新鲜的。传统的处理办法是人工审核照片效率低且标准不一。我在售后模块里加了一个AI照片质检功能用户上传收货照片后系统调用多模态大模型API分析花材的色泽、挺立度、花瓣状态输出一个新鲜度评分和文字描述比如“花瓣边缘轻微焦枯五朵玫瑰中两朵呈明显萎蔫状态”。这个结果作为售后审核的参考证据结合配送时长超时配送自动加权自动给出处理建议全额退款、部分补偿或驳回。这个功能实际落地时效果超出预期不是因为模型判断有多么精确而是它把售后的处理效率从平均15分钟缩短到了1分钟以内售后客服只需要看模型输出再点确认就行。6. 开发中的踩坑记录这些坑不写出来后面的人还得再踩一遍6.1 SpringBoot 3.x的jakarta迁移老教程代码直接编译失败用SpringBoot 3之后最明显的坑是javax.servlet包全部迁移到了jakarta.servlet。网上一半以上的老教程代码直接搬过来会编译报错很多人第一反应是自己环境有问题其实是规范命名空间的迁移。解决办法只有一个查资料认准SpringBoot 3.x和JDK17以上版本写代码时引入的依赖统一用jakarta前缀遇到老帖子的javax代码要手动替换。另一个关联问题是SpringCloud版本必须选适配SpringBoot 3的版本不要用旧版本硬顶否则无限报错会让你生无可恋。6.2 Maven依赖冲突spring-boot-starter-web和webflux你死我活我踩过实打实的一个坑是同时引入了spring-boot-starter-web和spring-boot-starter-webflux结果应用启动后部分路由返回406。原因是两个starter都会注册DispatcherServlet相关的自动配置Spring MVC和WebFlux在同一个上下文里互相抢占。这个问题的根源是我想引入WebClient做AI接口的异步HTTP调用结果直接拉进来一个webflux全家桶。解决方式是把WebClient相关代码独立成模块或者干脆用Java 17自带的HttpClient在实际项目中我用的是Spring的RestClient配合虚拟线程发起AI请求既顺滑又不带额外依赖。6.3 Vue打包进SpringBoot的细节base路径和history路由H5端开发完要部署上线我的做法是前端build后把dist目录的东西拷到SpringBoot的src/main/resources/static下面。这里两个大坑必须注意。第一个是资源路径前端打包时要把base配置改成./否则所有静态资源会从根路径加载部署到子路径时全部404。第二个是Vue Router的history模式刷新某个子路由会直接404因为后端找不到这个路径对应的Controller。生产环境最省事的做法是用hash模式或者在后端加一个转发规则对非/api开头的路径统一转发到index.html。我为了路由美观选了后者配置一个WebMvcConfigurer来解决。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController(/{spring:\\w}) .setViewName(forward:/index.html); registry.addViewController(/**/{spring:\\w}) .setViewName(forward:/index.html); } }6.4 MinIO预签名URL的过期时间用户看图一半裂了MinIO接入后遇到的坑比较隐蔽图片直传后展示还好但预签名URL默认有效期太短用户打开商品列表后停留一会儿再点开详情页时图片URL已经过期前端直接裂图。这个问题的原因是预签名URL带的是临时token过期时间由你生成时指定。解决办法是把商品图、花材图这些静态图片的预签名URL有效期设置成足够长我设成了7天动态生成的临时上传URL才用短时效。同时在上传接口里对文件类型做校验防止绕过前端直接传可执行文件。6.5 本地部署大模型的量化和内存配置本地部署路线我试过Ollama跑Qwen系列模型。32G内存的机器上7B模型用Q4_K_M量化大概需要6GB内存加4GB左右开销能流畅跑14B模型需要10GB以上推理速度明显下降34B级别就基本不推荐了。另外要把Ollama的并发请求数调小默认配置下同时来多个推理请求会直接OOM。我实际跑下来发现响应速度在3到5秒之间对于开发调试够用。如果将来要做高并发生产环境建议直接走云端API本地部署只适合数据敏感型项目。7. 关于部署、测试和上线的一些个人体会项目整体跑通之后部署上线的流程其实非常简单直接。后端打成Jar包扔到服务器MySQL和MinIO用Docker Compose起服务前端两个工程build完塞进后端静态目录再在宿主机配一个Nginx做访问转发和SSL终止一套单机部署就能把所有端跑起来。如果想要更规范可以把前后端拆开部署前端用Nginx独立服务后端通过反向代理暴露API这个看团队的运维习惯。测试环节我的经验是先集中精力把主链路的端到端用例跑透注册登录、选花下单、支付回调、门店接单、配送完成、售后申请这条链路是系统的心脏任何一环出问题都掉链子。AI功能单独做一轮评测准备一批典型的用户提问记录回答的准确率和推荐商品的可购买率指标跑不上去就去优化知识库切分和Prompt模板而不是盲目换大模型。最后说一点个人体会。做完这个项目我最大的感触是技术栈本身没有新鲜事SpringBoot和Vue都是成熟工具AI大模型平台都在卷接口接入真正决定项目质量的是你对业务的理解深度和把这些技术嵌进业务场景的能力。鲜花电商的特殊性——时令库存、配送时效、情感属性——逼着我在每个模块上都做针对性设计这些设计才是项目真正的亮点所在。如果只是把普通商城的代码换个皮肤技术上再炫,也只是一个作业而当你把AI助手嵌进选花链路、把保鲜时间轴做成可视化的订单体验、把模型能力用在售后质检的真实单据上这个系统才真正有了属于自己的灵魂。如果你也在做类似的项目我建议你别着急动手写代码先花一整个白天把业务特殊性梳理清楚这会让你后面的每一步都走得特别踏实。