遇到过不少做房地产营销策划宣传网站的同学上来就问同一个问题既然项目题目里同时写了Java和Python是不是必须把SSM和Flask两套后端硬塞进一个系统这是个好问题也是这个项目最有意思的地方。我当初拿到这个题目时也纠结了很久后来把它做完整之后才发现SSM和Flask同时出现并不是技术堆砌而是各有分工——SSM负责核心业务和运营后台Flask负责数据清洗、统计报表这些Python更顺手的活。这篇内容就是基于我自己完整开发这个项目的经验整理出来的从架构设计、数据库建模、核心代码实现到联调排错、论文和调试文档怎么写尽量把能复用的部分都讲透。适合正在做同类题目、或者想学SSM和Flask混合开发的朋友参考。1. 为什么我最终用SSMFlask两套后台来做营销宣传网站很多第一次接触这个题目的同学看到“SSMFlask”就会下意识想把所有功能都塞进同一套代码里或者干脆做成两个完全独立的系统。这两种思路都有问题。前者会导致代码结构混乱后者会造成业务数据割裂。我最后采用的方案是SSM负责Web主业务Flask负责数据计算和辅助接口两者通过HTTP接口通信共用一个MySQL数据库。1.1 先讲清楚分工SSM管运营主流程Flask管数据与统计房地产营销策划宣传网站的业务主体说到底就是三件事楼盘信息展示、营销活动运营、客户咨询线索收集。这三件事需要完整的增删改查、登录权限、后台管理是典型的“管理系统”场景用SSM这一套Java技术栈再顺手不过了——Spring管理对象、SpringMVC处理请求、MyBatis操作数据库分工明确代码组织也清晰。那Flask在其中扮演什么角色我实际开发中发现营销网站有一个很常见的需求统计各楼盘的浏览量、咨询量、活动报名量生成周报月报甚至导出Excel给运营人员。这类需求如果用Java写不是不能做但代码会比较啰嗦尤其是做数据分析、格式化报表、表格导出时。Python的Flask配合pandas、openpyxl这些库几十行代码就能搞定一件事。另外如果项目里还有房源数据同步、导入清洗的工作Python的处理能力也明显比Java写起来轻松。所以最终架构是这样的模块技术栈职责范围主后台与前台展示Spring SpringMVC MyBatis用户登录、楼盘管理、活动管理、宣传语管理、线索管理、后台权限数据处理模块Flask 2.x营销数据统计、Excel导出、数据导入清洗、辅助报表API数据库MySQL 5.7/8.0统一存储所有业务数据前端Bootstrap jQuery JSP用户端页面与后台管理页面1.2 一次完整请求在双框架下是怎么被处理的拿“营销周报导出”这个功能来举例比较直观。运营人员在后台点“导出本周各楼盘咨询量统计”这个请求先到SSM的ControllerController判断当前用户是否有权限有权限的话并不直接去数据库里查而是调用Flask暴露的统计接口。Flask收到请求后从MySQL里读取本周的浏览记录和咨询记录用pandas做聚合统计生成Excel文件把文件地址或二进制流返回给SSM。SSM再把这部分数据封装成统一的响应格式返回给前端前端触发下载。这样做的好处是业务主流程全在SSM里权限控制和事务管理有保证而统计计算的代码全部收敛在Flask里后续要改报表逻辑只动Python不影响主系统。项目里如果把所有代码都放一起最后调试的时候会非常痛苦。这也算是我踩过坑之后才明白的——很多项目看着技术栈多实际上只要把边界划清楚开发效率反而更高。1.3 这套组合适合哪些人和场景如果只做普通的官网展示一个SSM完全够用没必要引入Flask。但如果题目明确写了“SSMFlask”或者你希望在项目里体现更多技术亮点那这个组合就非常有价值。它在答辩时特别有用老师问“为什么用Flask”你可以明确回答“利用Python在数据分析上的生态优势实现营销数据的快速处理与报表导出降低Java侧的代码复杂度”。这个回答既体现了技术判断力也说明了架构设计的合理性。我建议的适用场景包括课程设计或毕业设计题目本身要求两种后端框架结合。项目需要周期性生成营销报表、数据导入等辅助功能。希望丰富简历或作品集展示跨语言协作能力。2. 营销官网的功能地图前台做体验后台做运营这个项目名字看起来很长实际上核心功能模块并不复杂。我把功能归纳成前台展示和后台运营两大块每块再往下拆整体结构非常清晰。2.1 前台楼盘展示、活动专题、预约咨询的转化路径前台是给访客看的也是营销的基础。访客打开网站后最核心的动作是“看楼盘”和“留线索”。楼盘展示模块需要支持按区域、价格、户型状态筛选楼盘详情页要展示基本信息面积、户型、均价、开盘时间、开发商等、楼盘图片和营销活动入口。这里有一个容易被忽略的点楼盘的“首页推荐位”。营销网站和普通信息网站不一样运营人员需要手动控制哪些楼盘置顶、哪些楼盘打“热销”标签所以数据库里必须有推荐位和标签字段后台也要有对应配置入口。活动专题模块是营销网站的特色功能。一个楼盘开盘、一次节日促销都需要专题页面来承载。我在设计时没有让活动做成独立的静态页面而是做成“活动内容模板后台录入”运营人员在后台编辑活动标题、宣传语、活动时间、报名截止时间前端专题页自动展示。这样运营人员改一场活动的宣传语几分钟就能完成不需要开发介入。预约咨询模块其实就是线索入口。访客在楼盘详情页填写姓名、电话、意向楼盘点击提交这条数据直接进入线索表。这里要注意做好前端校验手机号格式、必填项和后端校验双重保障防止垃圾数据刷爆线索表。2.2 后台营销活动、宣传语、线索管理的工作流后台是本项目工作量最大的部分。管理员登录后进入运营后台主要功能如下楼盘管理楼盘信息的增删改查、上下架、首页推荐位设置。活动管理创建营销活动、编辑活动文案和宣传语、查看报名人数。宣传语管理这是标题里“网站宣传语”对应的模块。我实现了一个独立的宣传语配置包括首页Banner文案、活动口号、推广标语运营人员可以随时修改前端立即生效。线索管理查看访客提交的购房意向支持按楼盘、时间段筛选标记线索状态待跟进、已联系、已成交。数据统计调用Flask提供的报表接口按日/周/月查看楼盘浏览量、咨询量、线索转化率。管理员管理添加或禁用运营账号分配角色权限。后台页面我用的Bootstrap jQuery和SSM的JSP页面搭配开发起来快页面也不难看。如果你想让后台更专业也可以集成AdminLTE模板网上有大量现成资源直接改布局就行。2.3 角色与权限超级管理员和运营专员能干什么权限设计如果太复杂对于这个体量的项目完全是负担。我最多做了两个角色足够覆盖场景角色权限范围超级管理员所有后台功能含管理员账号管理、数据统计导出运营专员楼盘管理、活动管理、宣传语管理、线索查看与跟进实现方案是每个管理员用户有role字段后台统一用SpringMVC拦截器校验角色只有超级管理员才能访问账号管理相关的URL。这个设计写进论文里也很好交代不用刻意扩展更多角色。3. 数据库设计里决定成败的三张核心表这个项目的表数量建议控制在8-10张既能覆盖功能又不会让论文显得冗长。我最初设计时列了十几张表后来发现很多表可以合并。核心的三张表是房源表house、活动表activity、线索表lead。它们直接决定了系统的稳定性。3.1 整体表结构几张表和它们之间的关系我最终的数据库表清单如下admin_user后台管理员账号house楼盘房源信息house_type楼盘户型一对多activity营销活动lead客户咨询线索news新闻公告banner首页Banner/宣传语配置sys_log操作日志可选house表和activity表通过中间关系绑定即一个活动可以关联多个楼盘一个楼盘可以参加多个活动。为了简单我直接在设计活动表时加了house_ids字段存逗号分隔的ID字符串查询活动时再解析。这种反规范化设计在这个场景下完全够用省去了中间表对毕设项目来说是合理取舍。lead表通过house_id关联意向楼盘通过activity_id来标记用户是从哪场活动进来的。3.2 house表楼盘信息的字段设计细节楼盘表是最核心的表字段直接决定前台展示效果。我列出实际使用的关键字段CREATE TABLE house ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 楼盘名称, district VARCHAR(50) COMMENT 区域, address VARCHAR(200) COMMENT 详细地址, price DECIMAL(10,2) COMMENT 均价(元/平), area_min DECIMAL(10,2) COMMENT 最小面积, area_max DECIMAL(10,2) COMMENT 最大面积, house_type VARCHAR(200) COMMENT 户型简介, developer VARCHAR(100) COMMENT 开发商, sale_status TINYINT COMMENT 销售状态 1在售 2待售 3售罄, is_recommend TINYINT DEFAULT 0 COMMENT 是否首页推荐, tags VARCHAR(100) COMMENT 标签,多值逗号分隔, cover_image VARCHAR(200) COMMENT 封面图, detail TEXT COMMENT 楼盘详情, create_time DATETIME, update_time DATETIME );这里有两个细节值得注意。第一个是价格字段用DECIMAL而不是FLOAT避免浮点误差这在涉及金额统计时非常关键。第二个是tags和recommend字段当初做前台筛选和推荐位展示全都靠这两个字段如果没有它们首页就只能按创建时间排序营销属性就体现不出来。前台展示详情时我会把户型列表从house_type表里单独查出来避免都塞在一条字段里导致前端解析困难。3.3 lead表从线索到成交的闭环设计lead表的设计特别能体现对业务的理解。访客留下购房意向后运营人员需要跟进所以线索表不能只存“谁留了什么信息”还要存“跟进到什么阶段了”。CREATE TABLE lead ( id INT PRIMARY KEY AUTO_INCREMENT, house_id INT COMMENT 意向楼盘, activity_id INT COMMENT 来源活动, name VARCHAR(50), phone VARCHAR(20), remark VARCHAR(500) COMMENT 留言, status TINYINT DEFAULT 0 COMMENT 0待跟进 1已联系 2已到访 3已成交, follow_user VARCHAR(50) COMMENT 跟进人, create_time DATETIME, update_time DATETIME );status字段是整个线索管理模块的灵魂。我在后台实现了按状态筛选运营专员打开线索列表先看“待跟进”的处理完一条就更新状态实现了简单的销售漏斗。论文里把这个过程描述为“线索全生命周期管理”非常有内容可写。数据统计里最常用的“转化率”就是拿status1的线索数除以总线索数算出来的Flask报表接口直接读这张表就够用。需要注意的是lead表必须建索引。电话、状态字段是高频查询条件我加了组合索引status, create_time在数据量几百上千条的规模下差别不明显但这是良好的建表习惯也方便论文里写“数据库优化”。4. SSM主后台的几个关键实现点SSM这套技术栈本身已经很成熟网上各种教程都有我不打算流水账讲一遍。我只挑三个真正影响开发体验的地方来说这三个点也是我实际调试时耗时间最多的位置。4.1 SpringMVC的请求流转与统一响应项目里的接口风格我统一采用的是JSON数据交互而页面跳转交给Controller返回视图名。后台管理页面里所有列表数据全部走Ajax请求前端拿到JSON后渲染表格。为了让前后端协作简单我封装了一个统一响应类public class ResultT { private Integer code; // 200成功 private String msg; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.code 200; r.msg success; r.data data; return r; } // fail方法略 }所有Controller都返回Result对象前端统一判断code。这样做的好处是调试接口时非常直观任何异常都能通过msg快速定位。如果没有这层统一封装后期每个接口都要写try-catch返回不同格式联调会非常痛苦。4.2 MyBatis动态SQL在筛选房源时的应用楼盘的按条件筛选查询是前台最常被调用的接口没有动态SQL的话你要写一堆if拼字符串代码又长又容易出错。MyBatis的xml配置天然适合干这个活select idqueryHousePage parameterTypemap resultTypeHouse SELECT * FROM house where if testdistrict ! null and district ! AND district #{district} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if if testsaleStatus ! null AND sale_status #{saleStatus} /if if testisRecommend ! null AND is_recommend #{isRecommend} /if /where ORDER BY is_recommend DESC, create_time DESC LIMIT #{offset}, #{pageSize} /select where 标签加 if 组合的写法会自动去掉多余的AND这在动态条件查询里是最实用的一招。前台首页推荐楼盘列表和后台筛选列表共用同一个Mapper方法只是参数不同代码复用率很高。有一点要提醒价格区间的minPrice、maxPrice参数传到SQL之前Java侧需要做好类型转换和空值判断否则前端传空字符串给MyBatis时会报NumberFormatException。我实际开发时在这个问题上卡过一下午。4.3 登录拦截器与权限校验的正确写法后台所有以/admin开头的请求都需要拦截校验session中是否有登录用户。我用了SpringMVC的HandlerInterceptor实现public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); Object user session.getAttribute(adminUser); if (user null) { // Ajax请求返回JSON页面跳转重定向到登录页 response.sendRedirect(/admin/login); return false; } return true; } }在spring-mvc.xml里注册拦截器并配置排除登录页、静态资源路径mvc:interceptors mvc:interceptor mvc:mapping path/admin/**/ mvc:exclude-mappings mvc:mapping path/admin/login/ mvc:mapping path/admin/css/**/ mvc:mapping path/admin/js/**/ mvc:mapping path/admin/images/**/ /mvc:exclude-mappings bean classcom.demo.interceptor.LoginInterceptor/ /mvc:interceptor /mvc:interceptors权限校验的要点在于静态资源一定要排除不然CSS和JS加载会被拦截页面样式全丢。这个问题在项目调试里非常典型我遇到过不止一次。5. Flask模块在项目里做的三件“顺手”的事很多同学对SSM和Flask的结合方式感到困惑。我的经验是不要试图用Flask重写SSM的功能只让它做Python顺手的辅助任务。这个项目里Flask被用来做三件事数据清洗与导入、营销统计报表、辅助接口对接。5.1 房源数据的清洗与导入房地产营销网站的数据来源通常是运营商提供的Excel表格或者手工录入。如果全让运营在后台一个个录效率太低了。我写了一个基于Flask的数据导入接口运营在后台页面点击上传Excel请求转发到FlaskFlask解析文件后把合法数据写入house表同时返回导入成功的记录数和失败原因。from flask import Flask, request, jsonify import pandas as pd app Flask(__name__) app.route(/api/data/import_house, methods[POST]) def import_house(): file request.files.get(file) df pd.read_excel(file) success_count 0 for _, row in df.iterrows(): try: # 数据校验与入库逻辑 save_house(row) success_count 1 except Exception as e: log_error(row, str(e)) return jsonify({code: 200, successCount: success_count})这个功能最大的价值在于答辩时可以演示“批量导入50条楼盘数据”效果比一条条手工录入直观得多。实际代码只有几十行性价比极高。5.2 营销报表的统计与导出报表统计是这个模块另一个核心功能。SSM后台里只展示统计结果具体计算放到Flask里。我实现了一个按时间范围统计各楼盘咨询量的接口app.route(/api/stats/lead_by_house, methods[GET]) def lead_by_house(): start request.args.get(start) end request.args.get(end) sql SELECT house_id, COUNT(*) as cnt FROM lead WHERE create_time BETWEEN %s AND %s GROUP BY house_id data query_db(sql, (start, end)) return jsonify({code: 200, data: data})如果需要导出Excel就把同样的数据用openpyxl写入文件再把文件路径返给前端触发下载。整套逻辑我把SQL查询和数据处理放在一起代码保持在几十行维护成本很低。这里有一个经验SSM和Flask之间的日期参数最好统一用yyyy-MM-dd的字符串格式不要混用时间戳不然边界日期统计会出问题。5.3 和SSM的HTTP接口对接细节SSM怎么调用Flask接口我在Java侧用的工具是Spring的RestTemplate。项目里封装了一个简单的HttpClientUtil统一配置Flask服务的地址和连接超时RestTemplate restTemplate new RestTemplate(); String url http://localhost:5000/api/stats/lead_by_house?start start end end; Map result restTemplate.getForObject(url, Map.class);这里有几个坑必须提前说端口固定写成了5000实际部署时Flask监听的地址要跟Java侧配置保持一致。Java侧拿到Flask返回的JSON后要用Map或对应的DTO去承接不要直接拿String解析否则代码写起来很别扭。如果Flask服务没启动Java侧调用会直接报连接超时需要在代码里捕获异常并给前端一个友好提示不能让后台页面直接白屏。我最后选择把Flask的地址配置在Spring的properties文件里而不是硬编码这样部署时可以随时改不用重新编译Java代码。6. 联调与调试我踩过的最深的五个坑整个项目开发中真正让我花时间去解决的不是功能实现本身而是两套服务联调时的各种“意外”。下面这五个坑几乎每个做SSMFlask混合项目的同学都会遇到我直接按排查链路写下来希望对你有用。6.1 端口冲突与跨域问题SSM项目通常跑在Tomcat的8080端口Flask默认跑在5000端口。如果两个服务都启动在同机第一个要确认的是端口没有被占用。我遇到过一次Tomcat启动失败因为本机其他程序占了8080最后把Tomcat端口改成8081解决的。Flask那边的调试还有更隐蔽的问题就是Flask自带的5000端口在某些系统中会被AirPlay接收服务占用导致Flask启动时报Address already in use。跨域问题则出现在前端页面直接通过Ajax调用Flask接口的场景。因为页面的域名是localhost:8080Flask接口是localhost:5000两者端口不同浏览器默认会拦截。我在Flask侧加了CORS支持from flask_cors import CORS CORS(app)如果你选择让SSM后端统一转发Flask请求像我上面说的用RestTemplate前端就不涉及跨域这也是一种更安全的方案。6.2 JSON日期格式引发的BugJava后端返回的日期格式默认是Mon Jun 03 10:30:00 CST 2024前端拿到之后如果不处理直接显示在表格里非常别扭。Flask返回的日期格式是2024-06-03两套服务的格式差异在联调时会让你一头雾水。我在Java侧给所有日期字段加了统一格式配置JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private Date createTime;Flask侧则在返回前统一转成字符串row[create_time] row[create_time].strftime(%Y-%m-%d %H:%M:%S)这样两边的输出格式保持一致前后端渲染就不容易出现null或者格式错乱。这个细节虽然小但影响所有列表和详情的展示效果。6.3 数据库连接池与中文字符集SSM的MyBatis配置里如果jdbc连接串没加characterEncodingutf8数据库里所有中文都会变成问号。这个问题非常经典我后面在调试文档里专门写了一页强调。jdbc:mysql://localhost:3306/house_sale?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai另外如果项目中既有SSM又有Flask连接同一个MySQL两边都使用相同的字符集配置不然Flask写入的中文在Java侧读出乱码排查起来费时费力。我建议在项目一开始就把数据库、连接串、页面编码全部统一为UTF-8。6.4 前端静态资源的访问路径这个坑在SpringMVC配置中非常不起眼但破坏力很大。页面里引用CSS和JS使用相对路径时如果URL带有多级路径比如/admin/house/list浏览器解析相对路径的方法可能和预期不一致导致CSS加载404。我的解决方案是使用JSP的上下文路径link relstylesheet href${pageContext.request.contextPath}/admin/css/bootstrap.min.css所有静态资源全部带上${pageContext.request.contextPath}前缀杜绝路径歧义问题。这个经验也适合写在调试文档里属于典型“页面样式丢失”的排查方向。6.5 双服务启动顺序与日志排查项目部署时SSM和Flask谁先启动其实没有硬性顺序要求。但如果你在SSM启动时就去调用Flask接口而Flask还没起来初始化逻辑就会失败。我最后在实际部署时固定顺序先启动MySQL再启动Flask最后启动Tomcat。因为SSM启动过程中并不会立刻调用Flask所以这个顺序主要是为了避免演示时手忙脚乱。排错时应养成两个习惯。Flask的调试日志设置成INFO级别启动时能看到每次请求的路径和状态码Java侧我把log4j配置成输出到控制台和文件MyBatis的SQL日志打开任何一条数据查不出来都能从日志里找到原因。7. 论文、调试文档和演示讲解这套项目的“临门一脚”项目的代码能跑起来只是完成了一半。另一半是LW论文和调试文档的写作以及最后现场演示的准备工作。这些文档工作做得好能极大提升项目的完成度。7.1 LW论文的章节架构与写作节奏标题里带了“LW”说明论文是这个项目的重要交付物。论文通常包含摘要、绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结八个部分。其中真正拉开差距的是“需求分析”和“系统实现”两章。需求分析部分要写用例图和用例说明把前台用户、后台运营人员、超级管理员三类角色的操作流程逐条写清楚。这里特别建议把“营销策划”的业务背景写透楼盘展示、营销活动投放、宣传语管理、客户线索跟踪这几个子系统的需求每条需求都要对应一个功能点。系统实现部分不要写流水账而是按“功能模块关键技术点”来组织文字比如楼盘管理模块里讲动态SQL的实现思路线索管理模块里讲状态流转的前后端协作逻辑计算统计模块里讲SSM如何调用Flask接口。写论文最忌从头抄模板。学校的模板只能作为格式参考内容要结合自己实际写的代码。因为答辩的时候老师会看细节代码里有没有对应接口、数据库里有没有对应表一问便知。7.2 调试文档记录哪些内容才有价值调试文档不是把代码复制一遍而是记录“运行环境怎么搭、有哪些步骤、踩过哪些坑、每个坑怎么解决”。我的调试文档固定包含这几块环境配置表JDK版本、Maven版本、Tomcat版本、MySQL版本、Python版本以及每个软件安装时的注意事项。启动步骤创建数据库并导入house_sale.sql → 修改application.properties数据库密码 → 启动Flask服务 → 启动Tomcat → 访问前台和后台地址。初始账号说明超级管理员账号密码、测试用户账号防止现场演示时因为忘记密码卡壳。常见问题排查表端口占用、数据库乱码、静态资源404、Flask接口连接失败每个问题配解决方案。关键接口列表前台楼盘列表接口、登录接口、线索提交接口、统计报表接口写清请求方式和返回示例。调试文档写到这个程度不光是为了应付交付检查更重要的是两周以后你自己回头看这个项目时花十分钟就能把所有环境重新搭起来这种复现能力在答辩和后续维护中非常值钱。7.3 现场演示前必做的三轮自测演示出问题是最尴尬的所以我在正式演示前一定会做三轮自测第一轮测主流程。从网站首页开始打开楼盘列表、点击一个楼盘详情、填写预约咨询、提交成功然后切到后台登录、查看这条线索、修改状态为已联系完整走一遍业务闭环。这一轮能发现八成以上的问题。第二轮测特殊功能。轮流点开后台的报表页面确认Flask接口返回的数据能正常展示试一下宣传语修改刷新前台确认生效。跨服务的功能一定要在不同时间多测几次因为这种功能最容易在演示现场出状况。第三轮测环境切换。把数据库清空重启一次从头开始跑环境确认部署文档里的步骤无误。很多同学只在开发环境跑顺了换一台电脑部署时连数据库都连不上所以这一轮必须做。答辩环节还有一个加分项准备一两张架构图和数据流图简单画出用户访问请求在SSM和Flask之间的流转过程。讲解时直接讲图的顺序比现场翻代码清晰得多。这个项目做到这里本质上的技术路线已经完整了。我个人最大的体会是SSM和Flask的混合项目真正的难点不在“会不会两个框架”而在“能不能界定清楚两边的边界”。边界清楚了开发、调试、写论文都会顺很多。如果你刚好也在动手做这个项目建议先花半天把分工和表结构定下来再动手写代码后面你会感谢当时的这个决定。