企业官网建设流程全解析

每年到了这个时候，总有一批计算机专业的同学在毕设选题上犯难。你要是也正在纠结做什么题目，又对Spring Boot这套技术栈比较熟，那"交通线路查询系统"确实是个性价比很高的选择。别小看这个题目，它看着朴实，但真要做得像模像样，里面涉及的技术点一点都不少：后端接口设计、数据库建模、算法逻辑（比如换乘方案计算）、前端交互展示、甚至地图可视化都能塞进去。不管你是想拿它当毕业设计，还是纯粹想练手做个能写进简历的项目，这篇内容都够你参考一阵子。

我先说下我做这个系统时的总体感受：这个题目的核心难点不在CRUD，而在"线路查询"这四个字背后的数据组织和换乘算法。你只要把这两块想清楚，整个项目的骨架就立住了。接下来我会从设计思路、技术选型、关键实现到常见坑位，把整个过程完整拆开讲。

1. 项目定位与整体设计思路

1.1 功能需求梳理

交通线路查询系统，说到底解决的是用户的出行问题：我想从A点去B点，有哪些公交或地铁线路可以坐？怎么换乘最方便？首末班车是几点？系统需要把这些信息快速、准确地呈现给用户。

在做需求分析时，我习惯先把自己当成真实用户，列出一张使用场景清单。这张清单决定了系统必须包含哪些功能模块：

• 线路查询：这是核心中的核心。用户输入起点站和终点站，系统返回可乘坐的线路方案，包括直达、一次换乘、两次换乘。
• 站点查询：输入站点名称，系统展示经过该站点的所有线路列表，以及每个线路在该站的停靠时间和方向。
• 线路详情：点击某条线路后，可以查看它的完整途经站点、运营时间（首班/末班）、票价信息、线路类型（公交还是地铁）。
• 个人中心：包含用户注册登录、收藏常用线路、查看查询历史。
• 后台管理：管理员登录后维护基础数据，包括站点的增删改、线路信息的维护、线路与站点关联关系的配置。

有同学可能会问，毕设有必要做后台管理吗？我的经验是很建议加。评阅老师看的不只是功能，还有你的工程化思维。后台管理模块能把整个系统的数据流转闭环打通，让你在论文里多写出一章的完整设计，答辩的时候也更有东西可讲。

1.2 技术选型白板

技术选型上，我建议走一条"稳中带亮点"的路线。主体框架用Spring Boot，这是国内Java方向最主流的框架，几乎成了企业级开发的事实标准。前端这块，如果对Vue有基础，用Vue3配合Element Plus做管理后台和查询页面；如果时间紧张，直接用Thymeleaf模板引擎做服务端渲染也能交出不错的成果。我这里更推荐前后端分离的方案，一是更贴近企业真实开发模式，二是论文里可以多写一章"前后端分离架构设计"，用词都能显得高级不少。

数据存储用MySQL，8.0版本完全够用。持久层框架我选了MyBatis-Plus，这东西真是个开发效率神器。单表CRUD基本不用写SQL，复杂的多表关联查询再用注解或XML文件手动编写，兼顾了效率和可维护性。

这里有个很关键的选择：Spring Boot的版本。我强烈建议用2.7.x系列，而不是最新的3.x。原因很简单：3.x版本要求JDK 17起步，而且很多第三方组件的兼容性还没有完全跟上。毕设场景下追求的是稳定可靠，与其折腾版本兼容问题，不如把时间花在业务实现上。JDK用8或11都可以，Maven做依赖管理，开发工具用IDEA社区版就足够了。

提示：如果你在创建项目时发现IDEA里只有Spring Boot 3.x的选项，可以在start.spring.io这个网站上手动选择2.7.x版本生成项目包，再导入IDEA。这个方法比重置本地Spring Initializr配置要简单得多。

2. 后端核心架构与代码组织

2.1 工程目录结构与分层设计

好的工程结构能让你少走很多弯路。我是按经典的分层架构来组织的，每层职责单一，代码看起来非常清爽：

