企业官网建设流程全解析

做私人西服定制这个项目，当初真不是看它“高大上”才上的车。我自己接触过好几家定制工坊，他们的日常流程几乎就是微信沟通加Excel表格来回倒腾：客户量体数据躺在某个人的电脑里，面料库存靠记忆，订单做到哪一步要翻聊天记录才能告诉客户。这个leabo系统，本质就是把这些散落在沟通工具和电子表格里的信息，整理成一套可运转、可追溯、可复用的在线业务流程。它不是一个简单展示官网，而是围绕“预约量体—选款选料—下单支付—进度跟踪—售后记录”这条完整链路设计的管理平台。

这篇文章我打算按一次真实项目复盘的方式来写，把技术选型、数据建模、核心接口设计、前端交互以及开发过程中踩过的坑，原原本本讲一遍。内容适合正在做传统行业数字化转型项目的程序员，或者准备用SpringBoot加Vue3搭一个完整前后端分离业务系统的朋友参考。不管你是刚接触这类全栈项目，还是已经有过几个CRUD系统经验，这里面提到的细节应该都能用得上。

1. 项目定位与需求拆解

1.1 私人西服定制的行业痛点在哪

很多人以为西服定制就是“买一件贵点的西装”，但实际业务里，它是最典型的高依赖信息协作的场景。一个客户从首次进店到拿到成衣，中间要经历至少两次量体记录、面料挑选、款式细节确认、版房制作、试穿调整等多个环节。传统手工管理方式下，最让人头疼的不是单量小，而是信息碎。客户半年后想补做一条同面料的西裤，量体数据找不到了；同一个客户两次下单用了不同的领型参数，版房师傅对着两个版本的数据一脸懵。leabo项目要解决的，就是这些碎数据怎么被结构化沉淀下来的问题。

更深一层，定制的“非标”属性决定了系统的数据模型不能套用普通商品系统。普通电商卖一个SKU，规格属性能用规格值列表解决，但定制西服不同，同一个客户每次来量体，胸围、肩宽、袖长等三四十项数据都可能因为体型微调或季节穿衣习惯发生变化。这些数据要支持多版本存储、版本间对比，还要在下单时自动化带入订单。所以系统的核心，不在于界面多炫，而在于数据模型能否承接住定制业务这种“高频变动”和“强上下文关联”的特征。

1.2 用户角色与功能边界划分

我在梳理功能的时候，没有一上来就写代码，先把系统切成了三个视角：客户视角、门店管理视角、量体师视角。分这么细的原因很简单，定制行业的三种角色，关心的信息完全不一样。

客户只关心三个问题：什么时候能预约量体、我最终选了哪些面料和款式、订单现在走到哪个环节。管理端要关心的是客户档案完整度、款式和面料库存、订单产值、以及定制价格策略的维护。量体师最关心的是量体数据的录入效率、历史记录能不能快速调出来、以及每次量体结果和上一次相比有什么变化。

把这三个视角拆开之后，系统模块就非常清晰了：客户档案模块、预约管理模块、款式库模块、面料库模块、量体数据模块、订单中心模块、系统权限模块。每个模块再往下拆，具体到一张表、一个接口，工作量评估就准确很多。权限方面我用了比较传统的RBAC模型，一张用户表、一张角色表、一张菜单权限表，不做多租户，不搞复杂的数据权限隔离，对于门店规模十人左右的业务场景已经绰绰有余。

2. 技术选型与架构设计思路

2.1 为什么是SpringBoot+Vue3+MyBatis+MySQL

先说SpringBoot。这个项目是典型的互联网应用后端，需求变化快，上线周期短。SpringBoot的起步依赖机制大大简化了工程配置，Maven里引依赖、写一个启动类，剩下的自动配置全部接管。而且它的生态太成熟了，JWT鉴权、Excel导出、定时任务、Redis缓存，哪个都能找到现成整合方案，这对一个需要快速交付的项目来说非常重要。

