企业官网建设流程全解析

又到毕业季，每年这个时候总有一批人被毕设题目卡住。这次选题是《鲲龙装饰公司在线管理系统的设计与开发（手机端）》，后端用SSM，前端用Vue，交付物是论文加程序。别一听“管理系统”就觉得是老掉牙的增删改查，装修装饰行业的业务链其实相当长，从客户咨询、预约量房、设计方案，到报价、合同、施工、材料、验收，每个环节都要有记录。把这类项目做明白，你收获的不只是一个能过答辩的Demo，更是一套完整的企业业务系统开发思路。我按自己的实际开发经验，从需求梳理、技术选型、核心功能到论文写作和答辩准备，把整条链路拆开讲清楚，希望能帮你少走弯路。

1. 项目定位与需求梳理

1.1 装饰公司的业务链路

装饰公司看起来只是“给人装修”，实际运作中信息特别碎。客户从电话咨询、门店到访，到销售跟进、设计师去量房，再到方案沟通、报价谈判、签合同、开工交底、材料进场、施工阶段验收、竣工验收和售后回访，每一个环节都要换人、换系统、换表单。如果没有统一管理，很多信息就散落在Excel表格和微信聊天记录里，某个项目经理请假，工地上做到哪一步了、材料还剩多少，可能没人说得清楚。

所以这个系统管的不是单个小功能，而是一条完整业务线。系统里至少要区分几种角色：管理员负责账号、数据统计、报价和合同审核；销售/业务员管客户、预约和跟进；设计师上传案例、制作方案和报价单；项目经理维护施工进度、材料清单和现场照片。权限如果一开始不做，后面补起来会非常痛苦。我建议第一版先把这条主线打通，其他辅助功能后面再慢慢加。

1.2 手机端不是APP，别自己吓自己

看到“手机端”三个字，很多人第一反应是要做APP。但题目技术栈写的是SSM+Vue，没有说必须用原生Android或Flutter，所以最合理的方案是做一个移动端H5页面，用Vue配合移动端组件库，比如Vant，做出一套适合手机浏览器和微信内打开的系统。手机端展现为底部导航、卡片式列表、大按钮、简化的表单，而不是把PC端页面缩小。

这样做工作量可控，答辩时也容易解释。在论文里可以表述为“面向移动端的响应式设计”，讲清楚H5跨平台、免安装、方便现场使用即可。如果你真想提升演示效果，最多做一个“管理员扫码登录”的彩蛋，但不要花太多时间，毕设的核心是把主业务闭环走通。

2. 技术选型与整体架构

2.1 SSM后端如何分工

SSM是Spring、SpringMVC、MyBatis三个框架的组合。Spring管对象创建、依赖注入和事务，SpringMVC管请求路由和参数绑定，MyBatis管SQL和结果映射。很多同学把SQL直接写在Controller里，Controller里面几百行，Service层形同虚设，这样后面答辩画架构图时很难自圆其说。

我建议一开始就养成分层习惯：Controller只做参数接收、调用Service、返回结果；Service里写业务判断和事务控制；Mapper只写数据库操作。比如新增预约时要同时生成待办提醒，如果第二步失败了，前面写入的预约数据必须回滚。这时候在Service方法上加事务注解，保证数据一致性，论文里还能写一句“系统通过声明式事务保证核心操作的数据完整性”，属于加分项。

@Transactional public boolean createAppointment(AppointmentDTO dto) { customerMapper.insert(dto.getCustomer()); appointmentMapper.insert(dto.getAppointment()); reminderMapper.insert(dto.getReminder()); return true; }

2.2 Vue3+Vant4的移动端组合

前端技术栈如果在2026年做，建议用Vue3+Vite+Vant4，而不是还在Vue2的老教程里打转。Vue3配合新的组合式API写业务代码更清晰，Vite启动速度也比Webpack快很多，省下来的时间可以用来调页面。用Vue Router做页面跳转，Pinia做全局状态管理，Axios发接口请求，这已经是一套很标准的移动端Web方案。

