最近有朋友问我有没有适合毕业设计和练手的 Web 项目，我第一个想到的就是房屋销售管理系统。原因很简单：它麻雀虽小五脏俱全，既有典型的增删改查，又有房源、客户、跟进、预约、成交这条完整业务链，还牵扯权限、图片上传、数据统计这些面试官最爱问的点。这套系统的核心不是技术难度，而是业务流程怎么在数据库和页面上串成一条线。

我前后搭过 Java 和 PHP 两个版本，也用 Python 重写过一个简化版，C# 那边也看过不少同行的实现思路，发现底层逻辑大差不差。无论你用 Spring Boot、ThinkPHP、Django 还是 ASP.NET Core，都能做，区别只在开发效率和答辩时的表达侧重点。所以这篇基于 Web 的房屋销售管理系统的设计和实现，我会从需求拆解、数据库设计、后端接口、前端页面、部署排错五个方面完整讲透，Java、PHP、Python、C# 四条技术路线都能参考。

这类系统最适合谁？毕业设计、课程设计、转行找工作练手，甚至小中介门店内部试用都没问题。你不需要会微服务、不需要会消息队列，只要把 CRUD 写扎实、把状态流转想清楚、把权限和统计做好，就已经超过绝大多数同类作品了。

1. 整体设计与技术选型：先搞清楚业务再动手写代码

1.1 业务角色与核心模块拆解

很多初学者拿到题目就急着建表，我见过不止一个人先写用户表，写完之后才发现业务角色没理清，后面对不齐需求又反复改。正规做法是先画业务角色图和核心流程图。

这套系统的角色一般分三类。管理员管后台，负责维护用户账号、角色权限、数据字典，偶尔处理一些异常订单和房源上下架审核；销售顾问是核心使用者，日常操作是录入房源、新增客户、写跟进记录、安排看房、登记合同；管理层或者老板只看统计报表，关心成交量、成交额、各个区域房源去化速度。

对应的功能模块可以拆成七块：

• 房源管理：房源信息的新增、编辑、上下架、带图展示、条件搜索。
• 客户管理：客户信息的录入、分配归属、客户来源统计。
• 跟进记录：每个客户的每一次电话、带看、微信沟通都按时间线追加。
• 预约看房：销售与客户约时间，校验时间和房源的冲突。
• 合同管理：成交登记、合同编号生成、合同状态变化。
• 收款管理：定金、首付、尾款的到账记录。
• 统计报表：按月份、区域、销售顾问维度统计成交量、成交额和房源去化。

这个模块设计带来的好处很明显：每一个模块之间都有外键关联和状态联动，天然覆盖了“一对多”“多对一”关系，你的数据库设计有东西可以讲；同时每个模块对前端来说都是一组独立页面，页面数量够了展示效果也丰富。

1.2 四种后端语言怎么选

标题里提到了 Java、PHP、Python、C#，我分别说下适用场景，你自己判断。以下是我实操下来的真实感受，不代表绝对标准答案。

• Java（Spring Boot）：资料最多、社区最活跃，面试认可度最高。缺点是写起来重，实体类、Mapper、Service、Controller 一堆文件，开发速度慢一些。适合答辩的时候往“企业级开发”“项目分层规范”方向讲。
• PHP（ThinkPHP / Laravel）：开发效率是真的高，模型层、验证器、中间件都有现成的，一个控制器写完一整套接口也就一晚上。适合时间紧、想快速跑通全部功能的场景。缺点是面试时容易被追着问“高并发怎么处理”，答案会比较尴尬。
• Python（Django / Flask）：代码量少，逻辑清晰，尤其适合再加一个“房价趋势分析”或“客户画像”的加分功能，用 pandas 做数据聚合比 Java 漂亮得多。Django 自带 Admin 后台，演示管理功能时非常加分。
• C#（ASP.NET Core）：如果你本身在 Windows 环境、用过 Visual Studio，那也完全可以。EF Core 做数据库操作和迁移很顺手，就是部署时如果只是 Windows 服务器，别人跑起来会稍麻烦。