com.example.transit ├── controller # 控制层，接收请求并返回结果 ├── service # 业务层，处理核心业务逻辑 │ └── impl # 业务接口实现 ├── mapper # 数据访问层，MyBatis-Plus提供的Mapper接口 ├── entity # 实体类，对应数据库表结构 ├── dto # 数据传输对象，用于接口参数的接收和响应 ├── vo # 视图对象，用于给前端返回定制化数据 ├── config # 配置类（跨域、拦截器、MyBatis-Plus分页插件等） ├── common # 通用类（统一返回结果、异常处理、常量定义） └── TransitApplication.java # Spring Boot启动类

分层的好处是，你改业务逻辑不用翻控制层的代码，调整数据库字段不用动实体类以外的文件。每一层各司其职，出问题的时候能快速定位。很多同学在开发初期不喜欢这样分，觉得文件太多、麻烦。但项目一旦突破十几个接口，这种分层的价值就体现出来了。

控制层的代码我会尽量写得"薄"，只做参数接收、合法性和简单的数据处理，然后调用Service层的方法。业务层的职责是处理核心逻辑，比如换乘算法的计算、数据组装等。Mapper层就是纯粹的SQL交互，MyBatis-Plus的基础方法尽量复用，复杂查询才手动写。

2.2 统一返回结果和异常处理

写接口的时候，最怕的就是每个接口返回的数据格式都不一样，前端对接起来会疯掉。我从项目一开始就定义了一个统一的返回结果类Result，泛型设计，既能返回单个对象也能返回列表和分页数据：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

配合全局异常处理器@RestControllerAdvice，业务代码里拋出的自定义异常都会被统一捕获并转换成标准的错误JSON返回。这样做的好处很明显：前端只需要处理一种数据格式，拦截器里判断code是否为200即可，异常信息展示也标准化了。

我印象很深的是，在联调阶段，前端同学问我"为什么这个接口报错返回的字段和那个接口不一样"，我当时的系统里每个接口都是自己拼的返回体，改起来特别痛苦。后来重构成统一结构后，此类问题彻底消失了。这个教训让我在后续所有项目里都坚持使用统一返回结构。

2.3 跨域配置与拦截器