Vue3这块，我最看重的是Composition API对复杂交互逻辑的组织能力。定制下单是一个强流程、多状态的交互场景，用户要一步一步走完预约、量体确认、款式选择、面料选择、订单确认这五个步骤。如果按照Options API写，相关的响应式数据和操作函数会被打散在data、watch、methods各个块里，改起来头大。用setup函数把某个业务域的状态和逻辑聚合在一起，比如把整个下单流程封成一个useOrderFlow模块，代码可读性和维护性都有明显提升。

MyBatis和JPA之间我毫不犹豫选了前者。定制业务的筛选条件组合实在太复杂了，订单列表要根据客户名、下单日期、订单状态、面料类型做各种组合查询，这些用动态SQL去控制，写出来心里有底。JPA虽然开发快，但遇到这种复杂查询时，要么写JPQL，要么还得落到原生SQL，绕一圈回来，性能问题还特别不好定位。MyBatis的半自动模式反而成了优势，所有SQL都在自己手里，一条条看得见。

MySQL没什么可纠结的。项目早期承载的数据量，单实例MySQL完全扛得住，后续真要上规模，加个主从读写分离也很成熟。需要注意的倒是版本问题，MySQL 8.0和5.7在连接驱动、时区处理、默认认证方式上都有差异，很多项目在联调阶段才暴露这些问题，后面我专门列一节讲。

2.2 前后端分离架构的实际价值

这个项目从一开始就定了前后端分离，不是说为了追潮流，而是考虑到团队协作的现实。后端人员专注接口的稳定性和数据正确性，前端人员专注交互细节，两边只要把接口文档和数据结构对齐，就能并行推进互不阻塞。相比传统模板渲染模式，这种协作节奏要舒服得多。

部署层面也是分离的收益点。后端打成的jar包扔到服务器上，前端用Nginx托管静态页面，两者互不干扰。后端接口压力大了可以横向扩容，前端可以挂CDN加速，静态资源和动态请求分开治理，故障定位也清晰。之前的项目里，前段和后端耦合在一起，上线时前端一个静态资源改了，整个服务还要重启，很影响体验。这次完全避免了这个问题。

当然凡事有代价，分离架构带来的最直接问题是跨域。前端页面跑在Nginx的8080端口，后端接口跑在SpringBoot的9090端口，跨域请求是必然要处理的。我这边前后端都做了配合：后端的CorsFilter做全局跨域放行，前端开发环境用Vite代理转发。生产环境下，Nginx再配一层反向代理，把/api路径转发到后端服务，这样前端代码里就不需要写具体的后端地址了。

2.3 工程结构与模块规划

后端工程我按常见的微分层来组织，但根据项目体量做了必要的简化。controller包只负责接收参数和返回结果，不做业务处理；service包承载业务逻辑，包括事务控制、状态校验、价格计算这些；mapper层只做数据库交互，不掺业务判断。entity里放数据库表对应的实体类，dto里放接口交互的数据载体，vo里放需要给前端展示的视图对象。分层这么规整，后续加功能、修bug，定位问题都很快。

前端工程的核心结构没那么复杂，但我重点规划了页面和业务模块的对应关系。views目录下直接按用户端、管理端、量体师端三块区分，各自的页面组件互不混在一起。每个模块的页面、路由、状态管理、接口调用都以业务域为单位组织，不会出现一个global目录塞满了各种毫无关联组件的情况。团队协作时，两个人同时改一个目录的概率大大降低。

3. 核心数据模型设计

3.1 用户、角色与人员档案建模

用户体系这层没什么特殊，做了常规的用户表，字段包括用户名、密码、手机号、状态。密码存储我用的BCrypt加密，不用MD5这种已经被大会挂上高速路做碰撞的方案。角色表维护角色的编码和名称，用户角色关联表支持一个用户挂多个角色，比如一个门店店长，既拥有管理后台的权限，又可以充当量体师，这种场景在真实门店里非常常见。

但定制系统真正要建的，是在用户体系之外，单独建一张客户档案表。用户表只解决登录问题，客户档案表才是业务数据的关联中心。它要把客户的姓名、性别、身高体重、常用收货地址、历史订单次数、消费等级、客户备注全部挂在一起。量体师一次测量记录，要通过客户ID和档案表关联；客户预约表单，也要先在档案层面判断这个客户是不是老客户，老客户要自动带出历史数据。