我的建议很直接：如果你只是想要一个稳妥的毕设项目，首选 Spring Boot 或者 PHP；如果你后期想往数据分析方向延伸，选 Python。系统功能逻辑和数据库结构基本是通用的，换语言只是换一层实现方式，所以下面我讲核心设计的时候，会尽量用数据库和接口思路来描述，而不是绑定某一种语言。

1.3 项目结构与开发环境规划

从零开始搭这个项目时，环境规划很重要。我常用的组合是：

• 后端：Spring Boot 2.7 + MyBatis-Plus + MySQL 8.0，或者 ThinkPHP 8 + MySQL。
• 前端：Vue 3 + Vite + Element Plus，方便做前后端分离。
• 开发工具：IDEA 或 VS Code，数据库用 Navicat。
• 接口调试：Apifox 或 Postman。

如果你不想搞前后端分离，也可以直接用服务端渲染，比如 PHP 的模板引擎或者 Java 的 Thymeleaf，省去跨域问题，但页面响应速度会差一些，而且答辩时展示效果不如 SPA 流畅。我个人还是推荐 Vue 做前端，因为现在前后端分离已是主流，面试官看到“分离架构”本身就是一个加分项。

项目目录上，后端我习惯这样做分包：

controller/ # 接收请求、参数校验 service/ # 业务逻辑、事务控制 mapper/ # 数据库操作 entity/ # 数据实体 common/ # 统一返回结果、异常处理、工具类 config/ # 拦截器、跨域配置、静态资源配置

这个结构本身也是答辩时介绍系统架构的素材。你在介绍系统时，完全可以这样讲：系统采用经典三层架构，控制层负责请求分发，业务层处理核心逻辑，持久层访问数据库，通过统一返回对象实现前后端解耦。

2. 数据库设计：把表建对了，后面能少写一半代码

2.1 核心表结构规划与字段说明

数据库设计是整个系统最值得花时间的地方，因为后面所有接口、页面、统计都依赖于表结构。我这个项目最终整理出了八张核心表，再加上一个字典表，基本覆盖全部业务。

用户表字段不复杂，用户名、密码、手机号、角色标识、状态、创建时间。密码不要明文存，用 BCrypt 或 PHP 的 password_hash 加密。客户表要有归属字段 seller_id，这个字段决定销售只能看到自己名下的客户，是后面权限控制的基础。房源表是整个系统的核心，字段我会在下面单独讲。

2.2 状态字段与价格字段的设计细节

这是很多人容易踩坑的地方。首先，价格字段千万不要用 double 或者 float，因为浮点数有精度问题，成交价和定金计算容易出现 0.1 + 0.2 不等于 0.3 的尴尬情况。正确做法是用 decimal(12,2)，比如 5000000.00 就是五百万整，这在 Java 里对应 BigDecimal，PHP 里直接按字符串处理，前端拿到的是字符串，展示和计算都不会丢精度。

状态字段建议用整数或短字符串，并且要有一套统一的语义。我当时为房源设计了四状态：1 在售、2 预订、3 已售、4 下架。客户状态也设计了四个：1 潜在客户、2 跟进中、3 已成交、4 已流失。合同状态是：1 待签约、2 已签约、3 已完成、4 已取消。

为什么要专门设计状态？因为业务关联性强。比如房源被预约后，销售可能会把它置为“预订”状态，这时其他销售在列表里就看不到了；一旦合同签订，房源状态要更新为“已售”，后续任何编辑操作都要禁止。这些状态如果散落在代码里写成魔法值，后面维护非常痛苦，所以必须在代码常量类或字典表里统一管理。

还有两个所有表都建议加的字段：create_time 和 update_time，以及 del_flag（逻辑删除标识）。有了 del_flag，删除操作就变成 UPDATE 而不是 DELETE，数据还在，误删能恢复，统计报表也不会因为物理删除而缺数据。这一点我在答辩和面试时被问过很多次，属于高频加分点。

2.3 建表脚本参考（以 MySQL 为例）

下面给出核心表的简化建表脚本。不用完全抄，重点关注类型选择和索引设计。

