基于SpringBoot的天气驱动个性化穿着推荐系统设计与实现

做毕设那阵子，我把学院给的题目清单翻来翻去看了三遍，满眼都是“XX管理系统”“XX商城”，改个字段换个包名，本质上是同一个东西。最后我定了这个题目：基于SpringBoot的天气驱动个性化穿着推荐系统。说白了就是做一个能感知实时天气、告诉你“今天该穿什么”的Java应用，后端用SpringBoot这个当前JavaEE生态里最主流的框架，前端配合模板渲染和可视化图表，数据源对接第三方天气接口，再加上一套根据体感温度、天气状况、用户偏好综合打分的推荐逻辑。做完这个项目，我对SpringBoot的开发流程、数据访问层设计、定时任务调度、REST接口设计这些毕业设计考核重点算是彻底通了，关键是答辩时有实打实的业务闭环可以讲。

这篇博文就是整个项目从零到一的完整记录：选题怎么论证、技术怎么选型、天气数据怎么接入、推荐算法怎么设计、数据库怎么建、代码怎么组织，以及调试部署和答辩准备阶段踩过的各种坑。写给正在做SpringBoot毕设的同学，也写给想把“推荐系统”这个概念真正落地到具体场景的Java开发者。

1. 选题价值拆解：为什么“天气+穿搭”值得做成毕业设计

1.1 一个连你自己每天都会用的需求

先别急着打开IDE，把题目本身想清楚再动手，往往比写代码更重要。我做这个选题的第一个判断标准是：这个系统有没有真实的使用场景。天气驱动穿衣推荐这个需求，每个人每天早上出门前都得面对——今天降温了要不要加外套？外面起风了穿什么材质防风？下雨了穿什么类型的鞋？哪怕只是做一个粗糙的原型，只要能把这几个问题答明白，系统就有存在的意义。

这一点在答辩的时候特别好用。评审老师问“你的系统解决了什么问题”，你不需要背概念，只需要打开手机天气截图和系统推荐页面对照，告诉老师：同一套逻辑，今天预报有暴雨，系统推荐了防水面料的冲锋衣和防滑鞋，而不是纯棉外套。这个例子一摆，系统的价值就立住了，比任何功能列表都有说服力。

1.2 难度曲线刚好落在毕业设计的考核区间

第二点，也是更实际的一点：这个题目的技术难度很适合本科毕业设计。

难度太低不行。纯CRUD的管理系统，页面写几个表格，增删改查跑通了就交差，这种项目技术上几乎没有任何挑战，答辩时老师随便追问一个并发问题你就哑火了。难度太高也不行。如果一上来就搞深度学习图像识别穿搭、分布式推荐集群，三年经验都不一定压得住，更何况是几个月内的毕设工期。

天气穿搭推荐这个方向刚好卡在中间：

• SpringBoot本身是Java领域最主流的框架，和标题里的JavaEE定位一致，属于毕业设计里最稳妥的技术选型，简历上也拿得出手；
• 从第三方接口取实时天气数据，涉及HTTP调用、JSON解析、数据缓存，复杂度适中；
• 推荐逻辑不用上机器学习，用规则加加权评分就足以支撑业务闭环，但又比普通的if else多一些设计感；
• 前端需要气温展示、穿搭卡片、历史反馈记录，页面能做出视觉效果，又不需要Vue全家桶那一套重型工程。

这个组合意味着：你有足够的内容去展示技术能力，又不会因为太难而在deadline前翻车。

1.3 和同质化选题拉开差距

第三点是市场竞争层面的。SpringBoot毕设里，最常见的是“XX管理系统”“XX商城”，这类题目每年一大片，答辩现场老师审美疲劳，查重和工作量上都容易被横向比较。而“天气驱动的个性化推荐”至少做出来是能演示的：输入城市，后端自动拉取实时天气，推荐出对应的穿搭组合，页面还会根据天气变化自动切换背景风格。演示效果好，创新点就出来了。

