简介一套基于JavaMVC架构的天气预报穿衣搭配APP毕业设计含PC端与安卓手机端面向计算机专业毕业设计或课程设计场景。项目采用界面层、业务逻辑层、数据层三层分离的MVC模式服务器与客户端以XML和JSON交互覆盖地区天气查询、穿衣搭配提示、管理员发布天气公告等完整功能。资源共424个文件主要包括93个Java源码、86个XML配置、31个JSP页面以及数据库SQL、视频演示和图片素材压缩包仅2.73MB。已有266人学习浏览项目结构清晰便于理解Java Web与Android联动开发可直接用于二次扩展或作为毕设提交材料。1. 这个JavaMVC的天气预报穿衣搭配APP到底在做什么这个基于JavaMVC开发的天气预报穿衣搭配APP是毕业设计里相当经典的一套选题一个PC端管理后台、一个安卓手机客户端、一个共享的数据库再配上穿衣推荐规则。它解决的需求非常具体——用户打开APP选定城市看到实时温度的同时能直接拿到一份“当前体感适合穿什么”的搭配建议而不是自己对着温度数字犹豫。对想做Java方向又想展示Android开发能力的学生来说这个选题工作量适中、技术栈完整适合一个人独立完成也是投入产出比比较高的方向。2. MVC架构在PC端与安卓端的分层落地2.1 Android端MVC的切分Activity、XML布局与Model各管哪一块Android原生Java开发里MVC的分层一直有个被反复吐槽的现象Activity既是视图容器又是事件入口写着写着就变成几千行的“上帝类”天气解析、穿衣判断、UI刷新全堆在onCreate里。我写这个项目时给自己立了三条规矩Activity只做流程控制不写业务规则View层只用res/layout下的XML文件不动态拼界面Model层是纯Java类加数据访问对象不依赖任何Android组件这样单元测试可以直接跑Model。分包结构是照着这三条规矩来的你拿到源码后第一件事应该是看包名而不是打开Activitycom.example.weather ├── activity # MainActivity、CitySelectActivity ├── adapter # WeatherAdapter、DressingAdapter ├── model # WeatherModel、DressingSuggestion、CityModel ├── db # DatabaseHelper、DressingRuleDao ├── network # HttpUtil、WeatherApiClient └── service # DressingRecommendService、FeelsLikeCalculator包名里的com.example.weather只是演示用的占位实际项目换成你自己的域名反写即可。这里真正值得学的是分工activity包里的类只持有控件引用和Model实例adapter负责把数据绑定到列表项service包里的FeelsLikeCalculator专门算体感温度network包只处理HTTP和JSON。这样每一个类都能讲清楚“我在MVC里是什么角色”答辩时不会被问倒。MVVM和MVP当然也是选项但毕业设计里MVC有不可替代的优势Android官方文档里对Activity、Fragment、布局、数据模型的分层描述本身就接近MVC导师看起来不陌生而且题目明确写了JavaMVC用MVVM反而要解释“为什么题目说MVC你用了MVVM”。如果你对架构有一定经验可以在局部用类似MVVM的思路比如用LiveData做天气数据的订阅更新但整体分层还是保持MVC的骨架这样最稳。2.2 PC端Spring MVC的角色管理后台与JSON接口服务PC端在这个项目里有两个角色这也是新手容易搞混的地方。角色一是管理后台管理员登录JSP页面维护城市表、穿衣规则表、查看用户反馈记录。角色二是REST接口服务安卓端通过HTTP请求PC端暴露的JSON接口拿到天气数据和穿衣建议。常见做法是同一个Spring MVC工程同时承担两个角色Controller类返回ModelAndView给JSP页面RestController类返回JSON给安卓端Service层和DAO层共用。我为什么推荐用Spring MVC而不是Spring Boot因为毕业设计题目里通常有明确的课程背景要求Spring MVC加JSP是教科书表述的标准组合和“MVC”三个字完全对应。Spring Boot开发效率更高但不少毕业设计选题或评审表里要求体现三层架构、Controller-Service-DAO的分层Spring MVC反而更容易把这些层次展示清楚。如果指导老师不限制技术栈你完全可以在Spring Boot里写MVC结构的代码但题目以“JavaMVC”出现时Spring MVC是更稳妥的选择。注意一点不要把PC端当成一个单独的“网站”来做它就是整个系统的管理和服务端。安卓端是展示端、交互端PC端是规则配置端。穿衣规则表里每一条建议都应该能在PC端后台改掉改了之后安卓端下一次请求就能拿到新规则。这是整个项目里最能体现“两端数据联通”的演示路径也是答辩时最值得讲的三分钟。2.3 核心表结构天气数据、穿衣规则与用户偏好怎么存表结构是这类项目最容易设计乱的环节。别急着加表先想清楚闭环。我建议只保留四张核心业务表城市表、天气数据表、穿衣规则表、用户信息表。用户表在毕业设计里可以简化到只存一个用户名和耐寒偏好。CREATE TABLE city ( id INT PRIMARY KEY AUTO_INCREMENT, city_name VARCHAR(50) NOT NULL, province VARCHAR(50), city_code VARCHAR(20) UNIQUE NOT NULL ); CREATE TABLE weather_data ( id INT PRIMARY KEY AUTO_INCREMENT, city_code VARCHAR(20) NOT NULL, temperature DECIMAL(5,1) COMMENT 实时温度, humidity INT COMMENT 相对湿度单位%, wind_speed DECIMAL(5,1) COMMENT 风速单位m/s, weather_desc VARCHAR(50) COMMENT 晴/多云/小雨等, update_time DATETIME ); CREATE TABLE dressing_rule ( id INT PRIMARY KEY AUTO_INCREMENT, min_temp DECIMAL(5,1), max_temp DECIMAL(5,1), wind_level INT, suggestion VARCHAR(255) COMMENT 穿搭建议文本 ); CREATE TABLE user_info ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) UNIQUE, cold_resistance TINYINT COMMENT 耐寒等级1-51最怕冷 );穿衣规则表是整个系统的核心。如果只按温度一个维度写死规则会显得太简单。同样10度晴天和刮风天的体感完全不同所以dressing_rule表里把min_temp、max_temp、wind_level三个字段联合起来做范围匹配。建议文本直接存成品句子比如“毛衣 厚外套 长裤”不推荐存衣服ID列表再去关联因为毕业设计阶段没必要把推荐做成组合计算存文本最简单、最直观答辩时也最好讲。weather_data表和city表是一对多关系通过city_code关联。一个城市每天可以有多条天气记录但系统展示时只取update_time最新的一条。如果接第三方天气接口这个表也可以用来做本地缓存避免每次都去请求外部接口。user_info表里的耐寒等级是为进阶功能留的接口基础版可以不用但表先建好后面加“怕冷/怕热用户穿得更厚”这类逻辑时不用改表结构。注意建表时中文注释和中文数据在旧版MySQL下容易乱码执行建表脚本前先确认数据库用的是utf8mb4字符集。我在一次模拟项目里就因为建表时的默认字符集不对天气描述字段存进去是“多云”读出来变成乱码排查了很久才发现是表本身字符集的问题源码里怎么设置连接编码都没用。3. PC端先行搭建Spring MVC工程并实现穿衣推荐接口3.1 最小工程配置pom依赖、web.xml与DispatcherServletPC端用Maven管理依赖不需要堆很多包。我建议核心依赖控制在五个以内spring-webmvc是框架本身servlet-api提供Servlet环境jackson-databind负责把Controller返回值序列化成JSONmysql-connector-java是数据库驱动再加一个连接池HikariCP或Druid。说句实话毕业设计项目里依赖越少越好排查多了反而出现版本冲突。dependencies dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.3.20/version /dependency dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version4.0.1/version scopeprovided/scope /dependency dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId version2.13.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.29/version /dependency /dependencies版本号可以根据你本地Maven仓库里已有的版本调整不一定要和这个完全一致。spring-webmvc是核心javax.servlet-api的scope为provided是因为Tomcat已经自带了Servlet容器打包时不需要打进去。jackson-databind在Spring MVC返回ResponseBody时负责对象转JSONmysql驱动版本要和你本地安装的MySQL大版本匹配8.x的驱动连5.x的库也能用但反过来不行。web.xml里最容易踩的坑是DispatcherServlet的url-pattern。用斜杠/表示除了JSP外的请求都进Spring MVC用/*会把JSP请求也拦截掉结果访问login.jsp直接404。servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-value/WEB-INF/spring-mvc.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern//url-pattern /servlet-mapping这里的load-on-startup必须为1保证Tomcat一启动就初始化Spring容器不然第一次请求会慢好几秒。contextConfigLocation指向的/WEB-INF/spring-mvc.xml里要做两件事component-scan扫描com.example.weather包下的所有类annotation-driven开启注解驱动。mvc:annotation-driven / context:component-scan base-packagecom.example.weather /这两个配置缺一不可。没有annotation-drivenRestController和GetMapping不生效没有component-scan你写的Controller类根本不会被Spring容器管理请求进来直接404。我见过不少同学把Controller写出去了但漏配扫描包Tomcat能启动、页面能打开就是一个接口都不响应最后折腾一晚上发现是扫描包路径写错了一个字母。3.2 城市天气数据的获取方式第三方接口与本地模拟数据天气数据从哪来是很多人在动手前最纠结的问题。第三方天气API需要申请Key、有访问频率限制、返回字段格式也可能随时变动对毕业设计来说变量太多。我建议分两步走先用本地模拟数据把整个流程跑通再在代码里预留一个数据源接口以后接真实API只需要换一个实现类。public interface WeatherDataSource { WeatherInfo fetchWeather(String cityCode); } Component public class MockWeatherDataSource implements WeatherDataSource { Override public WeatherInfo fetchWeather(String cityCode) { WeatherInfo info new WeatherInfo(); info.setCityCode(cityCode); info.setTemperature(22.5); info.setHumidity(60); info.setWindSpeed(2.5); info.setWeatherDesc(多云); return info; } }这个设计的关键是面向接口编程。WeatherDataSource是一个接口MockWeatherDataSource是模拟实现以后再写一个RealWeatherDataSource调用第三方APIController不用改一行代码。答辩时讲这一层非常加分因为大多数同学都是把第三方API写死在业务代码里而你已经做了数据源适配层的设计。如果你的确想接真实天气数据源有一个比较省事的做法去查国内哪家天气服务平台有免费开发者接口注册后拿到一个Key按文档拼URL发请求。返回的JSON结构一般是code、data、temperature这类字段用Gson或Jackson转成自己的WeatherInfo对象即可。需要注意第三方接口返回的温度单位、字段名语义要和业务代码统一比如有的平台返回的是开尔文温度有的返回的是华氏度换算错的话推荐出来的穿衣建议会明显离谱。3.3 实现GET /dressing/recommend接口体感温度计算与规则匹配穿衣推荐接口是整个PC端最核心的部分也是你答辩时最可能要手写白板的代码。这里把接口、体感温度计算、规则匹配三个层次放在一个Controller演示让逻辑集中看得清楚。RestController RequestMapping(/api/dressing) public class DressingRecommendController { Autowired private WeatherDataSource weatherDataSource; Autowired private JdbcTemplate jdbcTemplate; GetMapping(/recommend) public MapString, Object recommend(RequestParam String cityCode) { WeatherInfo weather weatherDataSource.fetchWeather(cityCode); double feelsLike calcFeelsLike( weather.getTemperature(), weather.getHumidity(), weather.getWindSpeed() ); String suggestion matchRule(feelsLike, weather.getWeatherDesc()); MapString, Object result new HashMap(); result.put(cityCode, cityCode); result.put(temperature, weather.getTemperature()); result.put(feelsLike, feelsLike); result.put(dressing, suggestion); return result; } private double calcFeelsLike(double temp, int humidity, double windSpeed) { double feels temp; if (temp 15 humidity 60) { feels temp - (humidity - 60) / 30.0; } feels feels - windSpeed * 0.5; return feels; } private String matchRule(double feelsLike, String weatherDesc) { String sql SELECT suggestion FROM dressing_rule WHERE min_temp ? AND max_temp ? ORDER BY (max_temp - min_temp) ASC LIMIT 1; String suggestion jdbcTemplate.queryForObject( sql, String.class, feelsLike, feelsLike); return suggestion null ? 温度超出规则范围暂无建议 : suggestion; } }体感温度计算里我用了两个简单影响因子湿度大于60%且温度低于15度时每多30个百分点湿度体感降1度风速每增加1米每秒体感降0.5度。这是一个简化模型精度在现实气象学里不算高但对毕业设计来说足够合理而且你能讲清楚每个系数的含义。matchRule方法里ORDER BY (max_temp - min_temp) ASC是关键——如果两条规则的温度范围重叠取范围最窄的那条避免出现10度时同时命中“短袖”和“羽绒服”两条规则的情况。接口返回的JSON结构建议固定成{cityCode, temperature, feelsLike, dressing}四个字段安卓端解析时一一对应。返回结果里的feelsLike是体感温度这个数字能让用户直观理解“为什么实际温度是10度但建议穿羽绒服”——因为体感只有5度。这个细节在答辩时主动讲出来效果比等着导师问要好得多。4. 安卓端开发从定位到穿衣卡片展示的完整链路4.1 主界面布局RecyclerView CardView搭建天气列表安卓端主界面通常分两块顶部一个城市选择入口下面用RecyclerView列出天气卡片。每一个列表项用CardView包起来CardView自带圆角和阴影效果能让界面看起来有层次感不需要额外引入复杂的自定义View。androidx.recyclerview.widget.RecyclerView android:idid/weatherList android:layout_widthmatch_parent android:layout_heightmatch_parent android:padding12dp tools:listitemlayout/item_weather_card /item_weather_card.xml里的布局结构建议用LinearLayout垂直排列从上到下依次是城市名、温度数值、天气现象、穿衣建议。穿衣建议是整条数据里最长的文本TextView不要限制行数或设置maxLines否则长建议会被截断用户看不到完整搭配方案。我见过把穿衣建议用android:singleLinetrue限制成单行的版本结果“羽绒服 加厚毛衣 棉裤 围巾帽子”只显示了“羽绒服 加厚”这种细节在演示时很尴尬。RecyclerView的Adapter绑定数据时要注意每一条数据里feelsLike和dressing两个字段是同时区展示的。我的做法是在卡片左上角显示城市和实时温度右上角显示体感温度底部整行展示穿衣建议字体稍微大一点因为它才是这个APP的核心输出。4.2 网络层封装OkHttp请求PC端接口与Gson解析安卓端的网络层用OkHttp和Gson就够了这两个库在Java原生开发里是事实标准资料多、坑也基本都被踩平了。网络请求要单独封装一个类不要散落在Activity里。public class WeatherApiClient { private static final String BASE_URL http://10.0.2.2:8080/weather/; private OkHttpClient client new OkHttpClient(); public WeatherResponse fetchRecommend(String cityCode) throws IOException { Request request new Request.Builder() .url(BASE_URL api/dressing/recommend?cityCode cityCode) .get() .build(); try (Response response client.newCall(request).execute()) { if (!response.isSuccessful()) { throw new IOException(HTTP错误码 response.code()); } String body response.body().string(); return new Gson().fromJson(body, WeatherResponse.class); } } }BASE_URL里的10.0.2.2是安卓模拟器访问PC本机的固定地址这个知识点几乎每次联调都会用到。真机调试时要把10.0.2.2改成电脑在局域网里的IP地址比如192.168.x.x。代码里用try-with-resources关闭Response避免连接泄漏。Gson的fromJson会直接按JSON字段名匹配Java对象的属性名所以WeatherResponse里的字段名要和PC端返回的四个字段保持一致建议直接用同样的命名cityCode、temperature、feelsLike、dressing。网络请求建议放在子线程执行。OkHttp的execute是同步方法如果在UI线程直接调用安卓会抛NetworkOnMainThreadException。简单做法是开一个子线程或者用OkHttp的enqueue异步回调回调里再通过runOnUiThread更新界面。这个点虽然基础但几乎每一个第一次做网络请求的同学都会遇到面试和答辩时也常被问。4.3 穿衣推荐引擎本地规则与PC端规则的取舍安卓端要不要也写一份穿衣推荐逻辑这是架构上一个值得想清楚的点。PC端规则表存在服务器上安卓端完全依赖接口返回离线时APP就没有推荐能力。独立的做法是在安卓端也存一份简化版本地规则作为接口异常时的兜底方案。public class LocalDressingRule { public static String recommend(double temp, int humidity, double wind) { double feelsLike temp - wind * 0.5; if (temp 15 humidity 60) { feelsLike - (humidity - 60) / 30.0; } if (feelsLike 26) return 短袖T恤 薄长裤/短裤; if (feelsLike 20) return 长袖衬衫 薄外套; if (feelsLike 15) return 卫衣/针织衫 牛仔裤; if (feelsLike 10) return 厚卫衣 风衣/夹克; if (feelsLike 5) return 毛衣 厚外套 长裤; if (feelsLike 0) return 羽绒服 毛衣 保暖裤; return 厚羽绒服 加厚毛衣 棉裤 围巾帽子; } }本地规则的阈值是我当时根据自己体感调的你可以按需求改没有标准答案。但要清楚它的定位它是PC端规则不可用时的兜底不是主逻辑。主逻辑永远以PC端返回的JSON为准因为PC端规则可以由管理员在后台实时修改而本地规则必须升级APP才能变更。这个取舍要在答辩时能讲明白——“为什么推荐逻辑写了两份因为PC端是权威数据源本地规则是离线容灾方案。”这道题我在模拟答辩里被问过这么答是能过关的。缓存方面建议用SharedPreferences存最后一次接口返回的完整JSONAPP启动时先读缓存秒开界面再在后台请求新数据刷新。不要一上来就动SQLiteSharedPreferences对这个体量的缓存完全够用代码量还少。5. 联调避坑PC端与安卓端对接的5个高频翻车现场5.1 安卓模拟器连不上本机PC接口现象模拟器打开APP请求PC端接口一直报ConnectException但用PC浏览器访问同一个接口地址却是正常的。原因模拟器是一个独立的虚拟网络环境它内部的127.0.0.1指向自己不是你的电脑。用localhost或127.0.0.1去连宿主机等于在模拟器内部找了一圈没找到服务。解决模拟器一律用10.0.2.2代替127.0.0.1这是Android模拟器预留的宿主机回环地址。真机调试则用电脑的局域网IP可以通过ipconfig命令查看。另外安卓9及以上默认禁止明文HTTP流量需要在AndroidManifest.xml的application节点里加android:usesCleartextTraffictrue或者在networkSecurityConfig里单独放行指定域名否则接口返回结果会在网络安全拦截那一层就被丢掉现象同样是连接失败。5.2 定位权限与模拟定位导致白屏现象APP运行后界面一片空白没有崩溃日志也没有弹出定位授权对话框但Logcat里能看到SecurityException相关异常。原因Android 6.0及以上把定位权限列为危险权限必须在代码里动态申请。只写在AndroidManifest.xml里的声明不会触发弹窗用户没有授权定位权限时LocationManager直接调用会抛异常。解决在进入主界面之前用ActivityCompat.requestPermissions申请ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION两个权限在onRequestPermissionsResult回调里判断授权结果未授权则提示并退出到设置页。还有一个隐蔽点Android模拟器的默认位置是谷歌总部附近如果你不做虚拟定位APP获取到的坐标会落在国外逆地理编码出来的城市名会和预期完全不符。调试时在Android Studio的Device Explorer或模拟器扩展控制里手动设置经纬度才能模拟你想要测试的城市天气场景。5.3 JSON字段缺失导致穿衣推荐崩溃现象PC端接口返回的JSON偶尔缺少某个字段比如第三方天气数据里的windSpeed为空时Gson解析出来的对象对应字段是null调用doubleValue时直接抛NullPointerExceptionAPP闪退。原因Gson对包装类型字段遇到JSON里的null值时不会自动填充默认值而是保持null。如果实体类把windSpeed声明成基础类型doubleGson会把null转成0但如果声明成Double包装类型使用时没有判空就会崩溃。解决实体类里所有天气数值字段统一用Double、Integer包装类型取值时通过工具方法判空给默认值。另外可以在PC端Controller里做一层保障——如果从数据源拿到的字段为null手动给一个合理默认值再返回JSON让安卓端永远拿到的结构是完整的把容错放在最外层。5.4 中文乱码编码不一致引发的显示问题现象PC端接口在浏览器里打开显示正常安卓端请求后“多云”变成“多”穿衣建议里的中文全部是问号。原因Spring MVC的RestController返回字符串时默认响应编码可能不是UTF-8。实际项目里最常见的是POST请求时Tomcat默认按ISO-8859-1解析参数返回时又按ISO-8859-1输出安卓端按UTF-8解码就彻底错位。现象要解决透需要两端各做一层。PC端在GetMapping注解里显式声明produces application/json;charsetUTF-8同时在web.xml里配置一个CharacterEncodingFilter把request和response的编码全部设为UTF-8。安卓端在解析响应时明确指定用UTF-8解码response.body().string()方法内部已经按Content-Type解析但如果你手动new String(bytes)就要显式传UTF-8字符集。编码问题属于那种排查时不难但因为涉及PC端、数据库、安卓端三个环节容易互相怀疑的玄学问题我第一次遇到时花了大半个下午才定位到是PC端响应头没设置编码。5.5 数据库连接泄漏导致接口假死现象PC端接口前几十次调用正常后面突然越来越慢最后Tomcat控制台报连接池连接耗尽整个服务无响应重启Tomcat恢复一会儿又复发。原因代码里用JdbcTemplate或原生JDBC获取数据库连接后如果异常路径上没有释放连接每次失败都会泄漏一个连接。程序运行越久可用连接越少直到连接池为空。我第一次遇到时一度以为是电脑内存不够后来在控制台看到连接池监控数据才反应过来。解决换用连接池HikariCP或Druid并把最大连接数设小一点比如30这样问题暴露得够快。代码层面所有数据库操作统一走Spring的JdbcTemplate它内部会帮你在finally块里归还连接不需要手动管理连接生命周期。如果你用了原生JDBC必须保证finally块里执行conn.close()。排查时可以在Tomcat启动参数里加一个连接池监控的JMX导出或者直接打印连接池当前活跃连接数看数字是不是只增不减。6. 答辩前验收测试用例、演示脚本与一个进阶亮点6.1 把穿衣推荐的边界条件测到位穿衣推荐这个功能最容易在极限温度上翻车。PC端规则表如果只在10度到25度之间配了数据夏天35度和冬天零下10度时查询结果就会落进“暂无建议”分支。我建议做一个简单表格提前把不同场景的输入跑一遍重点验证规则边界是否连续测试场景温度湿度风速预期穿衣建议夏季酷暑3470%1.5短袖T恤 短裤春秋过渡1845%3.0长袖衬衫 薄外套初冬降温840%2.0厚卫衣 风衣/夹克深冬严寒-530%4.0羽绒服 毛衣 保暖裤边界0度050%2.5羽绒服 毛衣 保暖裤注意0度、26度这类临界值要单独测因为SQL用的是闭区间min_temp和max_temp一旦设置成连续覆盖但边界重叠会命中多条规则必须确认排序逻辑没有问题。测试的时候带上接口返回的ture体感温度一起看比如温度18、湿度45%、风速3算出来的体感是16.5预期建议就应该按16.5对应的档位出而不是按18出。6.2 演示时讲清一条完整数据闭环答辩演示的路径我建议固定成一条闭环打开安卓APP选择城市显示天气卡片点击卡片进入穿衣详情然后切到PC端后台打开发衣规则表修改一条建议文本回到APP下拉刷新穿衣建议更新为新文本。这个演示能证明前后端真正通过接口打通数据流是活的不是各自跑各自的Demo。讲清楚这条链路比讲任何代码片段都有用因为它覆盖了用户操作、PC端接口、数据库更新、安卓端网络请求、界面刷新五个环节。到时候导师问“这个项目怎么体现MVC”你可以顺着这条链路把Controller、Service、Model、View一一指出来比背概念强得多。6.3 进阶亮点把规则从静态升级为用户反馈驱动如果还有精力我建议加一个“觉得冷 / 觉得热”的反馈按钮用户点击后记录一条反馈关联城市和当时的体感温度。PC端做一个接口统计各城市反馈分布用来微调该城市的推荐阈值。不用做复杂算法存表加两个查询接口就够了但讲项目的深度时能明显拉开和普通静态规则推荐的距离。我当年没时间实现只在PPT里写了这个方案答辩时作为改进方向提了一句导师的反馈还不错。做完这个项目之后我最大的习惯性动作是从此看天气的时候会下意识先算体感温度再判断穿什么。但更重要的一条经验是动手前把数据表结构和接口返回的JSON格式先定下来再开始写界面代码这个顺序能帮你少走很多弯路。希望你做完这个项目也能把“温度、湿度、风速”到“穿什么”这条链路想得明明白白。希望帮到你。本文还有配套的精品资源点击获取