CREATE TABLE house ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL, city VARCHAR(20), district VARCHAR(20), address VARCHAR(200), area DECIMAL(8,2) COMMENT '建筑面积', total_price DECIMAL(12,2) COMMENT '总价', unit_price DECIMAL(10,2) COMMENT '单价', room_count INT COMMENT '几室', hall_count INT COMMENT '几厅', toward VARCHAR(10) COMMENT '朝向', decoration VARCHAR(20) COMMENT '装修情况', floor_no INT, total_floor INT, house_status TINYINT DEFAULT 1 COMMENT '1在售 2预订 3已售 4下架', seller_id BIGINT COMMENT '归属销售', description TEXT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, del_flag TINYINT DEFAULT 0, INDEX idx_status_city_price (house_status, city, total_price) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE follow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT NOT NULL, seller_id BIGINT NOT NULL, follow_type VARCHAR(20) COMMENT '电话/微信/带看', content VARCHAR(500), next_plan VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, del_flag TINYINT DEFAULT 0, INDEX idx_customer (customer_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关于外键，很多课程设计喜欢在表上直接加 FOREIGN KEY，我不推荐。原因有两点：一是物理外键在更新、删除时会牵动很多表，后期改数据麻烦；二是线上系统和面试场景里，“逻辑外键 + 应用层保证一致性”反而是更被认可的做法。你只需要在实体配置里标明关联关系，业务代码做校验就够了。

3. 后端核心接口设计与实现要点

3.1 登录认证与权限控制

登录认证是所有系统的第一道门。这里我不推荐在课程项目里用复杂的 Spring Security 全家桶或 Laravel 的完整权限体系，而是建议掌握 JWT 这套东西，又实用又容易讲清楚。

JWT 的原理是后端登录成功后，签发一个携带用户 ID 和角色信息的 JSON Web Token 给前端，前端每次请求放在请求头 Authorization 里，后端用拦截器解析校验，无需在服务端保存 Session。实现流程大概是：

1. 用户提交账号密码。
2. 后端比对密码，成功则生成 token，失效时间建议设 24 小时。
3. 前端把 token 存到 localStorage。
4. 后端写一个拦截器或中间件，统一校验带过来的 token，校验失败返回 401 并提示重新登录。

权限控制怎么实现？最简单但够用的方式是基于角色的菜单权限。admin 登录后能看到“系统管理”菜单，销售顾问登录后看不到。前端根据后端返回的用户角色信息，动态渲染菜单；后端接口再用一个自定义注解或中间件做二次校验，比如只有具备 admin 权限的角色才能调用删除用户的接口。

JWT 相比传统 Session 的好处是无状态、天然适合前后端分离，你用 Vue 调接口不会遇到跨域携带 Cookie 的坑。但有一点要注意：JWT 一旦签发，在过期之前无法主动失效，所以管理员禁用某个账号时要额外加一层状态校验，比如数据库里 user 表的 status 字段，每次请求可以在拦截器里查一次或者用 Redis 做黑名单。

3.2 房源管理接口：分页搜索与图片上传

房源管理是核心中的核心。列表接口必须支持分页和条件搜索，至少包含城市、区域、价格区间、面积、户型、状态、关键词几个条件。接口设计成 GET /api/house/list，前端传过来一堆 query 参数，后端封装一个查询对象接收。

分页是必考知识点。前端只需要传 page 和 size，后端返回 total、records、current、size 四个字段。最好别用 LIMIT 100000,20 这种写法让前端看了无语；用 MyBatis-Plus 的 Page 或者 PHP 的分页类都行。搜索条件里价格区间用 priceMin 和 priceMax 两个参数，底层放到 SQL 的 WHERE 子句里做 between 区间过滤，注意两个参数都不为空时才拼条件。

图片上传这里我要重点说。最坑的做法是把图片转成 base64 字符串直接存进数据库，因为一张 2MB 的图片转成 base64 后可能变成 3MB，查列表接口一次返回几十条数据，响应能慢到怀疑人生。正确定位是：前端把图片文件通过 multipart/form-data 提交到 /api/file/upload 接口，后端把文件保存到本地磁盘目录，数据库里只存相对路径，比如 /upload/20240901/xxx.jpg。

这个方案还有一个好处：部署上线时可以让 Nginx 直接托管 upload 静态目录，图片请求完全不经过后端，性能要好很多。这个我放到后面部署部分再细说。编辑删接口要关注状态：已售和预订状态的房源，常规编辑建议加校验；删除建议做成逻辑删除，只改 del_flag。

3.3 跟进记录与看房预约的时序设计

跟进记录这个模块很重要，但实现很简单，它属于一对多追加式记录。核心设计原则是：客户详情页看跟进记录，永远按时间倒序排列，每条记录包含跟进方式、沟通内容、下次计划。销售每次新增跟进，客户状态应该同步更新。

潜在风险是并发写入问题，不过一般毕设系统并发量不大，给 customer_id 加索引就够了。要注意的是，跟进记录只能追加，不能覆盖，否则销售写错内容就会把之前的记录弄没，业务上不允许。

看房预约是逻辑稍微复杂一点的模块。设计上至少要考虑三件事：

• 同一个房源同一时间段不能被重复预约。
• 同一个客户同一时间段也不能有两条预约。
• 预约通过后房源状态应变为预订。

实现冲突校验时，SQL 大致是查 visit_appointment 表里是否存在 target_date 相同、time_slot 有交集、且 state 为有效预约的数据。前端的日期选择器可以精确到小时，后端也要做二次校验，不要信任前端传上来的任何数据。预约的会话状态也分几种：待确认、待看房、已完成、已取消、爽约。

这里我强调一个实操细节：预约时间字段建议拆成预约日期 visit_date 和时段 time_slot 两个字段，不要把“2024-09-01 10:00”整个压进一个 datetime 里。拆开后，做日历视图展示时简单很多。还要在处理预约确认时把房源的 status 改为 2，如果预约取消再改回 1，这些状态变更要统一封装到一个 service 方法里面，避免散落。

3.4 成交合同与数据统计实现

合同模块是业务流程的终点。销售录入合同时，后端要做三件事，而且要放在一个事务里：

1. 生成合同编号，格式类似 C20240901001，前缀 C + 日期 + 三位流水号。
2. 更新合同表，写入客户、房源、成交价、签约时间、付款方式。
3. 更新房源状态为已售，更新客户状态为已成交。

这三步只要有一个失败，全部回滚。Java 里在 service 方法上加 @Transactional 注解，PHP 里用 DB::transaction 包裹，Python 里用 context manager 或者 Django 的 transaction.atomic。为回答“为什么用事务”，最典型的场景就是：合同写入成功，但房源状态更新失败，结果系统里同一套房被卖了两回，这在真实业务里是重大事故。

收款记录是合同的一对多子表。首付、尾款分开登记，每笔记录含项目金额、收款方式、到账时间。统计报表模块就可以从这个数据基础上去聚合。常用的统计查询大概有三种：

• 按月份统计成交套数和成交额：GROUP BY MONTH(create_time)。
• 按销售统计业绩：GROUP BY seller_id，关联用户表查出姓名。
• 按房源状态统计去化率：GROUP BY house_status，然后算已售 / 总数。

前端用 ECharts 做折线图和柱状图，后端的统计接口把 List<Map<String,Object>> 直接 return 出去，前端取到之后渲染即可。如果你用 Python，还可以直接把 pandas 的 DataFrame 转成 JSON 返回，效果更直观。

4. 前端页面与前后端联调的关键细节

4.1 前端技术选型与页面清单

前端这块我依然是推荐 Vue 3 + Element Plus，原因很现实：组件成熟、文档全、页面好看。如果你实在不熟 Vue，用 jQuery + layui 也能做，但整体质感和开发效率差别不小，不建议。

页面清单基本对应后端的七个模块，从路由规划到页面组件，我通常这样安排：

• 登录页：账号密码表单，记住密码优化项。
• 布局页：左侧菜单 + 顶栏 + 内容区，普通后台管理布局。
• 工作台：看板统计，展示今日预约数量、我的客户数、在售房源数。
• 房源管理页：列表、搜索条件、新增编辑弹窗、图片预览。
• 客户管理页：客户列表、客户详情抽屉、跟进记录时间线。
• 预约看房页：预约日历或列表，支持状态操作。
• 合同管理页：合同列表、合同详情、收款记录表。
• 统计报表页：月份成交趋势折线图、销售业绩柱状图、房源状态饼图。

页面数量大概在八到十个，已经足够撑起一次完整的答辩演示。做的时候注意左侧菜单要长成动态的——根据用户角色显示或隐藏，后端登录接口返回一个 roles 字段或者 permissions 数组。这比把菜单写死在前端要有说服力得多。

4.2 接口请求封装与状态码约定

前后端分离项目，如果不约定好返回格式，联调能折磨死人。我后端所有接口统一返回下面这个结构：

{ "code": 200, "msg": "操作成功", "data": {} }

code 为 200 表示成功，400 表示参数错误，401 表示未登录或 token 失效，500 表示服务端异常。前端封装 axios 的时候，用响应拦截器统一处理：请求前把 token 挂到 Authorization 头；响应时判断 code，如果不是 200 就用 Element Plus 的 Message 组件弹出提示；401 时清理本地 token 并跳转登录页。

这个约定一旦定下来，前端写页面就非常快。每个人开发的接口都长一个样子，数据格式统一是 data 字段包裹，不需要每个接口单独写判断逻辑。这里我加一条建议：BigDecimal 类型的价格字段返回给前端时，一定要转成字符串，否则 JavaScript 的 Number 在传大数值时会丢失精度。Java 里可以在实体类的 price 字段上做序列化配置，PHP 和 Python 天然字符串返回，问题不大。

4.3 联调避坑：跨域、日期格式、文件上传

前后端分离最常遇到的问题就是跨域。开发环境最简单的解决方案是 Vue 的 Vite 配置 proxy 代理，把 /api 前缀的请求转发到后端地址，比如 http://localhost:8080，这样浏览器里看到的请求是同源的，不涉及跨域。部署阶段让 Nginx 把前端和后端都通过同一个域名对外，用路径区分即可，也就没有跨域问题了。后端也要在配置里允许前端的来源地址，这个我一般会写全局跨域配置类。

日期格式是一个隐藏坑。MySQL 的 DATETIME 返回给 Java 时默认可能是 2024-09-01T10:00:00。如果你英文不是特别好，还会踩时区坑：MySQL 8 的驱动在链接 URL 里必须加 serverTimezone=Asia/Shanghai，否则查询会报“The server time zone value”相关异常。前端拿到标准格式之后再用 dayjs 或 moment 格式化，统一成 yyyy-MM-dd HH:mm:ss。

文件上传的坑也很经典。开发时 easy，localhost 下图片能显示；运行时一旦打成 jar 包部署，写死的本地盘路径就可能失效。我自己养成的一个好习惯：数据库永远存相对路径，例如 /upload/20240901/xxx.jpg；后端单独写一个静态资源映射，把 upload 目录映射到根路径；部署后让 Nginx 直接托管这个目录。这样无论在本地、服务器还是迁移环境，只要配置一个目录路径就行。

5. 常见问题与排查技巧实录

5.1 打不开、启动失败类问题

先说一个 Java 新手高频问题：IDEA 2024 版本创建 Web 项目时，初始化出来的工程没有 webapp 目录，也没有部署配置。原因是新版本默认推荐 Spring Boot 内嵌容器，不再生成传统 war 结构。解决办法是用 Spring Initializr 创建项目，然后直接加 spring-boot-starter-web 依赖，写一个 Controller 就能启动，不需要手动配置 Tomcat。

端口占用也很常见，启动时报“Port 8080 was already in use”。Windows 下用 netstat -ano | findstr 8080 查 PID，然后在任务管理器里结束进程。PHP 项目常见的问题是 PHP 版本和扩展不匹配，比如 ThinkPHP 8 要求 PHP 8 以上，而有些人本机还是 PHP 7，页面直接白屏。建议用 PHPStudy 或小皮面板统一管理版本。

数据库连接报错是另一个高频问题。除了刚才说的 serverTimezone，还要注意 MySQL 8 和 MySQL 5.7 的驱动类不一样，Spring Boot 2.7 里如果用 mysql:mysql-connector-java 8.x，驱动类是 com.mysql.cj.jdbc.Driver。账号密码要对，库要提前建好，字符集 utf8mb4 不能少。调试时打开 MyBatis-Plus 的 SQL 日志，能直接看到执行了什么 SQL，排查效率翻倍。

5.2 登录失效和数据不一致问题

JWT 登录失效一般发生在两个场景：token 过期，或者后端修改了加密密钥导致之前发的 token 全部失效。排查时先看前端有没有把 token 成功放到请求头，再看后端拦截器有没有正确解析 token。有一种情况是后端返回 401 后前端一直跳登录页，这是处理逻辑写成了“任何 401 都清缓存跳转”，但登录接口本身如果返回 401，就会死循环，要把登录接口排除拦截。

数据不一致问题主要在预约和合同。比如用户提交看房预约时，后端的冲突校验做得不好，导致同一个房源在 10:00 同时被两组客户预约。解决思路是状态校验 + 事务 + 唯一约束三层防护。房源成交时加一条乐观锁更新：

UPDATE house SET house_status = 3 WHERE id = ? AND house_status = 1

如果影响行数为 0，说明这个房源已经不是“在售”状态了，后端直接返回“房源已被售出”，并发问题就解决了。这条 SQL 比任何锁机制都直观，面试时讲出来也是加分项。

5.3 部署上线后的静态资源与数据库连接问题

本地跑得好好的，部署到服务器就 404，多半是静态资源和文件上传路径的问题。我的做法是：后端打包成 jar，放到服务器后用 java -jar 启动，Nginx 监听 80 端口，前端三个路径规则：

• / 和 /api 前缀转发给后端地址。
• /upload 前缀指向服务器上实际的图片存放目录。

这个 Nginx 配置片段我经常复用，给一个基础版参考：

server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /data/house_system/upload/; } location / { root /data/house_system/dist; try_files $uri $uri/ /index.html; } }