我的体会是，毕设选题本质上是一次“差异化竞争”。技术栈可以大众化（SpringBoot加MySQL，大家都用），但业务切入点要尽量让人眼前一亮。天气加穿搭这个切入点，成本低、演示效果好、还自带话题性，是个性价比很高的选择。

2. 技术选型与项目骨架：SpringBoot版本和依赖怎么定

2.1 版本选择的两个关键原则

这个项目我用的核心组合是 SpringBoot 2.7.x + MyBatis Plus 3.5.x + MySQL 8.0。先说版本，这是很多同学第一步就会踩坑的地方。

SpringBoot现在有两个大版本线在并行迭代：2.7.x 和 3.x。3.x 要求JDK17以上，一些老教程里的写法会失效；2.7.x 是最后一个长期维护的2.x系列，用JDK8就能跑，生态最稳，网上能搜到的资料也最多。对毕业设计来说，我建议优先选2.7.6或者2.7.18，理由很实在：

• 绝大多数学校机房和老师手头环境还是JDK8或JDK11，用SpringBoot 2.x不会遇到环境不兼容；
• 大部分博客、GitHub上现成的SpringBoot项目案例基于2.x，遇到问题能搜到答案；
• 3.x的Jakarta命名空间变化、Spring Security 6配置方式变化，对新手来说都是额外的坑。

如果学校强制要求用SpringBoot 3.x，那也没问题，只是下面所有代码里 javax.* 包名要换成 jakarta.*，接口返回结构也要留意。在项目开始前先用一个空项目把Hello World跑通，确认JDK、Maven、SpringBoot三者之间版本兼容，这一步十分钟的事，能省下后面几十个小时的排错时间。

2.2 依赖清单与项目目录组织

pom.xml里我放了这些核心依赖：

我的项目目录结构大概是这样的：

com.example.dressrecommend ├── controller // 接收请求，返回页面数据和接口JSON ├── service // 业务逻辑：天气拉取、评价打分、推荐生成 ├── mapper // MyBatis Plus的Mapper接口，数据访问层 ├── entity // 实体类：User、WeatherRecord、DressItem、RecommendRecord ├── config // 配置类：定时任务、跨域等 ├── utils // 工具类：温度转换、穿衣指数计算等 └── DressApplication.java // 启动类

分包建议按“职责”而不是按“功能”划分，这样答辩讲架构的时候能讲清楚分层思想：controller只做参数接收和结果返回，service写业务逻辑，mapper只做数据库访问。

2.3 为什么用MyBatis Plus

持久层选型上，我对比过Spring Data JPA和MyBatis Plus。毕设项目里推荐MyBatis Plus的原因很简单：写代码少、出活快、SQL可控。JPA要写Entity之间的关联关系，新手容易把级联查询搞出一堆坑；MyBatis Plus的BaseMapper自带增删改查和分页插件，复杂查询再用 @Select、@Update 注解写SQL，两边结合非常顺手。

还有个细节是 MyBatis Plus 默认生成雪花ID作为主键，但如果习惯用自增主键，需要在实体类主键上加 @TableId(type = IdType.AUTO)，否则你可能发现插入数据后主键是一个超长的数字，而不是从1递增——这个小细节我身边不下三个同学踩过。

3. 天气数据接入：不花一分钱拿到实时天气的完整链路

3.1 API选型与免费额度评估

天气数据是整个系统的“上游水源”，怎么选接口很关键。我对比了和风天气、心知天气、OpenWeatherMap这几个常见的免费接口：

• 和风天气：国内数据全，免费版有每日请求上限，支持实时天气、逐小时预报、生活指数（包括穿衣指数），非常适合这个项目；
• 心知天气：有免费试用包，接口简单，文档对中文友好；
• OpenWeatherMap：国际数据，中文文档少，国内城市的中文名称匹配比较麻烦。

建议优先选择和风天气的开发者平台，尤其是它的“生活指数”接口直接返回“穿衣指数”这种字段，如果你不想自己算，可以直接拿来做推荐依据。当然，为了体现这是你自己设计的推荐逻辑而不是纯调接口，更推荐只拿它的实时天气原始数据（温度、湿度、风速、天气现象），把穿衣推荐的计算留给自己写。

