企业官网建设流程全解析

每年四五月份，总有一批正在做毕业设计的同学找我聊同一个问题：选什么题目既能顺利过审，又不会在答辩时被问倒。聊得多了，我慢慢发现一个规律——单纯做成"增删改查"的题目太单薄，硬上"人工智能""区块链"又容易把自己架在火上烤。真正适合大多数人的选题，往往是那种业务场景清晰、技术栈经典、能讲出一套完整业务闭环的项目。今天要拆解的这套售楼管理系统，就是典型的这类题目：基于SSM+Vue+MySQL实现，覆盖了从楼盘管理、客户跟进到认购签约、销售统计的完整链路。这篇文章不是贴一堆代码让你自己猜，而是把我做这个系统时的完整思路、踩过的坑、答辩时被问到的点都摊开来写，给正准备做类似毕设的同学一个可以直接参考的落地指南。

1. 为什么选售楼管理系统：一个不算惊艳但稳扎稳打的题目

1.1 技术栈的组合逻辑：SSM+Vue+MySQL为什么是毕业设计的黄金三角

先聊技术选型。这个项目用的是SSM，也就是Spring + Spring MVC + MyBatis，前端是Vue，数据库是MySQL。很多同学一上来就纠结"会不会太老了"，我理解这种担心，但毕设这件事，核心目标从来不是秀技，而是在你能力范围内做一个完整的东西，并在答辩时把原理讲清楚。SSM这套组合在学校课程体系中非常成熟，几乎每个相关专业的培养方案里都有涉及，导师不用花时间理解你的框架，他自己就能判断你的代码质量，这本身就是答辩的加分项。

从角色分工来看，Spring负责对象管理和依赖注入，Spring MVC负责请求分发与参数绑定，MyBatis负责数据库操作。这三层各司其职，和业务逻辑的归属天然契合。前端Vue负责页面渲染和交互，通过Ajax请求访问后端接口，数据格式统一用JSON。MySQL则存储所有业务数据。相比Spring Boot + MyBatis Plus的组合，SSM确实需要手写更多配置和SQL，这也意味着你能在论文里写的东西更多——配置文件的解释、过滤器的实现、动态SQL的编写，这些都是实打实的章节素材。

还有一个现实因素：很多学校的毕设开题报告里要求"国内外研究现状"，SSM和Vue的技术生态有大量的文献可查，写这部分时不用绞尽脑汁编造内容。相比之下，过于冷门的技术栈很容易在文献综述这个环节就卡住。

1.2 售楼业务的真实场景：从楼盘管理到交易跟进的全流程拆解

选售楼这个业务，主要是因为它的业务链条天然适合做权限管理和数据统计。我当时参考了本地一家房产销售团队的日常运作方式，把流程抽象成了这样一段主线：

• 楼盘登记：录入项目名称、位置、开盘时间、均价等信息；
• 房源维护：每栋楼包含多少单元、每单元包含多少楼层、每层有多少套房；房源有户型、面积、朝向、单价、状态之分；
• 客户管理：登记意向客户的基本信息和购房需求，比如面积区间、预算上限、意向户型；
• 跟进记录：售楼员每次和客户沟通后登记跟进情况，记录看房时间和反馈；
• 认购管理：客户选中房源后生成认购单，房源状态改为"已认购"，这一步是整个系统里事务性最强的地方；
• 统计分析：管理者查看成交总量、成交金额走势、户型销量排名、置业顾问业绩等。

这条链条最大的好处是：每一步都对应明确的功能模块和数据库表，模块之间有业务因果关系，不是你为了凑功能硬拆出来的。写论文时用数据流图把这条线画出来，逻辑非常顺畅。

权限方面我设计了三个角色：管理员、经理、置业顾问。置业顾问只能看到自己名下的客户和认购记录，经理可以看全量数据与统计报表，管理员负责楼盘字典和账号分配。这个设计在答辩时很容易被追问，因为体现了你对"用户隔离"的思考。

2. 数据库建模：别急着写代码，先把业务实体理清楚

2.1 核心实体与关系：从业务名词到数据表的映射

做这个项目时我最深的体会是：数据库设计花的时间越长，后面写代码越省力。如果一开始表就建歪了，后期改接口、改页面会非常痛苦。我这边的核心表大致如下，给你们做一个参考：

这里有几点要特别注意的关联逻辑。house表里的status字段我用了0待售、1已认购、2已签约、3已锁定四种状态，是为了让客户在筛选房源时能准确看到"哪些房子还能买"。sale_order表同时挂了house_id和customer_id，且与user_id（置业顾问）关联，是为了统计业绩时能以人分组，也为了在展示"某套房子的购买详情"时能直接回溯完整链路。