量体师本身也是用户体系里的一类角色，但我额外在档案表里加了师傅ID字段，用来指定每个客户的专属量体师。这个细节在实际业务里很重要，客户信任关系通常绑定在某个人身上，订单进度的推送也会指定给这个师傅。

3.2 定制业务核心表设计

款式表、面料表、量体数据表、订单表，这四张表是整个系统的地基。

款式表里存的不是简单的一个名字，而是定制工艺参数的集合，包括领型选项、驳头样式、口袋设计、纽扣数量、后开衩方式、里布选项。这些参数不是字段堆列，而是一个JSON字段，我在表里设计了一个styleConfig的字段，前端根据里面定义的参数渲染选择项。这样每新增一个款式，不用改表结构，后台配置JSON就能出新的定制选项。

面料表更强调的是供应链属性。一块进口羊毛面料，要从品牌、产地、成分、克重、颜色系列、库存长度、进货价、零售倍率几个维度记录。库存长度是个容易忽视但很关键的字段，因为定制业务以米为单位消耗面料，后台在订单确认时要扣减对应的面料库存长度，这块我设计成订单提交时加锁扣减，避免多人同时下单把同一匹布超卖。

量体数据表的设计参考了行业里常用的量体单，把胸围、腰围、臀围、肩宽、袖长、衣长、裤长、领围等四十多个字段平铺成列。这样设计看起来占了空间，但实际查询和比对非常方便。每次量体生成一条记录，通过客户ID关联，同时记录量体时间和量体师，历史数据可以随时调出来做前后对比。

订单表是主表，字段集中在订单号、客户ID、量体数据ID、款式ID、面料ID、金额、状态、备注。订单明细表则记录这个订单下的具体产品维度，比如本次订单是上装加西裤两件套，还是仅一件单西，每一件的价格、数量、定制参数都要分开存。主表跟明细表一对多，方便统计客单价和订单结构。

3.3 订单状态流转设计

订单状态我细化成了这几个：待支付、待量体、已量体、制作中、待发货、已完成、已取消。前端会根据状态用时间线组件展示进度，所以每个状态要对应一个状态更新时间字段。这里我没有引入状态机框架，直接用状态常量类加service层的手动校验，规则简单，代码也好读。

不过我在状态变更上做了一点设计，就是增加了订单日志表。每一次状态变更，包括操作人、变更前状态、变更后状态、备注，都会写进日志。这表前期看不出什么价值，但一旦系统上线遇到纠纷，比如客户投诉订单进度没更新，拉出日志表就能定位是哪个环节漏操作，责任清晰，排查效率高很多。

4. 后端核心功能实现

4.1 SpringBoot工程搭建与分层实现

正式搭建工程我用的JDK 17、SpringBoot 2.7.x，这个组合稳定，主流开源组件都能兼容。Maven配置里除了SpringBoot的parent依赖，还需要引进MyBatis Starter、MySQL驱动、Lombok、Validation校验框架、JWT工具包。SpringBoot版本太高反而容易踩一些第三方组件的兼容坑，生产项目我倾向于用落后一年左右的稳定版本，不做小白鼠。

工程的分层在前面提过，但有几个实现细节想单独说。controller层的统一返回结构我一般用Result对象，内部包含code、message、data三个字段。接口正常返回时code为200，业务异常时返回自定义错误码，比如参数缺失10001、订单状态不允许10002之类的规则。这样前端axios拦截器只要统一判断code，就能集中处理错误提示，不用每个接口单独写try catch。

service层我注重事务的开启时机。凡是涉及订单创建、状态变更、库存扣减的操作，必须加@Transactional注解，保证数据一致性。比如订单确认时，要同时生成订单主记录、订单明细、扣减面料库存、更新客户消费次数，这些操作任何一个失败都要回滚，否则会出现订单已经有了但库存没扣成，或者日志记录不一致的情况。

4.2 MyBatis数据访问层的几个关键细节