3.2 从HTTP请求到实体类：接口调用全过程

用Hutool的HttpUtil发GET请求，解析JSON，无非三步：配置API Key、拼接URL、把返回结果JSON转成自己的WeatherRecord实体。

我定义了一个天气服务类，核心逻辑大概长这样：

public WeatherRecord fetchWeather(String cityId) { // cityId 是对应城市代码，比如 101010100 是北京 String url = "https://devapi.qweather.com/v7/weather/now?location=" + cityId + "&key=" + apiKey; String resp = HttpUtil.get(url); JSONObject obj = JSONUtil.parseObj(resp); JSONObject now = obj.getJSONObject("now"); WeatherRecord record = new WeatherRecord(); record.setCityCode(cityId); record.setTemp(now.getInt("temp")); record.setFeelsLike(now.getInt("feelsLike")); record.setHumidity(now.getInt("humidity")); record.setWindScale(Integer.parseInt(now.getStr("windScale"))); record.setWeatherText(now.getStr("text")); // 天气现象：晴、多云、小雨等 return record; }

需要注意几个细节：

• 天气API返回的温度单位是摄氏度整数，直接存即可；体感温度字段feelsLike很重要，推荐算法里直接用真实气温会不准，体感温度才是用户体感的核心；
• 如果只按真实气温来推荐，26度和40度湿度80%的闷热天气穿法完全不同，这就是为什么体感温度比实际温度更有参考价值；
• API Key要放在配置文件中用 @ConfigurationProperties 读取，不要硬编码在代码里，一方面方便改，另一方面答辩时也会显得你的代码规范。

3.3 定时任务与缓存：避免把免费流量打爆

天气API免费额度撑不住每访问一次页面就实时请求一次，这里必须做缓存和定时更新。我用SpringBoot自带的 @Scheduled 定时任务，每隔30分钟拉取一次常用城市的天气存入数据库，页面读取时优先查本地库：

@Component public class WeatherScheduledTask { @Scheduled(fixedDelay = 30 * 60 * 1000) // 每30分钟执行一次 public void refreshCityWeather() { // 遍历配置的城市列表，逐个调用fetchWeather并保存或更新到数据库 } }

这里有个容易忽略的点：天气数据本身是“有状态”的，如果不落库，重启应用后当天之前的天气记录就丢了，而推荐系统还需要记录历史天气来印证“昨天冷了所以推荐厚衣服”这种逻辑。把天气快照落库另外有一个好处，答辩演示时可以直接展示本地数据库里的天气记录表，证明数据链路是通的。

城市范围我建议控制在常用城市列表范围内，比如省会加直辖市加几个热门旅游城市，十几二十个即可，完全不需要覆盖全国。用户端用下拉框或搜索选择城市，后端根据城市编码拉取数据，逻辑清晰又不浪费免费额度。

4. 推荐引擎：把天气数值翻译成“今天该穿什么”

4.1 从体感温度出发的穿衣层级模型

推荐引擎是这个项目里最值得讲清楚的部分。前期调研阶段我看过各种穿衣指数表，最后我把逻辑简化成一套“穿衣层级+场景修正+个性化加权”的三段式模型，后面代码实现都是围绕它展开的。

第一段是穿衣层级，根据体感温度决定整体厚度：

这套分级是推荐系统的主干规则。不要一上来就追求精细到每一度，先把区间分好，后面再逐步细化。加上用户偏好修正后，即使同一温度下，怕冷和怕热的人拿到的层级也不一样，这已经比单纯的温度穿衣表灵活很多了。

4.2 天气状况、湿度、风力的场景修正

光有温度层级还不够，真实场景里“下雨”“大风”“潮湿”这些因素对穿搭的影响非常大，这就是第二段“场景修正”。我的做法是在基础穿搭列表的基础上，按天气实况做过滤和替换：

• 天气现象为雨或雪：把基础推荐里怕水的材质（纯棉外套、普通帆布鞋）替换为防水面料（冲锋衣、有防水涂层的鞋），并强制加入雨伞或雨鞋的辅助项；
• 风力大于等于4级：优先推荐防风面料的外套，帽子类配饰加分；风大时围巾、高领内搭更实用；
• 湿度大于等于80%：体感温度下调2到3度，推荐里增加透气面料项，闷热天提示选择浅色、轻薄材质；
• 温差大（当天最高最低气温差超过10度）：推荐可穿脱的分层搭配，比如T恤加开衫加外套，方便中午脱、早晚穿。

场景修正要做到“解释得清”：每个修正规则都能在推荐结果里给出原因标签，比如“小雨：建议携带雨伞”“今日西北风4级：建议防风外套”。这种推荐理由展示在页面上，系统就从一个“查穿着表”的工具变成了“有判断的助手”，评审老师很吃这一套。

4.3 个性化权重：用户的体感偏差才是真正的差异化

如果所有人都按同一张温度表推荐，系统就不配叫“个性化”了。我当时设计的个性化维度有三个：性别、怕冷程度、用户历史反馈。

先看性别。男女在穿搭推荐上差异明显，比如连衣裙、高跟鞋和西装、工装的候选池完全不同。做法是给每个穿搭候选打上适用性别标签（男、女、通用），推荐时先做一轮按性别的过滤。

再看怕冷程度。用户在个人中心可以选“我怕冷、正常、我怕热”三档，对应一个温差修正系数：

• 选“怕冷”：在计算穿衣层级时，把体感温度再下调3度，也就意味着在同样的21度天气下，系统给怕冷用户推荐的是偏厚一档的衣服；
• 选“怕热”则相反，上调3度；
• 默认“正常”不加修正。

最后是历史反馈。用户在推荐卡片上可以点“满意”或“不满意”，系统记录这个行为，后续推荐时降低不满意类别的权重、提升满意类别的权重。这是最简单的隐式反馈协同思路，放到毕设里已经完全够用，而且它是可解释的——答辩时老师问“你如何实现个性化”，你直接说用户反馈驱动权重调整，比空泛地说“使用推荐算法”结实得多。

4.4 候选生成与加权评分怎么算

前几段讲的都是规则，但项目最后呈现给用户的应该是一个有序推荐列表，而不是单条建议，这样页面上能展示4到6张穿搭卡片，视觉上也漂亮。我的做法是：

• 候选库：数据库中维护一张穿搭物品表，存上衣、下装、外套、鞋子、配饰五类物品，每件物品标记适用季节、适宜温度范围、适用性别、材质、防水防风属性；
• 候选生成：根据体感温度加用户温度偏好修正后的“推荐温度”，查出温度范围覆盖该温度的候选物品，按类别分组；
• 加权评分：每个候选物品计算一个综合得分，公式大致是：

score = 温度匹配分数(0~60) + 天气适配分数(0~25) + 用户偏好分数(0~15)

温度匹配分数按目标温度与物品适宜温度范围的接近程度线性递减，完全落入区间给满分60，每偏离1度扣3分，直到扣完；天气适配分数看物品属性与当前天气的匹配情况，比如下雨天防水材质加10分，非防水材质扣5分，风大时防风属性加8分；用户偏好分数来自历史反馈积累的倾向，例如用户对“大衣”类别的满意次数多，则同类候选加5到15分。

最后按总分排序，取前若干个，再按“上衣、下装、外套、鞋、配饰”分组拼接成完整穿搭组合。这里我从实际体验得到一个心得：不要直接返回6件互不相关的单品，要按套系组合推荐，比如短袖加牛仔裤加帆布鞋是一套，衬衫加休闲裤加风衣是另一套，每套配文字说明。用户需要的不是一个物品列表，而是一套可以直接上身的方案。

5. 数据库设计与核心代码走读：从表结构到推荐接口

5.1 核心表结构怎么建

数据库我用MySQL 8.0，库名dress_recommend，一共五张核心表。设计原则是尽量精简，但满足推荐、记录反馈、管理候选库三个闭环需求。

CREATE TABLE `user` ( `id` INT AUTO_INCREMENT PRIMARY KEY, `username` VARCHAR(50) NOT NULL, `gender` CHAR(1) DEFAULT 'M', -- M男 F女 `temp_preference` INT DEFAULT 0, -- 对应怕冷/正常/怕热 `created_time` DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE `weather_record` ( `id` INT AUTO_INCREMENT PRIMARY KEY, `city_code` VARCHAR(20) NOT NULL, `temp` INT, -- 实时温度℃ `feels_like` INT, -- 体感温度℃ `humidity` INT, -- 相对湿度% `wind_scale` INT, -- 风力等级 `weather_text` VARCHAR(20), -- 天气现象：晴/多云/小雨等 `record_time` DATETIME ); CREATE TABLE `dress_item` ( `id` INT AUTO_INCREMENT PRIMARY KEY, `category` VARCHAR(10) NOT NULL, -- 上衣/下装/外套/鞋子/配饰 `name` VARCHAR(50) NOT NULL, -- 商品名或穿搭名 `min_temp` INT, -- 适宜温度下限 `max_temp` INT, -- 适宜温度上限 `gender` CHAR(1) DEFAULT 'U', -- 适用性别 M/F/U通用 `material` VARCHAR(20), -- 材质：纯棉/防风/防水/羊毛等 `style_tags` VARCHAR(100), -- 风格标签：休闲/商务/运动/文艺 `image_url` VARCHAR(255) -- 展示图片地址 ); CREATE TABLE `recommend_record` ( `id` INT AUTO_INCREMENT PRIMARY KEY, `user_id` INT NOT NULL, `city_code` VARCHAR(20), `weather_record_id` INT, `recommend_content` TEXT, -- 推荐结果快照JSON `feedback` TINYINT DEFAULT 0, -- 0未反馈 1满意 2不满意 `created_time` DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE `city_config` ( `id` INT AUTO_INCREMENT PRIMARY KEY, `city_name` VARCHAR(50), `city_code` VARCHAR(20) );

这里要特别提醒一个坑：recommend_record表中的recommend_content存的是推荐结果的JSON快照。如果推荐时只存动态计算的分数而不存结果快照，后续用户反馈、历史记录展示、以及答辩时演示“上周二系统推荐了什么”都无法还原。快照字段几乎是所有带“历史记录”功能系统的必备设计，尽管它在概念上有一点冗余，但换来的回放能力非常值。

5.2 推荐接口的完整调用链

核心接口我设计为 /api/recommend/{userId}?cityCode=xxx，完整调用链是这样的：

@RestController @RequestMapping("/api") public class RecommendController { @GetMapping("/recommend/{userId}") public Result recommend(@PathVariable Integer userId, @RequestParam String cityCode) { // 1. 查最新的本地天气快照 WeatherRecord weather = weatherService.getLatest(cityCode); // 2. 查用户信息（性别、怕冷程度） User user = userService.getById(userId); // 3. 调用推荐服务，生成穿搭组合 List<DressOutfit> outfits = recommendService.generate(user, weather); // 4. 记录本次推荐，供后续反馈追溯 recommendService.saveRecord(userId, cityCode, weather, outfits); return Result.ok(outfits); } }

推荐服务的核心逻辑按前面讲的三段式模型来实现，先是温度层级的修正，再是天气场景修正，最后是候选打分排序：

public List<DressOutfit> generate(User user, WeatherRecord weather) { // 第一层：个性化修正体感温度 int targetTemp = weather.getFeelsLike() + user.getTempPreference(); // 第二层：天气场景规则修正 List<DressItem> candidates = itemService.findByTempRange(targetTemp - 3, targetTemp + 3); if ("雨".equals(weather.getWeatherText()) || "雪".equals(weather.getWeatherText())) { candidates = candidates.stream() .filter(t -> !"纯棉".equals(t.getMaterial())) .collect(Collectors.toList()); // 强制加入雨伞/防水鞋等辅助项 } // 第三层：按加权评分排序，组装成套装 List<DressItem> ranked = candidates.stream() .sorted(Comparator.comparingDouble(t -> scoreItem(t, user, weather, targetTemp)).reversed()) .collect(Collectors.toList()); return assembleOutfits(ranked); }

实际上代码要处理的分支比这个多，但骨架就是这个套路：先修正温度，再过滤不适配，再打分排序，最后组装套装。把推荐逻辑拆成几个独立方法在service里写清楚，比把所有if else堆在一个大方法里好维护得多，答辩时讲代码也容易讲。

5.3 反馈记录：让推荐闭环转起来

当用户在前端点了“满意”或“不满意”，前端调用 /api/feedback 接口：

@PostMapping("/feedback") public Result submitFeedback(@RequestBody FeedbackVO vo) { RecommendRecord record = recommendService.getById(vo.getRecordId()); record.setFeedback(vo.getFeedback()); recommendService.updateById(record); // 根据反馈调整用户的风格标签权重 recommendService.adjustUserPreference(record); return Result.ok(); }

adjustUserPreference的实现可以直接在user表加一个preferred_tags字段，记录用户满意的穿搭风格标签；下次打分时“用户偏好分数”就根据用户是否有该标签来加分。这种设计简单、直观、能讲清楚，又能体现反馈闭环，对毕设来说已经非常足够。

6. 前端页面与演示效果：如何让推荐结果有说服力

6.1 Thymeleaf还是前后端分离，怎么选

很多SpringBoot毕设纠结要不要用Vue做前后端分离。我的建议很直接：没有Vue基础就老老实实用Thymeleaf服务端渲染，不要为了“前后端分离”这个词给自己加压。

理由有这么几个：

• Thymeleaf和SpringBoot是同一套体系，模板引擎内置的语法绑定简单，接口数据不需要再单独处理跨域；
• 毕业设计考核的是后端Java能力和业务设计，页面做到干净整齐即可，分离式的工程复杂度对本科阶段来说加分不明显；
• 用Vue还需要处理CORS跨域、静态资源打包、前后端联调，每一个环节都是隐藏的时间黑洞。

如果你的题目明确要求“前后端分离”（比如带Vue3字样的变体），那可以考虑用Vue3加Vite，把SpringBoot当纯后端提供REST接口，前端单独部署。但就本题目来说，Thymeleaf足够。

6.2 首页信息架构和穿搭卡片展示逻辑

我的页面分四块区域，信息架构是这样的：

1. 顶部：城市选择下拉框加“一键推荐”按钮，以及当前天气摘要（温度、体感温度、湿度、风力、天气现象）；
2. 中部：推荐穿搭卡片区，横排展示3到6套完整穿搭，每套包含上衣、下装、外套、鞋子和配饰的名称，下方有一行推荐理由说明文字，比如“今日体感23℃，建议长袖加薄外套；有小雨，建议携带折叠伞”；
3. 右下角：历史推荐记录折叠面板，按时间倒序列出往日的推荐结果和当时的反馈按钮；
4. 底部：穿衣指数小科普，展示温度区间的穿衣建议表，方便用户理解推荐依据。

穿搭卡片的数据来自推荐接口返回的JSON，Thymeleaf模板里直接遍历展示。每张卡片旁边放“满意”和“不满意”两个按钮，点击后通过Ajax提交反馈，页面不刷新地更新反馈状态。

这一块还可以加一个小亮点：根据天气现象切换页面背景色系。晴天用明亮的暖色调背景，雨天用偏冷的灰蓝色调，雪天用更素净的浅色。这个纯前端的CSS class切换，代码量不大，但视觉上效果很直观，演示的时候给人的“智能感知”印象会强很多，而且实现完全不复杂：后端在页面模型里放一个weatherType字段，前端根据它给body加不同class即可。

6.3 图表展示：把天气趋势可视化

如果要进一步给系统加分，可以在城市天气详情里用简单的ECharts折线图展示未来24小时的气温曲线（如果开的天气API有预报节点的话，免费版通常提供未来数小时到3天的预报数据）。ECharts通过CDN引入即可，几行JS代码就能出一个漂亮的曲线图。图表不是必选项，但有了它，页面的专业感会明显提升，而且答辩时用“未来温差超过10度，系统推荐分层穿法”可以做到图文对照，解释推荐逻辑时更有说服力。

7. 调试部署与答辩准备：那些代码之外的实战经验

7.1 高版本SpringBoot与MyBatis Plus的兼容坑

前面我反复强调版本选2.7.x，如果你偏要用SpringBoot 3.x，这里有个几乎必踩的坑：MyBatis Plus的旧版本（3.5.2及以前）底层依赖mybatis-spring，这个库在SpringBoot 3下不再兼容，启动时会报 Failed to introspect Class 之类的错误。解决方式是必须使用MyBatis Plus 3.5.3以上版本。如果你在2.7.x环境，这个问题基本不存在，但也要注意MyBatis Plus的PaginationInnerInterceptor配置方式在不同版本里略有区别，以官方文档为准，别照抄过时的博客配置。

还有一个比较隐蔽的坑：SpringBoot 3.x里自带HTTP客户端相关组件的类路径也有变化，如果用Hutool这类外置工具包影响不大，但如果直接用Spring的RestTemplate，要注意版本差异。总之，项目启动前先在控制台确认版本信息，把兼容问题扼杀在第一步，比运行到一半再排查高效得多。

7.2 定时任务与免费API的额度博弈

我在开发阶段因为频繁请求天气接口，一度把免费额度用爆，接口返回 429 Too Many Requests。这是一个特别现实的线上问题，但同样也是毕业设计里的加分点：在答辩时你可以说“我通过本地缓存加定时任务减少第三方API调用，防止超额”，要让老师看到你有生产意识。

我最终的方案是：

• 应用启动时加载城市配置表，把每个城市的首条天气记录初始化到本地库；
• 每天8点、12点、18点三个整点各跑一次定时刷新，避免高峰期数据过期太久；
• 如果请求失败，保留数据库中最近一次成功的天气记录，页面显示“数据更新于xx分钟前”，不影响核心推荐功能。

这个兜底方案做起来很简单，但效果很好。至少在实际演示时，哪怕现场网络或API出问题，页面照样能出推荐结果，不会出现白屏尴尬。

7.3 答辩时最容易被追问的五个问题

最后一个多月我总结了自己被问到最多的几个问题，提前准备好就不会慌：

1. “你的个性化体现在哪里？”——答：温度偏好的用户可配置，加上历史反馈对候选物品权重的调整，不是花架子；
2. “推荐结果是怎么算出来的？”——答：讲温度层级、场景修正、加权评分三段式，边说边打开打分日志或数据库记录展示；
3. “如果天气API挂了怎么办？”——答：本地缓存兜底，保留最后一次成功数据，页面提示更新时间；
4. “你这个和查天气App的穿衣指数有什么区别？”——答：天气App只给一句话，我的系统给出完整穿搭组合、推荐理由、具备个性化反馈闭环，并且数据全部落库可追溯；
5. “怎么验证推荐是合理的？”——答：人工规则验证，加上用户反馈数据积累，展示反馈满意度的统计接口或图表数据。

第4个问题尤其值得提前想清楚。现在天气App基本都带穿衣指数，你的系统凭什么有价值？答案在于“推荐”而非“指数”——指数只是一行文字，推荐是选项组合、是个性化的、是能反馈优化的。每次被问到这个，我都会现场演示同一温度下怕冷用户和正常用户拿到不同推荐结果，这个对比演示几乎是答辩环节最出效果的一幕。

最后一点经验

最后再分享一个小经验：毕设从选题到答辩的整个过程里，最容易拖垮进度的不是写代码，而是技术版本的兼容问题和需求边界的不清晰。我做这个项目时把“选型、数据接入、推荐逻辑、前端展示、调试答辩”分成了五个明确阶段，每个阶段限定一周到两周，整体节奏就很稳。尤其记住一点——优先把“天气到穿搭推荐再到页面展示”这条主链路跑通，再做那些锦上添花的图表、风格标签和反馈统计。把核心闭环做完，你的题目就已经立住了，剩下的一切都是加分项。希望这篇记录能帮你把同样一个题目做得更顺、更出彩。