还有一点容易忽略：一个客户可能有多次跟进记录，但同一时间只能有一条有效认购单。为了控制"客户不能同时认购两套房"，我在业务层做了校验，而不是单纯依赖数据库约束。这个设计细节在论文的"业务流程分析"里是很好的素材。

2.2 表结构设计的关键决策：状态字段、金额精度与逻辑删除

这个环节有很多细节，直接决定了后面开发的顺畅程度，我把最关键的几个决定罗列如下。

第一，金额字段一律用decimal(10,2)，不要用double或者float。很多同学贪方便用浮点数存钱，最后统计报表时出现一堆0.000001之类的尾差，非常尴尬。MySQL里decimal是精确小数，非常适合金额场景。

第二，status类字段用int外加代码注释，不要用varchar存"待售""已售"这种中文。虽然varchar可读性好，但不利于扩展和国际化的展示。我建议存储时用数字，页面展示时由前端字典做映射。代码里写死也可以，至少在SQL统计时"where status = 1"和"where status = '待售'"相比，前者效率更高，写起来也稳。

第三，给关键表添加is_deleted字段做逻辑删除。这个习惯很多课程里不教，但市面上真实系统几乎都这么干。因为业务数据一旦物理删掉，后续想追溯客户跟进的完整记录就非常困难。技术实现上就是所有查询都默认加上where is_deleted = 0。

第四，create_time和update_time字段统一用datetime类型，由后端在插入和更新时自动填充，避免数据库时区差异的坑。

2.3 初始化数据脚本的妙用：快速搭起演示环境

我这里要特别强调一下初始化数据脚本的作用。很多同学把精力全放在建表上，表建完就开始写代码，结果到了演示那天，浏览器里空空如也，只能现场录入数据，又慢又容易出错。我建议在建完表之后，立刻准备一份完整的初始化SQL，包含一个测试管理员、两个置业顾问、十来位客户、五六个楼盘和几十套房源、若干条跟进记录和认购单。

数据量控制也有讲究。太少看不出统计图表的效果，太多又显得假。我当时是让每个置业顾问名下配备4到6位客户、2到3条成交记录，这样演示报表时，每个顾问的业绩柱状图不会太挤，也足够说明权限隔离的效果。初始化数据的日期最好集中在最近两三个月，这样"本月成交走势图"展示出来非常自然。

这一步的另一个附加值是：论文的"系统测试"章节可以完全基于这批初始化数据来写测试用例，每一步的预期输出都是可复现、可截图验证的。比你从头录数据要体面得多。

3. 后端核心实现：从工程搭建到接口开发的全过程

3.1 工程结构分层：为什么采用包名驱动的模块划分

后端部分，我用的是Maven单工程多包结构，没有拆多模块。毕设阶段直接拆成多个Maven模块反而会给自己增加部署和打包的负担，单工程按包划分完全足够。

com.demo.sale ├── controller # 控制层：接收请求、参数校验、返回JSON ├── service # 业务层：事务控制、业务逻辑 ├── mapper # 数据访问层：MyBatis接口 ├── entity # 实体类：和数据库表对应 ├── common # 统一返回结果、常量、异常处理 ├── interceptor # 登录拦截器、跨域配置 └── util # 工具类：JWT、MD5加密等

也许你会问，为什么不把逻辑直接写在Controller里面，节省时间。我见过不少同学这么干，前两页代码确实快，但越到后面越痛苦。比如"创建认购单"这个操作，涉及房源状态检查、客户信息确认、生成订单号、扣减房源库存、插入认购记录这几步，如果全部堆在Controller里，一旦出现异常，事务不好管理，代码也没法复用。分层之后，Controller只做参数接收和结果返回，Service层专注业务规则，Mapper层只管SQL交互，每一层的职责都非常清晰。答辩的时候导师问"某一层是干什么的"，你随口就能答上。

3.2 登录鉴权的实现：JWT在前后端分离项目中的实践

登录鉴权是这套系统里非常核心的一个点。我采用的是JWT方案，流程是这样的：

• 用户提交用户名和密码，后端校验通过后，用JWT工具类生成一段签名Token，里面包含userId、username、role和过期时间；
• 前端把Token存在localStorage里，每次请求在请求头里带上Authorization: Bearer {token}；
• 后端写一个HandlerInterceptor拦截器，对非登录接口进行Token校验，通过解析Token得到当前用户信息，存入请求上下文；
• 前端路由守卫检查本地是否存在Token，没有就跳转到登录页。