MyBatis这块最值得说的是Mapper接口的注入方式。SpringBoot中用@MapperScan指定扫描包路径，我踩过一个坑：mapper包和启动类不在同一个父包下，导致Mapper Bean没有注入成功。解决办法是把启动类放在项目根包下，或者明确写全限定扫描路径。这个问题很隐蔽，报错信息还不一定直接告诉你Mapper找不到，经常是service层注入报空指针。

动态SQL是MyBatis的灵魂。订单列表查询要支持多条件筛选，我在XML里用where标签加 if 标签逐层判断，这样参数为空时能自动忽略条件，不会因为多了一个and导致SQL语法错误。前端传参的时候，后端对应的DTO字段要设置成包装类型，不能用基本类型，否则不传参数时默认0也会被判定为有效条件，这是一个容易忽视的技巧。

分页我直接用了PageHelper插件，在service层写查询前调用PageHelper.startPage(pageNum, pageSize)，紧接着执行的查询就会自动带上分页参数。PageHelper有个值得注意的点，它对PageHelper和Mapper查询的先后顺序很敏感，中间不能插入其他数据库操作，否则分页会被传染到别的查询上。这条我同事就踩过，排查了一天。

4.3 定制价格计算逻辑的落地

定制西服的价格不是固定一口价，它由面料价格、款式基础工艺费、特殊工艺加价、加急费用几部分构成。我专门写了一个PriceCalculator组件，输入参数是款式ID、面料ID、是否加急以及一些特殊选项，输出是明细组成和总金额。

计算的关键在于面料价格这块。面料按米计价，系统根据款式默认的单耗，比如一件单西消耗1.8米，一件西裤消耗1.2米，再乘以面料单价。但不同身材的客户，单耗系数不一样，大码体型的用料更多，我在面料表里加了sizingFactor字段，根据客户档案中的胸围尺寸做系数调整。这个业务逻辑虽然不复杂，但单价高，计算错了很难向客户解释清楚，所以我把价格明细的每一个组成部分都写到订单快照表里，即使以后改了价格策略，历史订单的价格组成依然可查。

计算完的价格在下单确认页展示，用户确认后才回传到后端生成订单。这里要强调一个安全细节：后端绝对不能直接信任前端传来的总价，必须重新用后端的价格计算器算一遍，以防有人绕过前端强改请求参数。前后端分离项目里，这类漏洞很容易被忽略，我在接口设计时把总价设置成服务端计算字段，前端传过来的总价仅做展示参考。

4.4 订单流程接口设计

订单模块的接口按流程设计自然分成几组：创建订单、支付回调、预约量体、确认量体、更新订单状态。其中创建订单接口的入参比较多，包括客户ID、款式ID、面料ID、量体数据ID、备注等，我用DTO对象接收，并且加了参数校验注解，必填字段缺失直接返回错误码。

量体环节的接口值得说一下。量体师在门店完成量体后，要把四十多项数据提交到量体数据表。这个接口对数据的完整性要求很高，我做了业务层校验，比如衣长、袖长必须大于0，各部位尺寸之间是否符合基本逻辑关联。数据问题留到版房制作阶段发现，返工成本会翻好几倍，这种前期硬校验是很值得的投入。

更新订单状态是典型的写操作，要注意并发问题。比如同一个订单，管理后台同时收到发货请求和取消请求，谁先执行都有可能。我的处理方式很简单但有效，在XML里的更新SQL加了status条件，比如update order set status=新状态 where id=#{id} and status=旧状态，更新行数为0就说明状态已经被别人改过，直接抛出冲突异常。比分布式锁轻量得多，单机部署完全够用。

5. Vue3前端设计与联调实践

5.1 前端工程搭建与核心依赖

前端工程用Vite搭建，相比Webpack，Vite冷启动速度快到让人觉得不太真实，开发期热更新也是即改即见。状态管理我选了Pinia，Vue3官方推荐的方案，它的API设计比Vuex简洁，没有那么多mutations概念，写起来像正常的赋值操作。UI组件库用了Element Plus，后台管理这类中后台页面基本就是表格加表单，Element Plus的功能覆盖足够。