前后端分离开发时，跨域问题是绕不过去的坎。前端跑在8080端口，后端跑在8081端口，浏览器会拦截跨域请求。解决办法是配置一个CorsFilter或者实现WebMvcConfigurer接口：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意，allowCredentials(true)和allowedOriginPatterns("*")都是在较新版本Spring Boot里的写法。早期版本用allowedOrigins("*")在携带Cookie时会报错，这个坑我踩过。另外，接口路径如果是/api/**这种统一前缀，跨域配置里也要对应匹配。

拦截器主要用于登录认证。我写了一个LoginInterceptor，在preHandle方法里校验请求头中的Token。用户登录成功后，后端签发一个JWT Token并返回，前端在后续请求的请求头里携带它。校验失败时直接返回401状态码，配合前端的路由守卫实现未登录跳转。为了让拦截器放行登录接口和线路查询接口，在注册拦截器时用excludePathPatterns排除掉这些白名单路径。

3. 数据库设计与核心数据模型

3.1 数据表设计与字段规划

数据表是整个系统的地基，设计得不好，后面写什么功能都别扭。我最终设计了5张核心业务表，外加2张用户相关的表。每张表我都刻意做了一些设计上的取舍，不是为了多而多，而是为了满足真实业务场景。

站点表：

CREATE TABLE station ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '站点ID', station_name VARCHAR(100) NOT NULL COMMENT '站点名称', station_lat DECIMAL(10, 6) COMMENT '纬度', station_lng DECIMAL(10, 6) COMMENT '经度', station_type TINYINT DEFAULT 1 COMMENT '1-公交站 2-地铁站', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

线路表：

CREATE TABLE line ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '线路ID', line_name VARCHAR(50) NOT NULL COMMENT '线路名称，如3号线、K01路', line_type TINYINT COMMENT '1-公交 2-地铁', start_station_id BIGINT COMMENT '起点站ID', end_station_id BIGINT COMMENT '终点站ID', first_bus_time VARCHAR(10) COMMENT '首班时间 06:00', last_bus_time VARCHAR(10) COMMENT '末班时间 22:30', ticket_price DECIMAL(4, 1) DEFAULT 2.0 COMMENT '票价', distance_km DECIMAL(6, 2) COMMENT '总里程', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

线路站点关联表：

CREATE TABLE line_station ( id BIGINT PRIMARY KEY AUTO_INCREMENT, line_id BIGINT NOT NULL COMMENT '线路ID', station_id BIGINT NOT NULL COMMENT '站点ID', station_order INT NOT NULL COMMENT '站点在线路上的顺序，从1开始', direction TINYINT DEFAULT 1 COMMENT '方向：1-上行 2-下行', INDEX idx_line_station (line_id, station_order) );

这里有个设计上的思考值得说下。线路和站点是多对多的关系，所以必须要一个中间表去维护。我在中间表上加了station_order字段，这个字段在计算换乘方案时至关重要，它决定了两个站点在某条线路上谁是前谁是谁后，也决定了换乘方向是否合理。

用户表和用户线路收藏表也很关键。用户表用于后台管理员的账号验证；用户线路收藏表则通过外键关联到用户ID和线路ID，当用户点击收藏线路时，后台会自动检查是否已收藏，避免重复插入。

3.2 关键查询的SQL实现

站点查询的功能很简单，就是一个like模糊查询：

SELECT * FROM station WHERE station_name LIKE CONCAT('%', #{keyword}, '%');

线路详情查询稍微复杂一点，需要把线路基本信息和所有途经站点一次性查出来。我的做法是先查线路基本信息，再根据line_id查询关联的站点列表，最后手动组装成LineDetailVO返回给前端。这样做要好过一次性使用复杂Join，因为业务逻辑更清晰，以后加字段也好维护。

换乘查询是整个系统最核心的SQL逻辑之一。我先查起点站所在的所有线路，再查终点站所在的所有线路，然后通过交集判断是否存在直达方案：

// 明确起点站和终点站，查找经过起点站的线路ID集合 List<Long> startLineIds = lineStationMapper.selectLineIdsByStationId(startStationId); // 查找经过终点站的线路ID集合 List<Long> endLineIds = lineStationMapper.selectLineIdsByStationId(endStationId); // 取交集，得到可直达的线路 startLineIds.retainAll(endLineIds);

这个retainAll操作在数据量不大时性能完全够用，逻辑上也很清晰。数据量达到百万级以上才需要考虑更复杂的图算法和索引优化，毕设场景下完全没有必要过度设计。

4. 换乘算法与线路推荐逻辑

4.1 直达查询与一次换乘

换乘算法是这类系统的灵魂。我先明确一下问题定义：已知站点集合S、线路集合L、线路与站点的关系R（某条线路经过哪些站点以及顺序），给定起点站A和终点站B，求所有可行的乘车方案。

直达方案最简单，判断A和B是否在同一条线路上，并且A在线路上的顺序号小于B即可（方向要一致）。如果有，说明可以直接坐这条线路，无需换乘。

一次换乘要复杂些。基本思路是：

1. 找到所有经过A站的线路集合L1，对L1中的每条线路line1，找出线路上所有站点集合S1。
2. 找到所有经过B站的线路集合L2，对L2中的每条线路line2，找出线路上所有站点集合S2。
3. 如果S1和S2有交集，说明存在换乘站点C，用户可以先坐line1到C站，再换乘line2到达B站。
4. 换乘站C可能有多个，需要按换乘站距离A和B的总站数进行评估，站数少的方案优先展示。

这个算法的时间复杂度大致是O(|L1| * |L2| * m * n)，m和n分别是两条线路的平均站数。实际数据规模下完全能接受。

4.2 两次换乘与推荐排序

两次换乘的实现思路和一次换乘类似，但从"线路-站点"的维度变成了"站点-线路"的维度。我的做法是：

1. 找到经过A站的线路集合L1，以及这些线路覆盖的所有站点集合T1。
2. 遍历T1中的每个换乘站点C1，找到经过C1的所有线路集合L1_2，再找出这些线路覆盖的所有站点集合T2。
3. 如果T2中存在站点C2，且C2与B在同一条线路上，则方案成立：A坐某线路到C1，换乘另一线路到C2，再换乘一条线路到B。
4. 如果T2中直接存在B，说明两次换乘可以简化成一次换乘，优先输出更优方案。

这个思路本质上是一个广度优先搜索的变体，只是我把它用两层循环实现出来了。算法的终止条件很明确：遍历完所有站点和线路组合后没有生成新的方案，或者方案数量达到预设上限（比如20条），就停止计算。

得到所有方案后，需要对它们进行排序。我的排序规则是综合评分制，考虑四个维度：总站数（等权重占比最高）、换乘次数、步行距离（如果有的话）、票价。默认按总站数和换乘次数升序排列，但在前端展示时会把换乘次数少但总站数稍多的方案排在前面。实际体验下来，用户更愿意接受"少换乘，多坐一站"的方案，所以这个排序策略是符合用户心理的。

4.3 通过Redis缓存高频查询

每次用户查询都要做一次全量线路分析，虽然数据量不大，但当系统并发上来后，重复计算的开销不容忽视。我引入了Redis做缓存，以"起点站ID:终点站ID"为Key，把查询结果序列化成JSON后存储，过期时间设置为一小时。效果非常明显，第二次查询同一个起终点时直接读缓存，接口响应时间从几十毫秒降到几毫秒。

public QueryResult queryTransfer(String startStationName, String endStationName) { // 先把站点名称转成站点ID Long startId = stationService.getIdByName(startStationName); Long endId = stationService.getIdByName(endStationName); String cacheKey = "transfer:" + startId + ":" + endId; // 先查缓存 String cachedResult = redisTemplate.opsForValue().get(cacheKey); if (StringUtils.isNotEmpty(cachedResult)) { return JSON.parseObject(cachedResult, QueryResult.class); } // 缓存未命中，执行换乘计算 QueryResult result = transferService.calculateTransfer(startId, endId); // 写入缓存 redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(result), 1, TimeUnit.HOURS); return result; }

这个缓存策略的实现难度不高，但给系统带来的性能提升是很直观的。毕设里提到Redis，一般出现在"系统优化"或者"缓存设计"章节，这也是一个不错的加分项。不过要注意，当后台修改了线路数据时，需要主动删除相关缓存，否则会出现数据不一致。我写了一个简单的缓存清理方法，在线路更新的Service里调用：

public void clearLineCache(Long lineId) { // 通过线路ID查询所有相关站点后，构造缓存Key并删除 Set<String> keys = redisTemplate.keys("transfer:*"); redisTemplate.delete(keys); }

提示：实际生产环境中不要用keys *这种全量查询操作，它在大数据量下会阻塞Redis。毕设场景问题不大，但你可以在论文里优雅地解释为"实际生产采用SCAN命令替代，避免阻塞"。

5. 前端界面设计与交互实现

5.1 Vue3 + Element Plus搭建查询页面

前端这块我用的是Vue3 + Vite + Element Plus + Axios的组合，通过前端代理解决开发环境的跨域问题。整个页面结构分成三大块：顶部导航栏、中部查询区、底部方案展示区。

查询区是这个系统的门面，UI设计上我借鉴了主流地图软件的做法：两个输入框分别填起点和终点，中间有个交换按钮，点击后起点和终点互换。输入框做了自动补全功能，输入字符时向后端拉取站点名称数据源，弹出下拉选项让用户选择。这个小功能提升了真实可用性，演示时也会给人留下"这系统是认真做了的"印象。

查询按钮的交互逻辑是：先校验起点和终点不能为空、不能相同，然后调用后端接口。等待响应期间显示Loading动画，防止用户重复点击。数据返回后，左边展示方案列表，右边通过高德地图JS API展示途经站点的可视化路线。

5.2 地图可视化的接入细节

地图可视化功能是点睛之笔，它不是必需项，但加了之后整个项目的完成度立刻不一样。我接入的是高德地图的JS API，在index.html中引入JS文件，并配置自己的Key：

// main.js 中初始化地图 const map = new AMap.Map('mapContainer', { zoom: 12, center: [116.397428, 39.90923] // 默认中心点 });

拿到后端返回的站点坐标列表后，用AMap.Polyline绘制线路连线，用AMap.Marker标记每个站点。点击方案列表中的某一个方案时，地图自动切换到该方案的线路，并调整视野缩放级别适配线路范围。

这里有个经验：站点经纬度数据一定要在数据库设计阶段就规划好，不然后期补数据非常痛苦。我建议在后台管理的站点维护页面提供"百度/高德坐标拾取器"链接，管理员录入站点时直接在地图上点选，自动填入经纬度。

5.3 后台管理界面的增删改查

后台管理页面的技术栈还是Vue3 + Element Plus，但页面逻辑更加直接。站点管理表格支持分页、搜索、新增、编辑、删除操作。线路管理稍微复杂点，因为需要维护线路与站点的关联关系。前端做一个站点选择器，管理员新增线路时选择线路类型、填写首末班时间，然后按顺序从可用站点列表中添加线路经过的站点。这个功能看似简单，但实际上是后台管理系统里最耗时间的一块，因为涉及的操作比较细碎。

前端页面和后端接口通过Axios通信，我封装了一个request.js工具类，在请求拦截器里统一加上Token请求头，在响应拦截器里统一处理错误码：

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code === 200) { return res; } else { ElMessage.error(res.message); return Promise.reject(new Error(res.message)); } }, error => { ElMessage.error('网络请求异常'); return Promise.reject(error); } );

这样封装的好处非常明显，前端代码中不需要在每个接口调用处写一堆错误处理逻辑，统一在拦截器里完成即可。如果后端返回401（Token过期），还能在这个地方统一跳转到登录页面，省得每个页面单独判断。

6. 项目部署与常见问题排查

6.1 打包部署的完整流程

项目的部署我采用的是经典的前后端分离部署方式。后端项目使用Maven的package命令打成jar包，然后在服务器上通过java -jar命令启动。在打jar包之前，记得先执行测试跳过：

mvn clean package -DskipTests

打包完成后，jar包一般位于target/目录下。如果项目依赖了外部配置文件，可以通过--spring.config.location参数指定外部配置文件路径，这样每次更新代码只需要重新上传jar包即可，不会覆盖生产配置。

前端项目构建相对简单，在项目根目录执行npm run build，生成静态文件到dist目录，然后把整个目录上传到Nginx的html目录下。Nginx除了托管前端静态文件外，还需要配置API的反向代理，把/api请求转发到后端服务：

server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这份配置里有两个细节值得注意：try_files确保前端路由的history模式刷新页面时不会404；proxy_pass最后的斜杠表示反向代理时去掉/api前缀，这样后端接口不需要额外处理前缀，保持Controller路径简洁。

6.2 Spring Boot版本过高导致的传统JDK兼容问题

用Spring Boot 3.x配合JDK 8启动项目时，大概率会遇到各种版本的兼容性错误，比如Unsupported class file major version之类的提示。当年我在做毕设的时候就踩过这个坑，后来总结出的应对方案是：

• 一是检查pom.xml中java.version是否为1.8。
• 二是检查Spring Boot版本，3.x版本强制要求JDK 17及以上，选择2.7.x版本。
• 三是如果IDEA中创建时默认使用了过高的JDK版本，需要在Project Structure中把Project SDK和Modules的语言级别都改为8。

类似的，如果项目是小白运行别人的代码，可能还会遇到Maven仓库依赖下载失败的问题。此时要检查本机Maven的settings.xml文件，看镜像源是否配置了阿里云仓库：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

换完镜像源后先clean再reimport，大部分依赖下载问题都能解决。

6.3 接口测试工具与常见HTTP状态码排错

开发过程中我习惯用Apifox调试接口，它和Postman功能类似，但团队协同和文档生成能力更强。每个接口都要测试正常参数、异常参数、空值参数三种情况。特别是Spring Boot的@RequestBody接收JSON数据时，前端传参格式和后端实体类字段不一致，很容易报HttpMessageNotReadableException，这类问题在联调阶段非常常见。解决方法是统一前后端字段命名规范，比如数据库用下划线，实体类用驼峰，JSON也统一用驼峰，利用map-underscore-to-camel-case配置自动映射。

另一个高频报错是404。出现这个问题的原因是接口路径写错了，或是Controller类上没有加@RestController注解。排查时先看后端日志，再让前端打开浏览器控制台查看实际请求的URL和返回状态码。我用得很频繁的一个方法是直接在后端Controller方法上加日志，打印接收到的参数，帮助判断是不是参数传递环节出了问题。

6.4 部署环境的坑：数据库连接和初始化数据

一个特别容易踩坑的地方是数据库连接配置。本地开发时用localhost:3306没问题，部署到服务器后必须改成服务器的数据库地址。如果数据库版本是8.0，还需要在JDBC连接串中加上时区参数：

spring: datasource: url: jdbc:mysql://localhost:3306/transit_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver

数据库初始化数据一定要在系统演示前导入。我准备了两个SQL脚本：一个是建表脚本schema.sql，一个是模拟数据脚本data.sql。模拟数据里包含了20条公交线路、5条地铁线路、200多个站点，这些数据覆盖了直达查询、一次换乘、两次换乘和无法到达等各种场景。这样演示时不管怎么输入，系统都能给出合理反馈，不会出现空数据的尴尬。

7. 优化方向与答辩准备心得

7.1 从毕设到开源项目的进阶方向

如果你把这个系统做完了，想再往上走一步，有几个非常不错的优化方向可以尝试：

• 引入Elasticsearch做站点搜索，让模糊查询的速度更快，具备更强的纠错能力。
• 把换乘算法升级为Dijkstra或A*算法，基于站点路网计算最短时间或最少换乘方案。
• 接入高德或百度地图的实时路况信息，预测乘车时长。
• 前端引入ECharts做乘客流量数据可视化，展示各线路的热度排行。

这些扩展点不太多，但每一个都能单独写一篇功能说明或论文章节。答辩的时候，老师如果问"这个系统未来有哪些改进方向"，你能从算法、性能、功能体验多维度展开，效果会很加分。

7.2 答辩中容易被追问的问题整理

基于我的观察，评阅老师针对这类系统的提问集中在几个点上：

• 换乘算法的原理是什么？为什么不用Dijkstra？我的答法是：Dijkstra适合带权图的最短路径，而公交换乘场景的核心代价是换乘次数和总站数，用层级搜索的方式更直观，同时计算成本更低。
• 如何保证查询结果的实时准确性？我会说到缓存更新机制和数据源维护规范。
• 系统的性能瓶颈在哪里？怎么优化？这个问题是考察你对系统的整体理解，可以从数据库索引、Redis缓存、接口复用多个维度回答。
• 为什么选择MyBatis-Plus而不是JPA？这里可以从SQL可控性、学习成本和生态成熟度来答。

这些问题的回答思路在开发过程中其实早就形成体系了。只要你动手把项目从头到尾写了一遍，这些追问反而能帮你展示真正的工程能力。怕就怕照着别人的代码抄了一遍，什么都答不上来。

7.3 我个人做完这个项目后的几点体会

做完整个系统，我最大的体会是：一个看似普通的业务系统，想做到逻辑自洽、性能可用、代码整洁，需要思考的细节远比想象中多。尤其是换乘方案的排序策略，我一开始只是简单按总站数排，但测试后发现用户更关心"换乘次数少"的方案，于是调整为多因素加权排序，才算真正贴合使用场景。这种体会不做项目永远得不到。

最后再分享一个很实在的小技巧：开发过程中保持"每完成一个功能就顺手更新接口文档"的习惯。不管是自己写的Markdown接口说明，还是用Apifox自动生成的文档，都要保证它是最新的。很多时候答辩前几天你会发现自己在翻几个月前的笔记，而文档混乱会让整个准备过程变得很崩溃。项目完成后，把代码传到GitHub或Gitee上，写好README，附上演示截图和核心设计文档。这些都不需要太多额外时间，但对作品呈现和后续找工作的简历补充都很有价值。