1. 这项目到底在做什么先给结论房屋销售管理系统说穿了就是把中介门店或者开发商售楼处那一堆纸质台账、Excel表格、微信群报备统一塞进一个Web系统里。房源、客户、带看记录、成交订单、回款进度全部在一个浏览器界面里搞定。我最早接触这类项目是在给一个本地中介门店做信息化改造的时候当时门店老板的需求很简单别再让我每天晚上手工汇总经纪人报上来的客户跟进记录了。就是这么朴素的诉求最后长成了一个完整的Web项目。这个选题在毕业设计、课程设计、个人练手项目里出现的频率非常高原因有几个一是业务场景足够熟悉不用费劲去理解领域知识二是功能边界清晰不像电商系统那样有无穷无尽的营销玩法三是技术选型自由Java、PHP、Python、C#甚至小程序都能落地适合不同技术栈的开发者。如果你正打算做这个题目或者已经在做了这篇内容值得看完。我会把系统拆开来讲先梳理清楚房屋销售管理系统必须包含的模块和核心数据表设计再逐层讲解前端页面、后端接口、数据库交互的实现思路最后给出我自己实践下来最有价值的几段关键代码和避坑经验。无论你选Java Spring Boot、PHP ThinkPHP、Python Flask还是C# ASP.NET底层逻辑完全一致我讲的是思路和骨架你套到自己的语言里就能用。2. 从业务调研到表结构设计第一步错了后面全歪很多做这个题目的人上来就打开IDE建项目写代码结果做到一半发现逻辑对不上只能推翻重来。正确顺序应该是先把业务流程画清楚至少是纸质草图级别的梳理。2.1 核心业务角色与流程定义房屋销售系统的角色一般分成三种管理员店长/经理、销售人员经纪人、客户买房/租房的人。有些系统会多一个财务角色但中小型规模里财务功能通常并入管理员。围绕这三个角色核心流程是房源录入、客户登记、带看预约、成交签约、回款跟踪。这里有一个很容易忽略的细节房源和客户是两套独立的数据通过带看记录和成交订单产生关联。很多新手设计表结构时直接在房源表里加一个customer_id字段这在大数据量下会出问题因为一个房源会被多个客户带看一个客户也会看多套房源这天然就是多对多关系必须用中间表承载。我画流程图时是这么做的第一步定义核心实体。房源、客户、员工、带看记录、订单、收款记录一共六个。第二步定义实体间关系。员工录入房源、员工登记客户、员工创建带看记录关联房源客户、员工创建成交订单关联房源客户、订单产生收款记录。第三步定义状态流转。房源状态从在售到已预定到已成交订单状态从待付款到部分付款到已完成客户状态从意向到已成交。状态字段用整数表示配合状态名比直接用字符串稳定得多。2.2 六张核心表的结构设计基于上面的分析我给出这套表结构字段命名尽量跨语言通用无论你用MySQL、PostgreSQL还是SQLite都能直接迁移房源表house字段名类型说明idint主键自增house_novarchar房源编号如BJ-20250115-001titlevarchar房源标题如北区三居室南北通透communityvarchar所在小区areadecimal建筑面积平方米layoutvarchar户型如3室2厅1卫floorvarchar所在楼层total_pricedecimal总价万元unit_pricedecimal单价元/平方米house_typetinyint1新房2二手房3出租statustinyint1在售2已预定3已成交4下架create_emp_idint录入员工IDcreate_timedatetime录入时间客户表customer字段名类型说明idint主键自增namevarchar客户姓名phonevarchar联系电话demand_typetinyint1买房2租房budget_mindecimal预算下限万元budget_maxdecimal预算上限万元demand_areavarchar意向区域demand_layoutvarchar意向户型statustinyint1意向客户2已预定3已成交4已流失bind_emp_idint跟进员工IDcreate_timedatetime登记时间员工表employee字段名类型说明idint主键自增emp_novarchar工号namevarchar姓名phonevarchar手机号roletinyint1管理员2销售passwordvarchar登录密码哈希存储statustinyint1在职2离职带看记录表visit_record字段名类型说明idint主键自增house_idint房源ID外键customer_idint客户ID外键emp_idint带看员工IDvisit_timedatetime带看时间feedbackvarchar客户反馈statustinyint1待跟进2有意向3无意向订单表order字段名类型说明idint主键自增order_novarchar订单编号house_idint房源IDcustomer_idint客户IDemp_idint成交员工IDdeal_pricedecimal成交价万元deal_timedatetime成交时间statustinyint1待付款2部分付款3已结清4已退款收款记录表payment_record字段名类型说明idint主键自增order_idint订单IDpay_typetinyint1定金2首付3尾款4全款pay_amountdecimal收款金额万元pay_timedatetime收款时间operator_idint操作人ID这套设计里我特别想强调几个取舍面积和价格一律用decimal不用float。为什么因为float在二进制里无法精确表示0.1这类十进制小数累计求和时会出现0.30000000000000004这种鬼问题。做金额相关的系统精确是第一原则。状态一律用tinyint存整数在代码里定义常量对照表。因为字符串状态如在售在售中sale在跨团队协作时很容易产生歧义而整数配合注释和枚举类既稳定又节省存储。房源编号和订单编号用业务编号不是直接用自增ID。自增ID一旦暴露在URL里比如/order/detail?id1025别人遍历ID就能看到所有订单数据这是严重的安全隐患。业务编号带日期和随机因子既方便人识别也能避免越权遍历。2.3 为什么外键关系不建议真正建在数据库里这是我在做的过程中踩过的一个认知坑。大学教材里讲外键约束讲得天花乱坠但到了真实项目里包括很多一线互联网公司反而很少在数据库层面建物理外键而是靠应用层维护逻辑外键。原因很简单物理外键会让插入、更新操作的性能下降而且一旦数据需要分表分库物理外键直接失效。我在这套系统里的做法是表结构设计时明确外键关系house_id、customer_id、emp_id这些字段但在建表SQL里不写FOREIGN KEY约束。删除数据时在业务逻辑层先做检查比如删除房源前先查询visit_record表里是否有引用记录有就阻止删除或做软删除。这样既保证了数据一致性又避免了一堆物理外键带来的运维麻烦。3. 前端到底怎么搭页面设计比想象中更重要Web系统的用户体验页面布局和交互占一多半。很多毕设项目功能齐全但看着就是程序员审美评分上不去原因就是前端太粗糙。我来说说我处理前端的方式。3.1 页面框架与布局方案整体布局采用经典的后台管理结构左侧固定侧边栏放菜单右侧内容区放业务页面。菜单项包括首页仪表盘、房源管理、客户管理、带看记录、订单管理、回款管理、统计报表、系统设置。前端技术选型我用的是Layui为什么Layui是一款国人开发的轻量级前端框架组件风格统一、文档全中文、上手成本低特别适合单人或小团队快速开发后台系统。如果你用Vue全家桶虽然更现代但组件库选型、路由配置、状态管理这些光配置就要折腾好几天。对于这套系统Layui的表格组件table、表单组件form、弹出层组件layer几乎覆盖了所有需求。页面配色上我建议用蓝白灰的主色搭配。蓝色系是管理系统的安全色不会出错。顶部导航栏可以用深色侧边栏用浅灰底内容区白底这样的视觉层次最清晰。这是很多现成后台模板验证过的最佳实践别自己搞大红大紫的配色尤其是毕设答辩现场太花的界面非常减分。3.2 房源列表页一次标准的表格搜索弹窗组合房源管理页是整个系统的使用频率最高的页面它的交互设计基本决定了系统好不好用。页面结构分三块顶部搜索栏房源编号、小区名称、户型、状态四个筛选条件中部工具栏新增房源、批量删除按钮下方数据表格房源编号、标题、小区、面积、户型、总价、单价、状态、录入人、操作列操作列里放两个按钮编辑和删除。点编辑弹出表单弹窗点删除先弹确认框再执行删除。这里给出一个房源列表的数据加载和渲染流程我用的是前后端不分离的传统模式后端渲染HTML前端用Layui的table模块发Ajax请求拿JSON数据// 注意以下代码适用于Layui框架加载table模块后使用 table.render({ elem: #houseTable, url: /house/list, // 后端接口 page: true, cols: [[ { type: checkbox }, { field: houseNo, title: 房源编号 }, { field: title, title: 标题 }, { field: community, title: 小区 }, { field: area, title: 面积, templet: function(d) { return d.area ㎡; }}, { field: totalPrice, title: 总价(万), templet: function(d) { return d.totalPrice 万; }}, { field: status, title: 状态, templet: function(d) { var map {1: 在售, 2: 已预定, 3: 已成交, 4: 下架}; return map[d.status] || 未知; }}, { title: 操作, toolbar: #houseBar } ]] });这里有个很关键的点表格列的显示和处理逻辑分开。数据库里存整数状态前端通过templet模板函数映射成中文显示。这样只要后端返回规范JSON前端就能独立处理展示逻辑。3.3 表单设计新增和编辑为什么复用同一个弹窗房源新增和编辑共用同一个表单弹窗这是后台系统的通用做法。实现方式打开弹窗时判断是新增还是编辑编辑时先通过一行table.on(tool)监听拿到当前行的数据然后再用form.val(houseForm, data)把数据回填到表单。这里要特别注意编辑回填时有时区问题。如果你的系统允许填带看时间、预约时间这种datetime字段后端返回的如果是标准UTC时间字符串前端回填到日期选择器时不要直接赋值原始字符串要先格式化。我遇到过的情况是编辑一条带看记录时时间总是比实际晚了8小时排查了半天发现是ISO格式字符串直接填入Layui日期组件时组件按本地时区重新解析导致的。后来我在后端接口返回时统一格式化成了YYYY-MM-DD HH:mm:ss问题才消失。4. 后端接口设计与核心代码实现逻辑清晰才能少踩坑后端部分是整个系统的大脑。我分别用几种主流语言的核心思路讲一遍但重点剖析通用逻辑。4.1 接口返回格式统一一切交互的基础无论你用什么语言后端接口返回的数据格式必须统一。我用的标准结构是{ code: 0, msg: 操作成功, data: {} }code为0表示成功非0表示失败。msg是给用户看的提示信息data是业务数据。这个格式对应Layui的前端组件约定表格组件需要page时data里返回{code:0, msg:, count:总条数, data:当前页数据}。统一的返回结构能极大减少前后端联调时的沟通成本。一开始我在每个接口里手动写echo json_encode($result)后来封装了一个统一响应类代码瞬间干净很多。我用PHP实现时?php // JsonResult.php class JsonResult { public static function success($data null, $msg 操作成功) { self::render(0, $msg, $data); } public static function error($msg 操作失败, $code 1) { self::render($code, $msg, null); } private static function render($code, $msg, $data) { header(Content-Type: application/json; charsetutf-8); echo json_encode([code $code, msg $msg, data $data]); exit; } }Java Spring Boot里就是定义一个R类Python Flask里就是make_response返回jsonify对象C#里就是return Ok(new { code 0, msg ..., data ... })思路完全一样。4.2 房源接口的几个关键细节这是房源列表接口的完整实现思路我以PHP为例因为PHP的代码量最少逻辑最直观。但请记住下面这些点在任何语言里都成立。第一分页参数处理。Layui表格默认传page和limit两个参数后端接收时要做默认值处理。用户没传page时默认第1页没传limit时默认10条。SQL里用LIMIT ? OFFSET ?参数绑定防止SQL注入。第二搜索条件的动态拼接。房源列表有四个搜索条件每个条件都可能为空。拼接SQL时用一个where数组只有条件不为空时才追加到查询语句里。这样避免了where 11那种丑陋且有一定SQL注入风险的写法。// HouseController.php 中的列表方法伪完整实现 public function list() { $page isset($_GET[page]) ? intval($_GET[page]) : 1; $limit isset($_GET[limit]) ? intval($_GET[limit]) : 10; $where where 11 ; $params []; if (!empty($_GET[houseNo])) { $where . and house_no like ? ; $params[] % . $_GET[houseNo] . %; } if (!empty($_GET[community])) { $where . and community like ? ; $params[] % . $_GET[community] . %; } if (!empty($_GET[status])) { $where . and status ? ; $params[] intval($_GET[status]); } $total Db::querySingle(select count(*) from house . $where, $params); $offset ($page - 1) * $limit; $list Db::queryAll(select * from house . $where . order by create_time desc limit ? offset ?, array_merge($params, [$limit, $offset])); JsonResult::success([ count $total, data $list ]); }第三返回值不能直接暴露密码字段。查询员工列表或做任何有敏感字段的表查询时SQL里明确写出需要的字段不要偷懒写select *。否则用户密码的哈希值一旦泄露出去虽然不能直接登录但可以被离线撞库。这是安全底线。4.3 成交业务的事务处理一组操作要么全成功要么全失败房屋成交是整个系统里逻辑最重的一个业务动作。一笔成交至少涉及三张表的变更房源表状态改为已成交订单表插入一条新订单客户表状态改为已成交这三个操作必须在一个数据库事务里完成。任何一步失败整个操作回滚。不然就会出现订单表里有成交订单但房源状态还是在售的脏数据。以Java Spring Boot为例事务处理有两种方式注解式和编程式。注解式最简洁Service public class OrderServiceImpl implements OrderService { Autowired private HouseMapper houseMapper; Autowired private OrderMapper orderMapper; Autowired private CustomerMapper customerMapper; Transactional(rollbackFor Exception.class) public int createDeal(DealRequest request) { // 1. 更新房源状态 houseMapper.updateStatus(request.getHouseId(), 3); // 2. 插入订单记录 Order order new Order(); order.setOrderNo(OrderNoGenerator.generate()); order.setHouseId(request.getHouseId()); order.setCustomerId(request.getCustomerId()); order.setEmpId(request.getEmpId()); order.setDealPrice(request.getPrice()); order.setStatus(1); orderMapper.insert(order); // 3. 更新客户状态 customerMapper.updateStatus(request.getCustomerId(), 3); // 返回值 return order.getId(); } }这里有个细节我必须提醒Transactional注解默认只针对RuntimeException回滚如果抛出的是受检异常Checked Exception事务默认不会回滚。所以注解上要显式写rollbackFor Exception.class。这个坑我在真实项目里踩过当时是某个底层服务抛了一个自定义受检异常结果事务悄悄提交了库存数据错乱排查了好久。另外把房源状态改为已成交之前还得先检查状态当前是否为在售。不然一个已经被预定的房源被另一个客户成交了就是业务数据错误。加个乐观锁或者CAS式的条件更新update house set status 3 where id ? and status 1受影响行数为0说明状态已被抢占直接提示用户房源状态已变化请刷新后重试。这段逻辑我写在这里是因为90%的同类系统都会漏掉并发问题而真实门店里两个经纪人同时抢一套房子的情况天天都有。4.4 统计报表用一条SQL别用循环首页仪表盘要展示的统计数据一般是总房源数、在售房源数、本月成交订单数、本月成交金额、本月新增客户数。很多人的第一反应是写五个查询方法循环查五遍数据库。但完全可以合并优化。我这样做写一个统计SQL用SUMCOUNT配合CASE WHEN实现单次查询出多个指标。虽然这五个指标来自不同的表但可以分别查询后合并至少把同表的聚合合并在一起-- 房源统计一条SQL出多个指标 select count(*) as total_house, sum(case when status 1 then 1 else 0 end) as sale_house, sum(case when status 3 then 1 else 0 end) as done_house from house;-- 订单月度统计 select count(*) as month_order_count, ifnull(sum(deal_price), 0) as month_order_amount from order where deal_time date_format(now(), %Y-%m-01);在PHP里用ifnullMySQL对应IFNULLSQL Server对应ISNULLPostgreSQL对应COALESCE名字不一样但作用相同。写报表SQL时有空值处理习惯是从第一天就要养成的。5. 系统安全与权限控制不能只写在PPT里的功能安全控制是这类项目里最容易被敷衍的部分但也是答辩评委和面试官最常问的部分。我建议你把这一块做扎实哪怕功能不多只要原理清晰就能拉开差距。5.1 登录态的保持方式Web系统的登录态一般有两种方案Session/Cookie和Token。Session方案是传统后端渲染模式的首选用户登录成功后后端把用户ID和角色存进Session发放一个携带SessionID的Cookie给浏览器后续请求浏览器自动带上。配合拦截器或中间件在进入需要登录的页面之前校验Session是否存在。Token方案更适合前后端分离或移动端场景登录成功后后端签发一个Token可以是JWT或随机字符串前端存储在localStorage或请求头里每次请求手动携带。Token的好处是无状态、适合多端坏处是丢失后只能靠过期时间控制无法主动失效除非做黑名单。对于这套房屋销售管理系统如果你用的是传统后端渲染用Session就够了简单可靠。如果你前后端分离用JWT更合适。两种方案都给一下核心代码。Java Spring Boot的登录拦截器完整思路public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains(/login)) { return true; } HttpSession session request.getSession(); Object loginUser session.getAttribute(loginUser); if (loginUser null) { // 未登录重定向到登录页 response.sendRedirect(/login.html); return false; } return true; } }注册拦截器时要注意放行静态资源css、js、图片等不需要登录就能访问。很多人第一次写拦截器会把静态页面也拦截掉导致登录页的样式全消失。用addPathPatterns(/**)拦截所有请求再用excludePathPatterns(/login, /css/**, /js/**, /images/**)放行这些路径。5.2 登录密码的安全处理密码不能明文存数据库这是底线。我见过有些课程项目直接明文存密码答辩时被评委一眼看穿场面很尴尬。正确做法是哈希存储。PHP的password_hash和password_verify内部使用bcrypt算法自带盐值推荐直接用// 注册/新增员工时 $hashedPassword password_hash($rawPassword, PASSWORD_DEFAULT); // 将$hashedPassword存入数据库 // 登录验证时 $storedHash Db::querySingle(select password from employee where emp_no ?, [$empNo]); if (password_verify($rawPassword, $storedHash)) { // 登录成功 } else { // 密码错误 }Java里可以用Spring Security的BCryptPasswordEncoderPython里可以用werkzeug.security的generate_password_hashC#里可以用BCrypt.Net库。只要遵循单向哈希随机盐的原则就行。5.3 基于角色的权限控制房销售系统的角色就两种管理员和销售。权限控制的粒度做到模块级就够了比如房源管理客户管理订单管理系统设置四个模块管理员全通销售只有前三个模块的读写权限系统设置仅管理员可见。后端实现上可以给每个菜单和接口打上一个权限标识用户登录后把角色信息放进Session在渲染菜单时根据角色动态隐藏。后端接口再做一层校验比如销售角色访问管理员接口时直接返回无权限。虽然有些重复但前端隐藏只是体验问题后端校验才是安全兜底。永远不要相信前端传过来的角色信息角色必须由后端从Session或Token里解析而不是从请求参数里读取。6. 我实践过程中遇到的实际问题与解决过程这一节聊几个我真正踩过的坑这些坑大概率你也会遇到。6.1 中文数据库乱码的根源刚把系统从本机迁移到服务器时房源标题里的中文全部变成问号。这个问题出现过很多次根源通常是三个地方不一致数据库编码、数据表编码、连接字符集。MySQL里正确的统一方式-- 建库时指定utf8mb4 create database house_sale default character set utf8mb4 collate utf8mb4_unicode_ci; -- 建表时继承数据库编码 -- 连接参数里加上字符集PHP PDO示例 new PDO(mysql:hostlocalhost;dbnamehouse_sale;charsetutf8mb4, $user, $pass);Java JDBC的连接URL要加useUnicodetruecharacterEncodingutf8Python MySQL连接器要加charsetutf8mb4。三个地方缺一不可。另外注意MySQL的utf8字符集实际上只是utf8mb3不支持emoji和一些生僻汉字强烈建议直接上utf8mb4。6.2 列表页搜索条件重置一个容易被忽略的交互细节这个问题的场景用户在列表页输入了小区名朝阳并搜索列表正常显示结果。然后用户点了分页第2页URL上还是带着search参数没问题。但用户如果直接点菜单里的客户管理再切回房源管理问题来了——搜索条件可能还残留在URL参数里页面打开就是搜索后的结果而不是全部数据。处理方法有两种一是菜单跳转时清空URL参数二是页面加载时从URL读取参数初始化搜索框这个方案我采用了因为用户刷新页面时搜索条件还在体验更顺。具体做法是页面初始化时解析URL参数填入搜索框的值再触发表格重载。6.3 时间字段的前后端格式约定还有一次我遇到的问题列表页显示带看时间数据库里存的是datetime类型ORM映射后返回给前端的是一个类似2025-01-15T14:30:00.00000:00的ISO格式字符串前端直接显示用户看到的时间比实际少了8小时。排查后确认是时区问题。解决方案很明确后端在序列化时统一指定时区为Asia/Shanghai并且日期格式统一用yyyy-MM-dd HH:mm:ss。Java的Jackson配置spring.jackson.date-formatyyyy-MM-dd HH:mm:ss spring.jackson.time-zoneGMT8PHP的话如果你用PDO查询的是原始字符串不会有时区问题但如果你用ORM框架且框架配置了UTC时区同样会踩坑。通用原则数据库连接和应用时区保持一致接口输出前统一格式化前端不做二次时区转换。6.4 图片上传和房源相册的实现建议房源带照片是刚需。这个功能的实现方案很成熟前端用文件选择框后端接收文件后保存到服务器指定目录如/upload/house/数据库里存文件的相对路径或URL展示时拼接完整地址。有几个细节要注意保存文件的目录要按月份分子目录如/upload/house/202501/方便后续清理管理文件名不能用原始文件名要重命名成时间戳随机串避免中文文件名和路径遍历攻击文件大小要限制我一般限制单张2MB以内类型要白名单校验只允许jpg、png、webp上传接口同样需要登录拦截防止未授权用户往服务器传文件Java实现文件上传时Spring Boot的MultipartFile接口很成熟。PHP里最需要注意move_uploaded_file之前要检查is_uploaded_file和错误码防止文件没上传成功却被当作成功处理。Python Flask的file.save方法同理也要先做文件类型检查。7. 技术栈选型对比Java、PHP、Python、C#到底改选哪个这个问题被问得最多。我看到太多人选定技术栈的时候不是基于项目需求而是基于哪个流行哪个看起来高大上结果自己做的时候苦不堪言。我做了一张对比表帮你建立直觉对比维度Java Spring BootPHP ThinkPHPPython Flask/DjangoC# ASP.NET Core开发效率中等高高中等学习曲线较陡平缓平缓中等部署成本中需JRE低LAMP直接跑中中生态丰富度极高高高高典型应用场景企业级系统中小型Web数据分析Web企业级Windows生态就业市场量最大大大大找参考资料难度极多多多较多我的建议分三种情况如果这是毕业设计你最熟悉哪门语言就用哪门别在技术选型上冒险创新。评委看的是你把一个业务做完善的能力不是炫技。如果这是求职作品集Java Spring Boot的含金量在传统互联网和国企里依然最高值得花时间啃。PHP适合快速出活但简历上不如Java醒目Python更适合你准备转数据分析方向的情况。如果这是门店真实要用的工具PHP MySQL Layui是部署最快、运维成本最低的选择。随便一台虚拟主机就能跑不用配置复杂的容器环境出了问题一个小白也能按教程修。有一点我想单独强调语言只是工具这套系统的核心是业务逻辑。你把这个业务逻辑用Java想透了换到Python只是把SQL改写一下、把框架的注解换成装饰器本质完全一样。很多人在选型上浪费了两三周这是完全没有必要的。8. 从零到一完整跑通一份可直接参考的操作清单到这里我想把整个开发过程压缩成一份操作清单方便你照着执行。无论什么技术栈都可以这样推进。8.1 阶段一环境准备与项目初始化第一步安装所选语言的运行环境与数据库。Java装JDK 8和MavenPHP装PHP 7.4和ComposerPython装Python 3.9和pipC#装.NET 6 SDK。数据库我推荐MySQL 5.7或8.0安装简单资料多。第二步初始化项目骨架。Spring Boot可以用Spring Initializr生成PHP可以用ThinkPHP的composer create-project命令Python用Flask的话手动创建app.py和templates目录即可C#用dotnet new mvc命令。第三步配置数据库连接。创建数据库house_sale执行建表SQL我前面给的那套表结构可以直接用。8.2 阶段二核心功能开发顺序我建议按这个顺序开发每个阶段都可独立测试登录功能先打通数据库查询员工表和密码验证这是所有页面的前提。房源管理完成列表展示、分页、新增、编辑、删除、搜索。客户管理功能点与房源管理对称可以复制前者的代码结构快速完成。带看记录核心是创建带看时同时更新客户状态和房源状态。订单管理实现成交业务注意事务操作。回款管理实现收款记录的增删改查订单状态随累计收款金额自动变更。统计报表首页仪表盘的数据查询接口、图表展示。权限控制登录拦截、角色鉴权、密码加密。这个顺序的核心理念是先做地基再做楼层——无登录态的增删改查先跑通再套上权限外壳。没做完中间业务就去做权限控制会不停地把登录验证代码复制到各个Controller里重复劳动且容易遗漏。8.3 阶段三测试与部署功能开发完后至少要过一遍这些测试场景登录失败密码错误是否给出友好提示未登录直接访问业务页是否被拦截新增房源字段为空时是否有提示删除被引用房源是否被阻止或提示并发成交同一房源时是否会重复下单分页搜索组合后数据是否准确手机端浏览器打开页面布局是否错位部署到云服务器时我习惯用宝塔面板管Nginx和MySQL日志查看和伪静态配置都比较方便。Java项目打成jar包扔到服务器用nohup java -jar xxx.jar log.out 21 启动PHP项目直接把代码放到站点目录里配好伪静态规则即可。9. 我从这个项目里总结出的通用开发方法论这个项目做完我最大的收获不只是学会了几个框架而是积累了一套做业务系统的通用方法论。分享三个我觉得最值钱的思考第一个思考永远先画清楚业务流程再写代码。系统越复杂前期梳理的价值越大。用思维导图或者简单的Excel表把实体、关系、状态列明白后面写代码就跟抄作业一样顺畅。反之不画图直接编码的结果是反复返工。第二个思考保持简单是第一原则。功能能简单做就不要复杂做。比如权限控制做模块级而不是数据级一个门店的销售不需要精确到按钮级别的权限控制。过度设计会让项目延期也会让你在答辩时被问到自己都答不上来的细节。第三个思考数据结构和接口设计决定了大半个系统的质量。页面可以丑一点但是表结构如果设计错了后面改起来就是牵一发动全身。我见过一个系统把客户姓名、电话都塞在备注字段里看起来省事实际上完全失去了结构化查询的能力。这个系统的全部价值就在于数据被合理组织了而不是在于页面多好看。现在这套系统的原型思路已经完全展开了。你可以直接照着我给的六张表和功能清单动手先跑通一个简单版本再逐步加功能。实际做的时候如果遇到具体的报错或者某个模块不知道怎么写欢迎带着你的代码和报错信息来讨论这类业务系统的问题大部分都是比较典型的只要定位准确解决起来其实不慢。