目录结构上，我按views、components、router、store、api、utils六块去拆分。api目录下按业务模块建文件，customer.js、order.js、style.js、fabric.js，每个文件统一导出对应的接口调用函数。这么做的好处是页面组件里不会直接出现axios请求，所有接口调用集中在api层，改了后端地址结构，只需要调整api层的URL映射，不用到每个页面里去找。

路由配置我用了路由懒加载，每个页面组件通过import函数动态引入。这样首屏加载不会一次性把所有页面都拉下来，管理后台有三十多个页面，懒加载的收益非常明显。配合Vite的代码分割，每个路由块独立打包，首屏加载体积一下子小了很多。

5.2 定制下单流程的前端实现

定制下单流程是前端交互最复杂的部分。我在Pinia里维护了一个orderStore，管理下单过程中的临时状态，包括当前在第几步、已选择的款式对象、面料对象、量体数据、价格计算结果。每一步用户操作都会实时更新store里的数据，最后一步点确认下单时，从store里整理出完整的下单请求数据发给后端。

这个设计的好处在于，用户如果中途离开页面再回来，状态还可以在一段时间内保留。我让orderStore里的数据同步持久化到了sessionStorage，刷新浏览器之后重新进入页面，能从本地缓存恢复起草中的订单。这一点对用户体验的提升是实打实的，定制流程本来就长，要是刷新一下全部重新选择，客户很可能直接放弃。

流程步骤组件我用了一个通用的StepPanel，它根据store里的currentStep控制每一步的显示和隐藏。这里遇到一个Vue3响应式的细节：如果直接对store里的reactive对象做解构赋值，会丢失响应式绑定。我统一用了storeToRefs方法来提取状态，页面里遇到的响应式丢失问题基本都靠这个解决。

5.3 前后端联调与鉴权协作

联调阶段，最痛的不是接口本身，而是环境问题。前端开发时访问后端用的地址是localhost:9090，后端接口又要求带Token鉴权，我就在axios封装里做了统一拦截。请求拦截器从localStorage里取JWT，放到Authorization头；响应拦截器判断HTTP状态码和后端返回的businessCode，遇到Token过期自动跳转登录页。

登录鉴权的细节值得单说。前端并不只是登录页拿到Token就完事了，还要把用户所属角色拉到本地。路由守卫里根据角色动态添加可访问的路由，比如量体师角色只能看到量体工作台和客户查询，管理端角色能看到订单管理、面料管理、价格配置。这样不仅是菜单展示层面的过滤，连路由本身都不注册，访问一个不存在的路由直接404，权限隔离更彻底。

跨域问题我在架构篇里提过，实际开发时还遇到了一个WebSocket的场景。订单进度如果要做实时推送，需要前后端建立WebSocket连接，而跨域下的WebSocket建立握手也会受CORS影响。这个项目我暂时没做实时推送，订单进度通过轮询接口获取，五分钟刷新一次就能接受，等业务量上来再考虑引入消息推送方案，避免一开始过度设计。

6. 常见问题与排查经验实录

6.1 MySQL 8连接与初始化问题

项目联调第一个遇到的高频问题就是MySQL连接报错。报错信息里最显眼的是SSL connection error，原因是MySQL 8默认开了SSL，而JDBC驱动没有配置相应的SSL参数。解决办法是在数据库连接URL后面加上useSSL=false。还有时区问题，报错serverTimezone需要明确指定。我的连接参数最后长这样，其中的serverTimezone=Asia/Shanghai和useSSL=false是我反复试出来的标配。

另一个比较容易踩的是MySQL 8的认证方式。默认的caching_sha2_password加密方式，在一些老一点版本的驱动下会连不上。我用的是mysql-connector-java 8.0.33，和MySQL 8的服务端兼容没问题，但如果是别的老版本，建议要么换成5.7兼容的驱动，要么在MySQL里把用户认证改成mysql_native_password，这个我在部署文档里专门标注了。

数据库字符集也设过问题。项目里有中文的客户姓名和面料描述，一开始建库用的默认字符集是latin1，插入中文直接变成乱码。我后来在建库语句里明确指定了CREATE DATABASE DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci，同时确保连接参数里配置characterEncoding=utf8，前后端加上后中文显示彻底正常。utf8mb4比utf8多了对emoji等四字节字符的支持，现在新建项目我基本无脑选这个。