这里选择JWT而不是传统的Session，核心原因有两个。第一，前后端分离架构下，接口是跨域调用的，Session处理跨域需要额外配置CORS专用会话，麻烦；JWT本质上就是一个加密字符串，不依赖服务端存储，天然适合跨域。第二，我的系统三个角色（管理员、经理、顾问）需要根据角色做菜单和接口的不同权限控制，JWT载荷里直接携带角色信息，后端拦截器解析后就能做权限判断，省去每次查库。

代码上其实不复杂，核心逻辑如下：

// 登录成功后生成Token String token = JwtUtil.createToken(user.getId(), user.getUsername(), user.getRole()); return Result.success(token);

// 拦截器中的校验逻辑 public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String header = request.getHeader("Authorization"); if (StringUtils.hasText(header) && header.startsWith("Bearer ")) { String token = header.substring(7); try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; }

需要注意的点是密钥和过期时间的配置。密钥不要硬编码在代码里，我放在application.properties中用@Value读取，过期时间设置了2小时，和前端路由守卫的检查逻辑保持一致，避免用户操作到一半Token过期被强迫重新登录的尴尬。

3.3 核心业务接口：房源筛选、认购下单与统计报表的实现要点

说了分层和鉴权，接下来看三个最典型的核心业务流程。

首先是房源的按条件分页筛选。这个接口是售楼员天天用的功能，搜索条件包括楼盘、户型、面积区间、朝向、状态和价格区间。MyBatis的动态SQL在这里发挥了大作用，我用<where>和<if>标签拼条件，没有条件时返回全量分页数据。分页用PageHelper插件，写起来很省事，但要注意在Controller层返回时把Page对象转成自定义的分页结构，避免把PageHelper的字段原样暴露给前端。

<select id="selectByCondition" resultType="com.demo.sale.entity.House"> select h.*, b.name as buildingName from house h left join building b on h.building_id = b.id <where> <if test="buildingId != null"> and h.building_id = #{buildingId} </if> <if test="layout != null and layout != ''"> and h.layout = #{layout} </if> <if test="minPrice != null"> and h.unit_price &gt;= #{minPrice} </if> <if test="maxPrice != null"> and h.unit_price &lt;= #{maxPrice} </if> <if test="status != null"> and h.status = #{status} </if> and h.is_deleted = 0 </where> order by h.create_time desc </select>

第二个是认购下单。这个操作涉及多张表的更新，必须加@Transactional事务控制。我是在Service层完成整个流程的：根据houseId查出房源，判断status是否等于0；客户Id是否存在且未处于异常状态；然后调用updateHouseStatus把房子改成已认购；再插入一条sale_order记录；最后回填客户状态。如果没有事务控制，一旦中间步骤失败，就会出现房子状态变了但订单没生成的情况，演示时被导师发现可就尴尬了。启事务其实只需要一个注解：

@Transactional(rollbackFor = Exception.class) public void createSaleOrder(SaleOrderRequest req) { House house = houseMapper.selectById(req.getHouseId()); if (house == null || house.getStatus() != 0) { throw new BusinessException("房源不存在或已被认购"); } houseMapper.updateStatus(req.getHouseId(), 1); saleOrderMapper.insert(buildOrder(house, req)); }

第三是统计报表接口。这里主要用SQL聚合查询。成交金额走势按月用GROUP BY DATE_FORMAT(deal_time, '%Y-%m')，户型销量排名用GROUP BY layout ORDER BY COUNT(*) DESC，置业顾问业绩榜则关联sale_order和admin_user，按user_id分组求和。这些聚合SQL都是在mapper里手写的，导向也很明确——写清楚注释，答辩时导师问你的是"这个统计是怎么实现的"，你直接指着SQL讲一遍，比打一堆文字解释强得多。

4. 前端实现要点：页面组织、请求封装与交互细节

4.1 项目初始化与路由设计：如何让页面结构与业务模块一一映射

前端部分我用Vue 2 + Element UI + ECharts组合。Vue 2到现在依然是很多课程里的默认版本，生态成熟稳定，遇到问题随手一搜都能找到方案，对毕设项目来说非常友好。

项目初始化我全程用Vue CLI，勾选了Router和Vuex。页面结构上，我采用了一个主布局（Layout）加多个业务页面的方案：主布局包含左侧菜单栏、顶部用户信息栏和内容区，子路由在内容区挂载。这样的设计好处是，菜单和用户信息全局只维护一份，不需要每个页面重复写。