项目结构可以这样规划：src/api放接口请求，src/views放页面，src/router放路由配置，src/store放全局状态。特别提醒一点，不要在项目里同时混用Vant和Element Plus，两个组件库的样式体系容易冲突，手机端优先用Vant就够了。真机调试时，让电脑和手机连同一个Wi-Fi，前端启动后用局域网IP加端口访问，不要用localhost。

2.3 数据库链路与表设计

数据库设计是整个项目的地基。建表不要一上来就铺二三十张，先把核心主链“客户-预约-设计-报价-合同-施工-验收”建出来，再补员工、角色、跟进记录、材料、收款这些辅助表。我常用的核心表大致如下：

这里尤其要注意金额字段，用DECIMAL而不是double，Java对应BigDecimal，不然浮点数精度问题会在论文测试环节暴露出来。外键物理建不建都可以，但业务上必须保证客户、报价、合同之间的关联关系是正确一致的。状态字段建议用编码值，不要直接在页面里写死中文，方便后面扩展。

3. 核心功能模块拆解与实现

3.1 登录、角色权限与安全设计

登录模块不能只做一个账号密码比对。前后端分离后，推荐用Token方案而不是传统Session，因为手机端H5请求接口时需要带身份凭证，Token放在请求头里更通用。Session需要依赖Cookie，在部分移动端浏览器里行为并不可控，所以Token更合适。毕设阶段可以把Token存在后端内存Map里，启动时重置，简单够用；如果要显得专业一点，可以引入Redis，但考虑到答辩环境，不要为了Redis增加额外部署成本。

密码必须加密存储。最基础也要做MD5加盐，再往上可以用SHA-256或者加一层盐值。答辩老师如果问“为什么不能明文存密码”，答“防止数据库泄露后所有账号一起暴露”就够。

