做旅游类App的毕业设计每年都有一大批人选但真正能在答辩现场把设计两个字讲明白的并不多。我见过太多项目源码能跑、页面能点一问到你这个推荐逻辑为什么这么排这个缓存为什么放这一层就卡住了。这篇东西想聊的是西藏旅游App设计与实现这条完整链路从开题报告怎么立题、功能模块怎么划边界、技术栈怎么选、数据库怎么落地一直到源码联调阶段那些文档里不会写的故障。关键词里带了源码和开题说明读者多半是要自己动手做一套能交付的东西所以我尽量把每一步的取舍理由写出来而不是只给一份功能清单。不管你是刚开始找选题还是代码写了一半发现架构撑不住下面这些内容应该都能对得上。1. 这个题目真正的难点不在西藏而在旅游App这四个字很多人拿到这个题目第一反应是地域特色——觉得难点在于怎么把高原风光、民俗元素做进界面里。我一开始也这么想后来发现完全想偏了。界面上的地域元素是最容易做的部分换几张图、调一套配色、写几段介绍文案两三天就能出效果。真正卡人的是旅游App这个品类本身的复杂度它是一个多角色、多状态、强时空关联的系统比你做的图书管理、学生成绩管理要难一个量级。1.1 为什么同类题目扎堆却少有能讲清楚设计意图的图书管理系统的本质是增删改查业务状态是线性的借出、归还、逾期三条分支就覆盖完了。旅游App不是。一个用户从想出去玩到玩完回来中间要经历目的地筛选、行程编排、票务预订、导航到达、现场消费、回来评价六个阶段每个阶段的数据形态都不一样。行程编排阶段是计划数据预订阶段是交易数据导航阶段是位置数据评价阶段是内容数据。这四类数据的生命周期、一致性要求、查询模式完全不同硬塞进一套CRUD接口里后期一定会崩。我见过一个比较典型的做法把所有东西都做成信息表 增删改查景点是表、酒店是表、订单是表、评论是表接口一律select * from xxx。演示的时候没问题因为数据量只有二三十条。但答辩老师只要问一句用户按距离排序附近的景点你怎么实现就露馅了——因为经纬度根本没建索引排序靠的是全表扫描后在内存里算。所以这个题目的第一个分水岭是你有没有意识到自己在做一个空间数据系统而不是一个内容展示系统。意识到这一点后面的表结构、接口设计、缓存策略才会跟着变。1.2 从能演示到有工作量的分界线在哪毕业设计有个很现实的问题老师要看工作量但你的时间只有两三个月。这两者之间的平衡点我总结成一句话——功能数量控制在十二个以内但至少有三个功能要做出技术纵深。什么叫技术纵深举几个例子对比功能浅做法工作量低深做法有技术含量景点列表分页查全表返回按地理距离排序 分类筛选 图片懒加载 本地缓存行程规划用户手动一条条添加按天分配、按距离就近排序、冲突检测、拖拽调整顺序地图导航点击跳转第三方地图应用内展示、地理围栏到达提醒、路线概览订单提交后改状态字段库存扣减 超时自动取消 状态机流转天气静态写死的文案按景点坐标请求、缓存有效期控制、异常降级左边一列是能演示右边一列是有工作量。做完右边一列的三到四个你的项目在同类里就站得住了而且答辩时有东西可讲。剩下的功能用浅做法补数量别贪多。这里有个我踩过的坑要提醒不要一上来就把功能清单列到二十几个。我当时列了二十四项写到最后发现光是把菜单页做出来就花了两周剩下的功能全靠占位页 敬请期待糊过去。后来重做的时候砍到十一个功能每个都跑通了整体完成度反而高得多。功能清单是给自己看的排期依据不是给老师看的炫技清单。2. 功能清单不是越长越好把旅游场景拆成三条主线功能怎么划我的建议是别按模块名划按用户旅程划。模块名景点模块、订单模块、用户模块是给数据库看的用户旅程才是给产品看的。这两者的区别在于按模块划你写出来的接口是散的按旅程划接口天然有先后顺序联调时能一条线走通。2.1 行前、行中、行后用户旅程决定模块边界行前阶段的核心诉求是降低决策成本。用户面对一个陌生目的地最想知道三件事有什么值得去、怎么安排顺序、大概花多少钱。对应到功能上就是目的地/景点浏览与筛选、行程编排、费用预估。行中阶段的核心诉求是降低操作成本。人在路上手不方便网络还不一定好。这个阶段的功能设计原则是一屏解决一件事当前在哪、下一站去哪、怎么过去。对应功能是附近景点按距离排序、地图与到达提醒、离线缓存。行后阶段的核心诉求是沉淀内容。用户可以发评价、发照片、收藏行程。这部分工作量不大但对项目的完整性很重要因为它是数据闭环的最后一环——你的数据库里终于有了用户产生的内容而不全是自己录入的假数据。按这三条线一切你会发现之前想做的积分商城会员等级社交关注全被自然淘汰了——它们不属于任何一条主线属于锦上添花砍掉不心疼。这就是按旅程划分的好处它自带优先级。2.2 一份可落地的模块清单与优先级排序下面这份清单是我实际做完之后总结的P0 是必须做P1 是做完了 P0 有余力再加P2 是答不出来也不要紧的。你看这个分布就知道P0 只有七个是能压在两三个月里做完的量。优先级模块关键能力预估工时P0账号体系注册登录、Token 鉴权、资料编辑5 天P0景点浏览列表分页、分类筛选、距离排序、详情页8 天P0行程规划多天分组、添加移除、排序调整、费用合计10 天P0地图与定位应用内地图、当前定位、景点标注6 天P0订单下单、库存扣减、状态流转、超时取消8 天P0评价图文发布、列表展示、评分聚合4 天P0离线缓存景点数据本地化、图片缓存4 天P1天气提示按坐标拉取、缓存降级3 天P1收藏收藏行程与景点2 天P2智能推荐基于浏览历史的简单加权视情况这里面有个容易被忽略的点行程规划和订单是仅有的两个有状态模块也是答辩老师最爱问的地方。行程规划涉及数据结构的组织怎么存多天、怎么保证顺序订单涉及并发与一致性库存扣减。这两个模块做好了你的项目就从页面堆砌升级成系统设计。我在做行程规划的时候第一次用的是一个大 JSON 塞进一个字段的方案好处是简单坏处是不能排序查询、不能单独删某一条、不能做统计。后来改成行程主表 行程明细表的结构明细表里带day_index和sort_order两个字段问题全解决了。这个改动花了我差不多一天但省下了后面无数麻烦。3. 技术选型开题报告里写的栈和你能写完的栈往往不是同一个开题报告阶段有个很普遍的现象为了显得技术先进写上一堆流行框架什么微服务、消息队列、容器编排全堆上去。结果真动手的时候发现光是让服务端跑起来就卡了一周。我的建议很直接开题报告里写的每一个技术名词你都得能说清楚它在你的项目里解决了什么具体问题否则就删掉。3.1 客户端三种路线的取舍客户端这块常见三条路原生 Android 开发、跨端框架、小程序。三条路各有各的适用场景不是哪个先进选哪个。路线优势劣势适合什么情况原生 Android地图、定位、相机等设备能力调用最直接性能最好只能跑一个平台代码量大你只做 Android且地图交互是核心跨端框架一套代码跑两端UI 开发效率高热重载体验好部分原生能力需要插件桥接包体积偏大想做双端且对设备能力依赖不深小程序免安装、有现成的定位与地图组件、演示方便需要额外的主体资质审核周期不可控只做课程演示不追求独立 App 形态我自己选的是跨端方案原因很实在地图、定位、相机这些能力都有成熟的官方插件不需要自己写原生桥接而 UI 部分的开发速度是原生的两倍以上。对于一个人两三个月要交付的项目开发效率的权重远高于极致性能。选跨端要注意一个细节状态管理别搞太复杂。我一开始学着大项目用了一整套状态管理方案写到一个页面要跨三个状态容器调试的时候根本不知道数据是从哪个环节丢的。后来退回到页面级状态 一个全局用户态代码量少了一半bug 也少了。小项目用小方案这是经验。3.2 服务端与数据层的最小可用组合服务端选型的原则是少组件、少中间件、少运维。一个人开发你既是前端又是后端还是运维多引入一个组件就多一个可能出故障的地方。我的组合是单体服务端 关系型数据库 一个内存缓存 对象存储。就这四个。没有消息队列没有服务注册没有网关没有容器编排。所有需要异步的地方用数据库的状态字段 定时任务轮询来实现比如订单超时取消就是一个每分钟跑一次的定时任务扫超时订单。这个方案在数据量小的时候完全够用而且排查问题极其直观——出问题就看数据库一眼就知道卡在哪。数据层用关系型数据库而不是文档型理由是旅游业务的数据关联性很强订单关联用户和产品行程明细关联行程主表和景点评价关联订单和用户。这种多对多、一对多的关系用关系型数据库的外键和连接查询最省心。文档型数据库在嵌套结构上是舒服但一旦要查某个用户所有订单里涉及的景点这种跨集合查询就很别扭。缓存这块只做一件事把首页和景点列表这类高频读接口的返回结果缓存起来设置较短的有效期。别一上来就设计多级缓存、缓存穿透布隆过滤器这些东西用不上还容易写出数据不一致的 bug。我踩过的最典型的一个更新了景点信息但忘了清缓存前端一直显示旧数据查了两个小时才想起来是缓存没过期。4. 数据库设计五张表撑起整个业务闭环数据库设计是这个项目里最能体现功力的部分也是答辩时最容易被追问的部分。我建议你在动手写代码之前先把表画出来反复问自己三个问题这张表的主键是什么、它和谁关联、它会被怎么查。4.1 核心实体关系与字段设计整个系统拆到最小五张核心表就能撑住用户表、景点表、行程表、行程明细表、订单表再加一张评价表做闭环。景点表是整个系统的数据底座字段设计上最需要花心思的是位置信息。经纬度必须单独存成两个字段而且必须建索引——因为按距离排序是这个 App 最高频的查询之一。别把经纬度拼成一个字符串存那样既不能算距离也不能排序。CREATE TABLE spot ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(80) NOT NULL COMMENT 景点名称, category VARCHAR(32) NOT NULL COMMENT 分类自然/人文/城镇, latitude DECIMAL(10,6) NOT NULL COMMENT 纬度, longitude DECIMAL(10,6) NOT NULL COMMENT 经度, altitude INT DEFAULT NULL COMMENT 海拔米, cover_url VARCHAR(255) DEFAULT NULL, intro TEXT, ticket_price DECIMAL(8,2) DEFAULT 0.00, open_time VARCHAR(64) DEFAULT NULL, score_avg DECIMAL(3,2) DEFAULT 5.00 COMMENT 评分聚合值, status TINYINT DEFAULT 1, INDEX idx_geo (latitude, longitude), INDEX idx_category (category, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;行程明细表是另一个重点。它承担多天分组和顺序调整两个职责所以必须带day_index和sort_orderCREATE TABLE trip_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, trip_id BIGINT NOT NULL, spot_id BIGINT NOT NULL, day_index INT NOT NULL DEFAULT 1 COMMENT 第几天, sort_order INT NOT NULL DEFAULT 0 COMMENT 当天内顺序, cost DECIMAL(8,2) DEFAULT 0.00, note VARCHAR(255) DEFAULT NULL, INDEX idx_trip_day (trip_id, day_index, sort_order) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单表的关键是状态字段要设计成状态机而不是随便几个数字。我用的是 0 待支付、1 已支付、2 已使用、3 已取消、4 已退款。每一个状态转换都必须有明确的触发条件比如待支付超过 30 分钟自动变已取消这个转换由定时任务触发。把状态画成图贴在文档里答辩的时候拿出来讲非常有说服力。4.2 索引、冗余与那些后期一定会改的地方有几个设计细节我当时纠结了很久最后的选择供你参考。第一评分要不要冗余。评价表里每条有分数景点表里我另存了一个score_avg聚合值。这是典型的空间换时间——查询景点列表时不用去连接评价表做聚合直接读冗余字段。代价是每次新增评价都要更新这个字段。考虑到评价是低频写、景点列表是高频读这个冗余是划算的。判断冗余的标准就是读写比例读远多于写就冗余反之别冗余。第二图片存哪里。千万别把图片二进制存进数据库。做法是图片传到对象存储数据库里只存 URL。这个决定能省掉后面一堆麻烦备份快、查询快、迁移容易。第三软删除还是硬删除。我给景点表加了status字段做软删除订单和行程用的是硬删除。区别在于景点是基础数据被其他地方引用删了会造成历史数据展示异常订单和行程是用户自己的数据用户想删就真删。这个区分在答辩时是个加分项说明你想过数据引用的问题。后期一定会改的地方我提前告诉你分类字段。一开始我想的是自然景观/人文景观两类做到一半发现用户会按是否适合带小孩是否需要长时间徒步来筛于是又加了一组标签字段。所以景点表建议从一开始就预留一个tags字段逗号分隔或者 JSON 都行把不确定的分类维度先放进去别急着建关联表。5. 几个真正值得写进论文的技术点论文最怕的是流水账——第一章需求分析第二章概要设计第三章详细设计第四章测试全是我做了个列表页我做了个详情页。这类内容写再多也显不出水平。真正能加分的是把几个有技术含量的小问题讲透讲清楚你遇到了什么约束、尝试了哪些方案、为什么最终选了这个。5.1 弱网环境下的图片与数据缓存策略旅游场景有个绕不开的约束用户在景区里网络很可能时好时坏。这不是假设是常态。所以缓存不是优化项是必需项。我的做法分两层。图片层用的是客户端本地磁盘缓存图片 URL 作为 key加载时先查本地命中就直接用没命中才发起网络请求成功后再落盘。这里有个细节要注意——必须给缓存设容量上限和淘汰策略否则用户刷几百张图App 的体积就膨胀到几个 G。我用的是按最近最少使用淘汰上限设 100MB。这个数字是估算出来的单张缩略图压到 80KB 左右100MB 大约能存 1200 张覆盖一次完整旅行的浏览量绰绰有余。数据层用的是两层缓存服务端把景点列表接口的结果缓存 5 分钟客户端把最近一次成功返回的列表存进本地数据库。这样即使断网用户打开列表页看到的也是上次的数据而不是一片空白。降级提示我放在了页面顶部一条很轻的横条当前为离线数据。提示缓存一定要设过期时间和清理入口。我在设置页加了一个清除缓存按钮看起来是个小功能但答辩演示的时候很有用——老师看到你考虑了这个会觉得你在认真做产品而不是交作业。服务端缓存的伪代码大概是这样重点是先查缓存、未命中再查库、查完回填这个顺序不能乱public ListSpotVO listByCategory(String category, int page) { String key spot:list: category : page; Object cached cache.get(key); if (cached ! null) { return (ListSpotVO) cached; } ListSpotVO list spotMapper.selectByCategory(category, page); cache.set(key, list, 300); // 5 分钟 return list; }看着简单但坑在于写操作之后必须删缓存。我在新增评价、更新景点信息的两处逻辑里都加了删除对应 key 的代码。漏一处就会出现数据更新了但页面不变的诡异现象。5.2 基于地理围栏的到达提醒怎么算到达景点附近时提醒用户这个功能听起来很高级实现起来其实不难关键是想清楚计算方式。最朴素的做法是定时轮询位置每隔一段时间取一次当前坐标和所有景点的坐标算距离小于阈值就提醒。这个方案的缺点是耗电、耗流量而且位置更新频率低的时候反应慢。我实际采用的是客户端本地计算 距离预筛先把景点坐标一次性拉到本地数据量不大几百个点定位回调触发时在本地做一次距离计算。距离计算不用精确的大地测量公式用等距圆柱投影的近似算法就够了误差在几百米以内对于是否进入 1 公里范围这个判断完全够用// 近似距离计算单位米 private double roughDistance(double lat1, double lng1, double lat2, double lng2) { double x Math.toRadians(lng2 - lng1) * Math.cos(Math.toRadians((lat1 lat2) / 2)); double y Math.toRadians(lat2 - lat1); return Math.sqrt(x * x y * y) * 6371000; }为什么要用近似而不是精确公式因为这是一个高频调用的函数在定位回调里每次都要对几百个点跑一遍。精确公式里有大量三角函数开销大约是近似算法的三倍。而我们的判断阈值是公里级的近似算法几十米的误差完全可以忽略。这就是典型的精度换性能而且是安全的换法。再补一个细节提醒要做去重。用户在一个景点附近待半小时定位回调可能触发几十次不能每次都弹提醒。我的做法是给每个景点记一个最近提醒时间同一个景点在两小时内只提醒一次。5.3 行程规划的数据结构与排序算法行程规划是这个小系统里逻辑最绕的地方值得单独说。用户的操作有这么几种往某一天加一个景点、从某一天删一个景点、把景点从第二天拖到第三天、调整某一天内的顺序、查看某一天的总费用和总耗时。每一种操作背后都是对trip_item表的增删和sort_order的重排。顺序调整的经典坑是断层。假设某天有 A、B、C 三条sort_order分别是 1、2、3。现在删掉 B剩下 A(1)、C(3)中间断了。下次插入新项时如果取max(sort_order)1得到 4排序结果是 A、C、新项逻辑上没问题。但如果按取当前条数1来算得到 3和 C 冲突了。所以统一用max1永远不用条数1这是最简单也最不容易出错的规则。跨天拖动需要同时改day_index和重排目标天的sort_order。我的实现是把目标天的所有项重新编号1、2、3……一次性批量更新。虽然写起来多几行但保证了不会出现重复序号。还有一个容易忽略的点是费用合计。每个行程项有cost字段行程详情页要显示第 N 天合计和全程合计。这两个值不要每次都去数据库聚合而是在返回行程详情时由服务端算好一起返回。因为前端拿到列表后自己算也可以但一旦分页加载就会算错统一在服务端算更稳妥。6. 开题报告怎么写才不像填空开题报告这块我得多说几句因为源码开题这个组合说明读者里有一大部分是在准备选题材料。开题报告最容易犯的毛病是空话密度太高研究背景写三段宏观形势技术路线写五个框架名字进度安排画个甘特图创新点写界面美观、操作便捷。老师一眼就能看出来这是模板。6.1 研究背景与意义的写法陷阱研究背景别从旅游业的蓬勃发展写起这个开头已经被用了成千上万次而且和你这个项目没有任何关系——你做一个 App跟行业大盘增长没有因果关系。背景应该写具体场景下的具体问题。比如可以这样切入某类旅游目的地的信息获取存在明显的不便利——景点分布在广阔的地理范围内用户在做行前规划时需要在多个信息源之间来回切换且已有的行程编排工具大多是通用型的不针对这类目的地的空间分布特征做优化。这就是一个具体问题而且它直接对应到你要做的按距离排序 行程编排这两个功能。研究意义也一样别写促进旅游业发展写你自己的项目能带来的直接改变把分散的景点信息、距离关系、行程编排整合到一个入口减少用户在多来源之间切换的成本。这句话就是你的功能目标答辩时也能拿它当设计依据来讲。我个人的经验是背景和意义加起来不要超过八百字但每一句都要能对应到后面的某个功能或某个设计决策。写完之后做个自检——随便挑一句话问自己这句话对应我哪个功能对应不上的就删。6.2 技术路线、进度安排与创新点的可信度技术路线部分最忌讳名词罗列。不要写采用前后端分离架构前端采用跨端框架后端采用主流服务端框架数据库采用关系型数据库——这是选型结果不是技术路线。技术路线要写的是数据怎么流、模块怎么分、关键问题怎么解。比较可信的写法是这样组织客户端负责界面渲染与设备能力调用服务端提供 RESTful 接口数据层负责持久化缓存层负责高频读接口加速客户端与地图能力之间通过官方插件桥接行程、订单等有状态业务的数据一致性由服务端保证。这样写每一句都能在代码里找到对应物。进度安排要避免平均分配。很多人的安排是每周做一行看起来整齐实际上完全不真实。真实的开发节奏是前松后紧、中间有返工。我的建议是按阶段划分并且明确标出风险阶段需求与原型 2 周、数据层与核心接口 3 周、客户端页面 4 周、联调与修复 3 周、文档与答辩准备 2 周。其中联调与修复标注为风险最高因为这一阶段最容易超期。主动写出风险反而显得你有经验。创新点这个词有点大我建议改成本项目的差异化设计写两到三条具体的、能被验证的针对景点空间分布分散的特点在列表与行程编排中引入距离因素支持就近排序与就近推荐针对户外场景网络不稳定的情况设计了客户端数据与图片的两级缓存以及断网降级展示将行程按天分组并支持顺序调整形成可保存、可复用的行程数据而不是一次性浏览。这三条都来自实际功能都能在演示时点出来比界面友好、体验流畅这种话有用一百倍。7. 联调阶段的典型故障与排查链路前面都是设计层面的东西这一节讲讲真刀真枪的阶段。联调是这类项目最容易让人崩溃的环节因为问题往往不在代码逻辑而在环境、配置、协议这些边角上。我把自己遇到的几个典型故障和排查过程写下来你能少走不少弯路。7.1 接口通了但页面空白这个现象我第一次遇到时折腾了大半天。表现是用接口调试工具请求接口返回的数据完全正常JSON 结构也没问题但 App 里的列表页就是一片空白也不报错。排查链路是这样的建议按顺序走第一步先确认请求有没有真的发出去。在客户端的网络拦截器里打一行日志看请求有没有到达。结果是请求发了但响应体是空字符串。第二步看响应状态码。状态码是 200但内容长度是 0。这说明服务端返回了空内容但状态码正常。第三步看服务端的日志。服务端日志显示查询语句执行了返回了 12 条记录。问题出在序列化环节——接口返回的是一个包装对象里面的data字段是ListSpotVO但SpotVO里的日期字段在序列化时抛了异常被全局异常处理器吞掉了返回了一个空体。第四步定位到具体字段。加上详细日志后确认是时间字段的格式问题数据库里是datetime实体类里是LocalDateTime序列化配置里没有注册对应的格式化模块。这个问题的根因是全局异常处理器把异常静默处理了。这是个很常见的坏习惯——为了不让用户看到报错把所有异常都捕获后返回统一提示。结果是问题被藏起来了。我的改法是全局处理器只处理业务异常系统异常必须打完整堆栈同时在开发环境把详细错误信息返回给客户端。上线前再关掉详细信息的开关。现象可能原因验证方式页面空白无报错返回体为空、字段解析失败看响应体长度、看序列化日志列表有数据但不显示字段名大小写不一致对比接口返回字段名与实体字段名图片全部裂开URL 拼接规则错误、存储桶权限浏览器直接访问图片 URL点击跳转无反应路由参数类型不匹配打印路由参数另一个高频问题是字段名不一致。服务端返回的是下划线命名客户端按驼峰解析结果全是 null。这类问题排查起来很快但定位之前很折磨人。解决办法是从第一天起就统一命名规范别指望后面统一改。7.2 真机与模拟器的行为差异模拟器跑得好好的一上真机就出问题这是移动端开发的经典场景。我遇到的两个第一个是定位。模拟器可以随意设置一个坐标真机上的定位需要权限授权而且首次定位往往有延迟。表现是页面打开时地图中心点跳到默认位置而不是用户当前位置。原因是代码里默认认为定位回调一定会及时返回没有处理超时。改法是加一个超时兜底3 秒内没有定位结果就用景点的中心坐标作为初始中心点同时提示用户未获取到定位已使用默认位置。第二个是图片加载。模拟器网络快图片几乎瞬间加载完成所以我的加载占位处理写得很随意。真机上网络慢占位图尺寸和实际图片比例不一致页面会剧烈跳动。解决办法是服务端返回图片宽高信息客户端按宽高比预留空间。如果服务端拿不到宽高就在上传图片时就算好存进数据库。这个改动看似麻烦但解决了列表滚动时的抖动问题体验提升非常明显。还有一个真机特有的问题应用切到后台再回来页面状态丢失。原因是后台时系统回收了部分内存。检查一下是不是某个全局状态存在了内存里而没有持久化比如登录 Token 存的是变量而不是本地存储。改成持久化存储后问题消失。8. 答辩与源码交付把工作量讲清楚的几个细节代码写完之后还有两件事要处理怎么讲怎么交。这两件事做得好能把你的实际工作量放大做得不好做得再多也显得单薄。演示路线的设计。别从首页开始一个个点菜单那是功能罗列。设计一条真实的使用路径打开 App 看到附近景点讲距离排序→ 选两个景点加进行程讲行程数据结构→ 第二天打开看到行程详情和费用合计讲数据聚合→ 断网后数据仍在讲缓存降级→ 提交一个订单讲状态机。一条路线走完你的核心技术点全讲到了而且是在真实场景里讲的比对着 PPT 念有说服力得多。源码的组织方式。交付的代码结构要能一眼看出分层客户端按页面、组件、数据访问分层服务端按接口层、业务层、数据访问层分层。命名要规范别出现test1、aaa、TestController2。可以写一个简单的说明文档列出目录结构和每个目录的职责再附一份从零启动的步骤——数据库脚本在哪、配置文件要改哪几项、依赖怎么装。这份文档花不了两小时但能体现你的工程素养。被问到哪些是你自己写的怎么办。这个问题的正确回答方式不是罗列代码行数而是讲决策为什么选这个架构、为什么这张表要这么设计、为什么这个功能用这种算法。决策是你独有的代码可能是抄的但决策思路抄不来。所以准备答辩的时候重点准备为什么而不是是什么。最后分享一个我个人在做这类项目时体会最深的事把时间花在想清楚上比花在写代码上更划算。我第一版是边想边写写到第三个功能时发现表结构不对返工花了三天第二版我花了整整两天时间只画图和写接口文档一行代码没写然后再动手十天就把核心功能全跑通了。这个比例大概是二八开——两成时间想八成时间写但想的那两成决定了后面八成顺不顺。如果你正在做这个题目建议先别急着搭环境把第 2 节的模块清单和第 4 节的表结构对着自己的需求过一遍看看哪些该砍、哪些字段该加。这一步做完后面的路会顺很多。