路由表我大致是这样的：

{ path: '/layout', component: Layout, redirect: '/layout/dashboard', children: [ { path: 'dashboard', name: 'Dashboard', component: () => import('@/views/dashboard/index.vue'), meta: { title: '销售看板' } }, { path: 'house', name: 'HouseList', component: () => import('@/views/house/index.vue'), meta: { title: '房源管理' } }, { path: 'customer', name: 'CustomerList', component: () => import('@/views/customer/index.vue'), meta: { title: '客户管理' } }, { path: 'sale', name: 'SaleOrder', component: () => import('@/views/sale/index.vue'), meta: { title: '认购管理' } }, { path: 'statistics', name: 'Statistics', component: () => import('@/views/statistics/index.vue'), meta: { title: '统计分析' } } ] }

路由守卫和菜单权限我是这样处理的：登录后把用户的角色存进Vuex和localStorage，在路由的meta里标记每个页面允许哪些角色访问，然后通过beforeEach守卫做统一判断。比如普通置业顾问想跳过菜单直接输入/statistics的路径时，守卫会拦截并跳转到无权限提示页。

4.2 Axios请求封装：统一处理Token、错误码和异常提示

前端和后端联调时，最容易出现的问题就是每个页面各自的请求写法不统一，错误提示五花八门。我的做法是封装一个统一的request工具，基于axios实例创建，用请求拦截器统一加Token，响应拦截器统一处理状态码。

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.msg || '请求失败') return Promise.reject(new Error(res.msg)) } return res }, error => { if (error.response && error.response.status === 401) { Message.error('登录已过期，请重新登录') localStorage.removeItem('token') router.push('/login') } else { Message.error('网络异常，请稍后重试') } return Promise.reject(error) } ) export default service

封装完成之后，页面上调用接口非常方便：

import request from '@/utils/request' export function getHouseList(params) { return request({ url: '/house/list', method: 'get', params }) }

还要提一个跨域的坑。前端开发服务器端口是8080，后端Tomcat端口是8081，肯定存在跨域问题。我的做法不是在后端加@CrossOrigin满天飞，而是在vue.config.js里配置devServer代理：

devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true, pathRewrite: { '^/api': '' } } } }

这里有个细节值得注意：前端请求路径写/api/house/list，代理转发到后端时去掉/api前缀，变成/house/list。这样后端接口路径保持简洁干净，前端只维护一份baseURL，部署时只要Nginx里同样配置转发规则即可。

4.3 关键交互场景：筛选表单联动、ECharts看板和表单校验

交互方面我挑三个典型场景聊透。

房源筛选这个页面，我用的是Element UI的el-form。实际的联动细节比看起来复杂：户型下拉框的数据从后端字典接口获取，面积区间用的是el-slider双滑块；每调整一个条件，点击搜索时重新向后端发请求。比较隐蔽的坑是滑块值在初始化的时候是数组[0, 200]，如果需要清空条件，必须重置为初始值而不是置空，否则会导致请求参数异常。

ECharts看板是答辩时的视觉亮点。我做了三张图表：月度成交金额折线图、户型销量饼图、置业顾问业绩柱状图。图表数据来自后端统计接口返回的JSON结构，前端只需要遍历组装成ECharts要求的data格式。这里我想提醒一个加载时序的问题：因为页面切换时图表容器可能还未渲染完成，我是在mounted钩子里用this.$nextTick()再初始化图表。如果直接初始化，偶尔会出现图表宽度为0的报错，演示时很掉链子。

表单校验我用的Element UI自带的rules，手机号、身份证号之类的字段写自定义正则。比较实用的技巧是，在提交认购订单前先做一次校验，通过后再调接口，避免非法数据直接传到后端。但请注意，前端校验永远只是体验优化，后端必须再做一次完整校验，不能信任任何来自客户端的输入。

5. 答辩与文档：毕设分数差在哪，往往不在代码本身

5.1 演示顺序：如何把页面操作组织成一条说服力强的主线

代码写完只是第一步，答辩演示的节奏往往比代码本身更影响分数。我见过太多人一上来就点进菜单，这里看一下那里看一下，导师看完完全没有代入感，也不知道你的系统到底解决什么问题。我的建议是：把演示组织成一个完整的业务故事。

我当时的演示流程是这样的：