@PostMapping("/login") public Result login(@RequestBody LoginDTO dto) { // 根据登录名查用户 Employee emp = employeeMapper.selectByUsername(dto.getUsername()); if (emp == null) { return Result.error("账号不存在"); } String md5Pwd = DigestUtils.md5DigestAsHex((dto.getPassword() + emp.getSalt()).getBytes()); if (!md5Pwd.equals(emp.getPassword())) { return Result.error("账号或密码错误"); } String token = UUID.randomUUID().toString().replace("-", ""); tokenStore.put(token, emp.getId()); return Result.success(token); }

权限控制不要只隐藏前端按钮，后端也要做拦截。比如设计师角色的请求不能操作报价单审核接口。SSM中可以用拦截器实现：校验Token是否存在、用户角色是否匹配、接口是否在白名单内。把这些写进论文“系统安全设计”一节，内容就很扎实。

3.2 客户、预约与跟进管理

客户管理是这类系统的门面，也是最容易出效果的部分。客户列表要支持姓名、手机号、状态、来源筛选。手机端页面适合做顶部搜索框加下拉刷新，卡片上显示客户姓名、小区、意向面积和当前状态。点击进入详情页后，可以看到客户的基本信息、跟进记录、预约历史、关联报价单和合同。

客户状态建议按业务流转设计：意向客户、已预约、已量房、已报价、已签合同、施工中、已竣工、已验收。后端用一个状态码字段维护，前端根据状态码渲染不同颜色的Tag。跟进记录要单独建表，每次沟通都追加一条，包括沟通内容、下次跟进时间和跟进人，这样销售换人接手也能快速了解前情。新增客户时手机号最好做唯一校验，避免重复数据，这是答辩测试用例里很常见的一项。

3.3 设计案例与报价单实现

设计案例模块重点在图片上传。设计师从手机端选择多张案例图，Vant的Uploader组件拿到文件后，调用后端上传接口，后端保存文件并返回访问路径，前端再把路径和案例标题、描述一起提交。这个流程看着简单，但要注意：Uploader组件回调拿到的对象不是标准File，需要先做格式处理；上传接口只负责上传，不要和案例保存逻辑混在一起，方便复用。

报价单是装饰公司最复杂的业务对象之一。一张报价单对应多个项目明细，比如拆除、水电改造、木工、油漆、主材等，每个明细有项目名称、单位、单价、数量、小计。前端以明细表格录入，后端对应报价主表和报价明细表。计算总价时注意折扣字段，有些客户谈的是九五折，有些可能抹零，所以总价不能简单由明细相加，还要带上优惠逻辑。金额计算用BigDecimal，否则会出现小数点后多一位的尴尬。

3.4 施工进度与材料管理

施工进度模块最能体现装饰行业特点。施工阶段可以分：开工交底、水电改造、泥瓦工、木工、油漆、安装、竣工验收。每个阶段记录开始时间、完成时间、负责人、现场照片和备注。手机端更新进度时，Vant的Steps组件可以直观展示当前阶段，项目经理选好阶段后拍照上传、填写说明，业主或管理员在另一端立刻看到更新。

材料管理不要独立于合同存在。一张合同下维护材料清单，包含材料名称、规格、单位、数量、预算单价、实际单价和供应商。项目经理报材料时，系统提示当前合同下材料预算剩余额度。这需要DOUBLE判断：如果实际单价和数量相乘超过预算，就给出警告。这部分在论文中可以写成一个“限额提醒”小功能，答辩时演示很直观。

4. 手机端页面与接口联调细节

4.1 移动端布局与导航设计

手机端页面布局我建议用底部TabBar，四个主要入口：首页、客户、工作台、我的。首页放待办事项、近期预约、工期预警；客户页是列表加筛选；工作台按角色展示常用操作，比如销售看到“新增客户”“预约量房”“跟进记录”，设计师看到“上传案例”“新建报价”；我的页面放个人信息、修改密码、退出登录。路由配置按页面懒加载，避免首屏加载太多代码。

适配方面，Vant组件库基于375px设计稿，在大多数手机浏览器上表现不错。按钮高度不要小于44px，列表点击要有水波反馈或背景色变化。手机端不适合做复杂的多列布局，优先使用单列卡片和折叠面板。图片列表要懒加载，案例图和施工现场图容易撑爆流量，可以用Vant的Lazyload插件，体验会好很多。

4.2 统一返回格式与接口管理

前后端联调最头疼的问题就是每个接口返回结构不一致。我建议后端所有接口都返回统一结构：

public class Result { private Integer code; // 200成功，其他为业务错误 private String msg; private Object data; }

分页接口返回pageNum、pageSize、total、list四件套。前端在Axios响应拦截器里统一处理，成功就返回data，失败就弹Toast提示。这样页面里不用每个请求都写各种错误分支，整体代码干净很多。如果接口路径设计得好，前端和后端可以各写各的，最后按接口文档对接就行。

service.interceptors.response.use( response => { const res = response.data; if (res.code === 200) { return res.data; } Toast.fail(res.msg); return Promise.reject(res); }, error => { // 处理401、网络异常等 return Promise.reject(error); } );

4.3 文件上传与图片预览避坑

图片上传这块坑特别多，很多人在本地开发时好好的，部署到服务器就全部404。原因是后端保存图片到本地目录后，没有把目录映射成可访问的静态资源。在SpringMVC的配置里需要加静态资源映射，把/upload/**指向实际存储目录。如果是前后端分离部署在同一个Tomcat里，可以放到WebApps下的upload目录；如果分开部署，就要保证存储目录有持久化和备份。

上传时还要做两层校验：前端限制文件类型和大小，后端必须再做一次，不能信任前端传来的参数。文件保存名称建议用时间戳加随机数，不要直接用原文件名，避免中文乱码和重名覆盖。保存的路径要返回相对路径，前端展示时拼接完整地址，这样切换开发环境和生产环境时，只需要改接口域名。

5. 论文写作与答辩准备

5.1 论文章节如何组织

论文结构大多按学校模板走，常规套路是：绪论、相关技术介绍、系统分析、系统设计、系统实现、系统测试、总结。最容易写空的是“相关技术介绍”，不要只粘贴一堆网络定义。建议写清楚为什么用SSM而不是SpringBoot，为什么前端选Vue而不是JSP，以及手机端H5相对原生APP在企业应用中的优势。这些内容要结合项目本身去说，才显得是你自己思考过的。

“系统分析”部分要画用例图、功能模块图，并写清楚每个角色有哪些权限。“系统设计”部分要放总体架构图、数据库E-R图、核心表结构。“系统实现”部分尽量每个小节配上线框截图和关键代码片段，截图要保证清晰，不能有脏乱桌面。论文里反复强调“面向业务闭环”和“移动端现场使用”，就是区别于其他管理系统的特色。

5.2 测试数据、演示环境与截图

答辩翻车往往不是因为功能没做完，而是现场演示时随机点到一个数据断层的地方。所以我强烈建议准备一套完整的演示数据：创建三个账号，分别对应销售、设计师、项目经理；准备一个客户从“意向”逐步走到“竣工验收”的完整记录；每张页面至少保存两张不同状态的截图。测试部分不要只写“功能正常”，要写明具体的测试用例，例如：

这些用例是答辩老师最爱翻的地方，提前准备好，被问到时直接展示，比现场临场打字有说服力。演示时手机连不上校园网是个常见事故，最好提前准备好手机热点，或者录一段完整的操作视频作为后备。

5.3 答辩高频问答思路

答辩老师经常问的问题其实就那几类。“为什么用SSM不用SpringBoot”可以答：SSM是传统企业分层框架，用XML和注解结合的方式能更直观理解Spring核心机制；SpringBoot本质是SSM的自动配置封装，类比到科研选题，选SSM是为了学习底层原理。“Token过期怎么办”可以答：前端在响应拦截器里遇到401就清除本地登录状态并跳回登录页，更完善的方案是加刷新Token接口，但毕设阶段做到前端自动引导重新登录已经够用。“数据量大了怎么优化”可以从索引、分页、SQL字段优化、图片分离存储等角度说两条，不需要太深。提前把这些问题的最简答案写进自己的笔记里，答辩心态会稳很多。

6. 常见问题速查与开发经验

6.1 高频报错与解决办法

开发过程中遇到的问题，很多是共性的。我把常见的整理成一份速查表：

分页是很多人的痛点。用PageHelper时，它的作用范围是紧随其后的第一条查询，如果Service里先查了统计信息，再查列表，分页经常失效。解决办法是让分页查询单独走一条链路，或者干脆手写SQL，用LIMIT和COUNT分别控制。要保证pageNum从1开始，返回total时用COUNT查询结果，前端才能正确渲染分页组件。

6.2 开发节奏、命名与工程管理

如果现在开始做，时间线不建议拖太长。第一周确认需求、建库建表、搭好前后端脚手架；第二三周完成后端登录、客户、预约核心接口；第四五周做设计案例、报价、施工模块；第六周集中做手机端Vue页面和联调；第七周测试、修Bug、补测试报告；第八周写论文、截图、做PPT。如果时间只剩两周，就优先做“客户-预约-报价-施工”这条主链路，其余模块简单做数据维护即可。

命名规范这事一定要坚持。Java包名按controller/service/mapper/entity/dto划分，Controller命名为XxxController，Service为XxxService，Mapper为XxxMapper。数据库表名单数小写下划线，字段名用customer_name这种，不要用拼音缩写。代码注释不用多，但核心业务方法和复杂状态判断一定要写一行说明。这些细节在答辩老师翻阅代码时会形成非常好的正面印象。

6.3 一点个人体会

这类SSM+Vue的管理系统项目，我前前后后做过不少版本，最大的体会是：毕设不是炫技，而是把业务讲通、把工程跑通、把论文写圆。很多人一上来就想加各种高大上的技术，Redis、ElasticSearch、消息队列，结果最后连基本流程都走不通。技术栈就算传统一点，只要把装饰公司的业务闭环梳理清楚，把权限、状态流转、数据关联做好，一样能拿不错的成绩。

另外，工程能跑通之后，论文别急着照抄模板。先根据实际功能列章节提纲，再边截图边补充文字，效率高很多。踩过的每个坑都值得记下来，像分页失效、上传路径404、跨域拦截这类问题，写在“开发中遇到的问题及解决”一节里，反而比空谈原理更有说服力。真到答辩那天，你会发现准备充分比临场发挥靠谱得多。