6.2 MyBatis开发中踩过的坑

MyBatis这边的问题集中出现在参数传递和动态SQL上。

单参数传String时，我发现XML里的#{}会报参数找不到的错误，后来才明白需要加@Param注解给参数命名。多参数时这个注解更必要，不然后端只能arg0、param1这样用，代码可读性很差。我在Mapper接口里统一规范了所有方法签名，凡是超过一个参数的都加@Param命名，这个习惯帮我避免了很多低级错误。

动态SQL的where和set标签也有讲究。我试过在where里直接写and条件导致SQL语法报错，后来只用官方推荐的where标签，它会自动处理第一个条件前面的and。更新操作我更喜欢用set标签，它同样会自动去掉最后一个逗号。这些细节写多了就形成肌肉记忆了，但刚开始不熟悉时它们确实能卡住人半天。

还有一个坑是PageHelper分页参数丢失。排查后发现是PageHelper.startPage和Mapper查询之间插入了一个optional判断逻辑，其中隐藏的数据库查询把分页上下文给消耗了。官方文档提醒了PageHelper是线程本地的线程变量，但实际编码时很容易忽略。我后面立了个规矩，分页查询方法里，startPage下面必须第一行就是对应的Mapper查询，中间不写任何别的SQL操作。

6.3 Vue3响应式与渲染问题

Vue3的响应式是用的Proxy代理，这带来了一个便利，向响应式对象新增属性不需要像Vue2那样用Vue.set，直接赋值就行。但在页面上使用别名解构时，很多人会犯丢失响应式的错误。我的习惯是，模板里直接用store的方法和属性，组件里优先用storeToRefs，经手它取出来的属性引用一定是安全的。

路由懒加载之后，切换页面偶尔会出现白屏和闪烁。刚开始以为是代码问题，排查了一圈发现是动态导入模块时组件还没加载完，控制台其实有警告。我在路由加一个加载动画做过渡，视觉体验就好很多。还有一次白屏是因为前端打包后文件名带hash，部署时清浏览器缓存没清干净，旧的缓存文件指向了不存在的JS资源，刷新强制就好。这个问题在前后端分离项目上线时非常常见，给到用户的部署文档里我都会加上一条“部署更新后需要让用户强刷一次页面”。

表格渲染大列表时，我遇到过渲染卡顿的问题。查了Element Plus的表格文档后，我把不必要的列禁用排序，同时提出了分页加载的方案，每页20条数据，切页时重新请求。这个做法比较保守，但对中后台项目来说，稳定比炫技重要得多。

6.4 一个印象深刻的线上问题

项目上线后的第一个月，反馈最多的不是功能缺失，而是一个数据展示问题：后台订单列表的金额汇总和明细对不上。我排查了两天，最后发现是服务端返回的金额是BigDecimal类型，前端序列化JSON时默认转成了Number，某些金额较大的数值出现了精度丢失。比如数据库里的1499.50，前端显示成了1499.5还是能接受，但像9007199254740993这种大数就会变成9007199254740992。

解决方案也很干脆，统一在SpringBoot配置里设置Jackson将BigDecimal序列化为String，前端拿到的是字符串而不是出现精度问题的数字。这个改动对所有涉及金额的字段都生效，从根上解决了精度问题。这个小问题让我意识到，前后端分离项目里的数据精度问题，不在前端也不在后端，而在两边的类型约定上。

最后再分享一点个人的项目体会。用SpringBoot、Vue3、MyBatis、MySQL这套组合做业务系统，本身没有什么特别高深的技术含量，难点永远在业务理解和细节落地。leabo系统开发下来，我觉得收益最大的不是写了多少代码，而是把定制行业这种强依赖经验、强上下文关联的业务，真正用数据模型跑通了。后续如果想扩展，从订单进度推送、面料库存预警、量体数据智能推荐这几个方向都可以继续深入。希望这篇复盘里的技术决策和踩坑整理，能给你正在做的项目提供一点参考。