1. 先用管理员账号登录，展示楼盘和房源管理：为什么楼盘要分栋、分单元管理，数据是怎么结构化录入的；
2. 切换成置业顾问账号登录，演示他只能看到自己的客户：这一步专门体现权限隔离；
3. 模拟一个完整业务过程：查看客户列表—>找到一位意向客户—>查看跟进记录—>进入房源列表根据预算筛选房源—>帮客户锁定一套—>生成认购单—>返回列表看到房源状态变成已认购；
4. 切换成经理账号，演示统计报表：月度成交走势、户型销量排行、团队业绩对比；
5. 最后展示合同模块和基础字典管理。

这条线走下来，导师会看到你系统的每个功能都不是孤立的，数据在模块间是有因果关系的。演示前把每个页面的几条核心数据背熟，能精确说出"某个客户上周五看的房，今天完成认购，成交金额是多少"，一下子就有说服力了。

5.2 高频答辩问题：顺手能答的就是加分项

答辩环节的问题基本是固定的套路，有些问题我现在闭着眼都能列出来。提前准备了，场上就能非常从容。

第一个高频问题：为什么用SSM而不是Spring Boot？这不是让你说Spring Boot不好，而是讲清楚你的考量点。我的回答思路是：SSM作为课程核心授课内容，自己对其原理更熟悉，能在论文中完整描述配置的演进和框架整合过程；Spring Boot的自动配置虽然简化开发，但容易掩盖底层的初始化细节，对理解框架运行机制来说不一定更有利。这种回答显得你思考过，而不是人云亦云。

第二个高频问题：为什么使用JWT，它的Token过期了怎么处理？你就把JWT的三段结构（头部、载荷、签名）讲清楚，然后说明2小时过期策略和前端401拦截跳转逻辑即可。如果导师再深挖一次签名如何防止篡改，简单回答"服务端持有密钥，任何改动都会导致验签失败"就足够。

第三个高频问题：如果同时有两个顾问抢同一套房源，你的系统怎么处理？这个问题其实是考验并发意识。诚实说，毕设项目没有引入分布式锁或数据库乐观锁，但我会先说明：在认购下单的事务中，SQL更新使用了带状态条件的update house set status = 1 where id = ? and status = 0，数据库的行级锁会保证只有一个事务能更新成功，另一个事务更新0行并抛出业务异常。这个回答既承认了项目的边界，也展示了你在数据一致性上的思考。

我之前指导过一位同学A的毕设，他做的是类似系统。答辩当天导师就问了并发锁这个问题，他用了上面这个思路回答，导师追问他"为什么不直接select再判断"，他顺势解释了这样做的失效场景——两个请求同时select到status=0，然后同时update，就会产生超卖。这个一正一反的回答组合，直接让导师点头了。

5.3 论文文档中容易被低估的三处细节

论文的比重在很多学校占到50%以上，代码写得再好，文档拉胯依然可能翻车。我重点提醒三处细节。

第一，E-R图和流程图不要用Word自带的形状拼凑，最好用专业绘图工具完成，输出图片再插入论文。E-R图要能清晰地展示所有实体之间的一对多关系，流程图至少要覆盖登录、房源筛选、认购下单三条业务线。

第二，需求分析章节不能只写"系统分为管理员模块和用户模块"这种废话。我当时是自己先去调研了售楼业务流程，然后按角色把用例整理出来。需求分析写得扎实，后续的设计和实现才顺理成章，导师也能看出你真的做过功课。

第三，测试章节不要只写"功能测试通过"这种话。我建议分模块写出完整的测试用例表格，包含用例编号、测试步骤、预期结果、实际结果、是否通过这些列。拿登录模块举几个例子：正确账号密码是否进入首页、错误密码是否提示重新输入、空用户名是否有前端校验、Token过期后操作是否跳转登录。五六张这样的表格，整个测试章节的内容就非常立体了。

最后补充几句

做完这个系统后，我个人在实操中的体会是：毕业设计最宝贵的收获不是"我写了一个系统"，而是亲身体验了一遍从业务调研、数据库设计、接口开发到前端联调、文档撰写的完整流程。这套售楼管理系统，业务上有真实场景支撑，技术上是SSM+Vue+MySQL这个经典组合，难度适中，深度又足够撑起一篇合格的毕业论文。

最后再分享一个小技巧：把初始化数据脚本和部署说明文档在答辩前留成一份单独的Markdown文件，不仅自己测试方便，演示前重置数据也快。如果后续想继续扩展，可以为这个系统增加一个定时任务，每天统计成交数据生成日报并推送给经理，用Spring自带的@Scheduled注解就能实现，这又成了论文里一个不错的创新点。希望这篇拆解对正在选题或者已经开工的你有所帮助。