数据库连接方面，服务器上的 MySQL 默认可能只允许 localhost 连接，远程工具连不上，要检查 bind-address 和账号授权。生产环境不要用 root 账号连应用数据库，单独建一个业务账号，只授权对应库的增删改查权限，这样也更安全。

6. 后续可扩展方向与个人经验补充

6.1 低成本扩展：地图找房、消息通知、H5 适配

系统做完之后，如果你还想增加亮点，我建议优先做这三个方向。

第一个是地图找房。给 house 表加两个字段 lng 和 lat，接入高德或百度地图的 JavaScript API，在页面上绘制房源标记点，点击弹窗展示房源卡片。这个扩展视觉冲击力强，答辩现场随手一演就很加分，而且技术门槛不高。

第二个是消息通知。预约看房成功之后，给客户手机号发一条短信，或者给销售的企业微信机器人发一条提醒。短信服务需要申请第三方，企业微信机器人只要一个 webhook URL，用后端 HTTP 调用即可，成本几乎为零，但“主动通知”这个设计点比被动等用户刷新页面要高级很多。

第三个是 H5 适配。给移动端做一套轻量页面，客户扫码进来就能看房源列表和预约记录。后端接口可以完全复用，只是前端多一套自适应布局。如果你会一点小程序开发，把 H5 套进小程序的 web-view 里也是常见路数。不过准备毕设的话，H5 就够，不建议这个时候去碰小程序编译环境和审核问题。

6.2 开发这类项目最值得养成的习惯

最后说我个人的体会。做房屋销售管理系统这类项目，真正花时间的不是“页面好看”，而是业务状态流转和数据一致性。预约、合同、房源状态、客户状态，每一个角色操作都会引发一连串变化，你只要有一次忘了把状态同步更新，演示的时候就会露出破绽。

我养成的几个习惯分享给你：

• 所有表都建 create_time、update_time、del_flag 三个基础字段，后面做报表、恢复、迁移都靠它们。
• 枚举值不散落，统一放常量类或数据字典表，代码里出现魔法字符串就顺手改掉。
• 列表查询按时间倒序，新录入的房源、客户、合同永远在最前面，演示效果最合理。
• 每次写接口先定返回结构，然后写文档再写代码。文档即使简单到只有接口名和字段列表，也比写完就忘强。

如果你时间紧张，优先把房源管理、客户管理、合同管理、预约看房这四个模块做完整，统计报表能简单显示几条曲线就够。剩下这些扩展功能，是你主流程稳定之后再考虑的部分。做项目不是把所有功能都堆上去就叫完整，而是把核心链路走通、走到每一个分支状态都对，这比什么都重要。