企业官网建设流程全解析

开头

这个题目我见过太多次了——“基于XX的旅游网站的设计与开发（源码+开题）”，每年选题季都会有一批人拿着几乎一样的标题来找我聊。说实话，旅游网站这个题目本身不难，难的是大部分人把它做成了“能跑起来的增删改查”，然后在开题答辩和最终验收的时候被问得哑口无言。旅游网站的设计与开发，本质上是把一个真实的业务场景（用户找目的地、看线路、比价格、下单、支付、评价、售后）压缩到一个可交付的工程量里，同时还要配上开题报告说清楚“为什么这么做”。配套的源码不是越多越好，而是要能讲清楚每一块的取舍；开题也不是套模板填空，它决定了你后面三个月是顺着走还是反复返工。

我把这篇东西写给三类人看：第一类是刚定下题目、还在纠结技术栈和功能清单的；第二类是代码写了一部分，发现订单、库存、图片这些地方越写越乱的；第三类是代码差不多能跑了，但开题报告和技术文档写不出来、答辩心里没底的。全文围绕一个通用技术路线展开（前端框架 + 后端服务 + 关系型数据库 + 对象存储），具体技术名词你按自己熟悉的替换即可，思路是通用的。里面会有表结构、代码片段、参数计算，也会有一些只有真正动手做过才会知道的坑——比如为什么你的线路详情页加载要三秒、为什么并发下单会超卖、为什么图片上传在本地好好的、一部署就 404。

1. 先把题目拆开：旅游网站到底要做成什么样

1.1 “基于XX”这四个字，决定了你一半的技术路线

很多人写题目的时候随手填个技术栈，等到中期检查才发现自己根本讲不清为什么选它。题目里的“基于XX”不是装饰，它是你整篇文档的技术主线：你后面所有的架构图、模块划分、部署方案，都要能回溯到这四个字上。

我的建议是把“基于”拆成三层来理解。第一层是运行形态——是单体应用还是前后端分离，是本地部署还是容器化部署。第二层是核心框架——后端用什么语言和框架，前端用什么框架，这决定了你的代码风格和目录结构。第三层是数据与中间件——数据库选关系型还是文档型，缓存要不要上，搜索用数据库模糊查询还是独立检索引擎。

对旅游网站这个场景，我给一个相对稳妥的组合：前后端分离的单体后端 + 关系型数据库 + 本地或对象存储放图片 + 一个轻量缓存。理由很实在——旅游网站的核心数据（用户、线路、订单、库存、评价）之间的关系非常强，线路属于某个目的地、订单关联用户和线路、评价关联订单，这种强关联用关系型数据库表达最自然，写 SQL 联表查询、做事务控制都顺手。如果你的题目写的是文档型数据库，那你得额外解释清楚“订单一致性怎么保证”，这是个给自己找麻烦的选择。

至于微服务，我劝退。一个课程级或毕业设计级的旅游网站，硬拆成五六个服务，带来的不是加分而是负担：服务注册发现、链路追踪、分布式事务，每一样都要写文档、都要在答辩时被追问。单体分模块（按 controller / service / mapper 分层，按业务域分包）已经足够体现工程能力，而且你能把精力放在业务逻辑上。

提示：题目里的技术栈一旦写进开题报告，后面改起来很麻烦。定之前先问自己三个问题：我能不能用它写出一个完整的增删改查？我能不能解释它在这个场景下的优势？我本地环境能不能稳定跑起来？三个都是“能”，再定。

1.2 功能清单应该怎么砍：三类角色、五个闭环

旅游网站的功能可以列出一百项，但你的时间只够做二十项。砍功能的标准不是“看起来酷不酷”，而是“能不能形成闭环”。我一般把功能按角色切三刀：游客/普通用户、注册用户、后台管理员。

普通用户侧需要形成的最小闭环是：浏览 → 检索 → 详情 → 下单 → 支付（模拟）→ 查看订单 → 评价。后台侧需要形成的最小闭环是：登录 → 线路/景点管理 → 订单管理 → 用户管理 → 内容（轮播、公告）管理。这两个闭环走通了，你的系统就是“完整”的，而不是“半截”的。

具体到功能模块，我整理成下面这张表，你可以直接拿去当开题报告的功能清单初稿：

砍功能的时候有个技巧：选做项不要删掉，写进“后续可扩展”里。开题报告的评审看的不是你做了多少，而是你有没有想清楚范围。你在文档里写“本期聚焦交易主链路，收藏与社交分享作为二期扩展”，比硬做十个半成品要专业得多。

1.3 先写文档还是先写代码：一个被低估的顺序问题

我的经验是：先画数据模型，再写开题，最后写代码。原因很朴素——开题报告里最难写的部分是“系统设计”，而系统设计的核心就是数据模型和模块划分。你如果先把表设计出来，开题报告的设计章节基本就是“把图翻译成文字”，半小时能写完；反过来，你先写一堆技术名词堆砌的文档，等真开始写代码会发现表结构跟文档对不上，来回改，文档和代码两边都烂。

具体操作上，我会先在一张纸上列出所有实体（用户、目的地、景点、线路、行程日、订单、订单明细、支付记录、评价、轮播图、管理员），然后画连线标关系：一对多、多对多。多对多的地方一定要有中间表。这一步花两个小时，能省掉后面两周的返工。

2. 数据模型：旅游网站真正的地基

2.1 核心表结构怎么设计才不别扭

旅游网站的数据模型有两个特点：一是层级多（目的地 → 景点 → 线路 → 行程日 → 行程项），二是状态多（订单有状态、支付有状态、线路有上架状态）。层级多容易设计成“一张表塞所有字段”，状态多容易设计成“一个字段存所有状态”。

先说层级。目的地和景点是一对多，景点和线路是多对多（一条线路会串多个景点），线路和行程日是一对多，行程日和行程项是一对多。这个结构不要偷懒合并，尤其是行程日单独一张表——因为详情页要按“第1天、第2天”渲染时间轴，你如果把它塞成一个 JSON 字段，后面想按天查、想排序就很痛苦。

下面是核心表的一个简化版本，字段名用下划线风格，你可以按自己的规范调整：

-- 用户表 CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(128) NOT NULL COMMENT '加盐哈希后的密码', salt VARCHAR(32) NOT NULL COMMENT '盐值', nickname VARCHAR(32) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL COMMENT '头像地址', phone VARCHAR(20) DEFAULT NULL, role TINYINT NOT NULL DEFAULT 0 COMMENT '0普通用户 1管理员', status TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0禁用', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; -- 线路表（核心商品） CREATE TABLE t_route ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(120) NOT NULL COMMENT '线路标题', dest_id BIGINT NOT NULL COMMENT '目的地ID', cover_img VARCHAR(255) NOT NULL COMMENT '封面图', days INT NOT NULL COMMENT '行程天数', price DECIMAL(10,2) NOT NULL COMMENT '成人价', child_price DECIMAL(10,2) DEFAULT NULL COMMENT '儿童价', stock INT NOT NULL DEFAULT 0 COMMENT '可售库存', sold INT NOT NULL DEFAULT 0 COMMENT '已售数量', themes VARCHAR(100) DEFAULT NULL COMMENT '主题标签,逗号分隔', status TINYINT NOT NULL DEFAULT 0 COMMENT '0下架 1上架', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_dest (dest_id), KEY idx_status_price (status, price) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='旅游线路表';

这里有几个点值得单独说。价格用 DECIMAL 而不是 DOUBLE，浮点数做金额计算会出现 199.99999999 这种事，等你做对账的时候会疯。库存和已售分成两个字段，而不是只存一个库存然后减掉——因为“已售”是要展示给用户看的（“已有 328 人预订”），也是后台统计要用的，两个字段各自维护比反推要清晰。主题标签用逗号分隔的字符串在课程级项目里是可以接受的，别硬上标签表，除非你确实要做标签筛选的多条件组合。

2.2 订单表：整个系统里最容易出事的一张表

订单表的坑主要在状态设计。我见过太多人把订单状态做成一堆布尔字段：is_paid、is_cancelled、is_refunded、is_finished。结果是“已支付且已取消”这种非法状态也能被组合出来，日志一看全是脏数据。

正确做法是单一状态字段 + 明确定义的流转图。我把状态定义成这样：0 待支付、1 已支付待出行、2 已完成、3 已取消、4 已退款。流转规则写死在服务层，任何非法流转直接抛异常。下面这张表就是我常用来做状态校验的：

另外，订单主表和订单明细表一定要拆开。主表存订单号、用户、总额、状态、联系人信息；明细表存“这条订单买了哪条线路、几个人、单价、小计”。为什么？因为后面你很可能要做“一单多线路”（购物车式下单），主表结构不用动，明细表加行就行。订单号别用自增 ID 直接暴露，用“日期 + 随机数 + 自增”拼一个业务单号，既好查又不泄露业务量。

2.3 索引与查询：让详情页从三秒变三百毫秒

索引这件事，不写不觉得，一写就知道疼。旅游网站最典型的查询是三种：按目的地 + 状态 + 价格排序的列表查询、按关键词的模糊搜索、按用户查订单。

第一种查询，索引建成(dest_id, status, price)这样的组合索引，注意顺序：区分度高的、等值条件在前，范围条件在后。你把 price 放前面，MySQL 用不上后面的 dest_id，这是很常见的失误。第二种模糊搜索，LIKE '%关键词%'是走不了索引的，数据量小的时候无所谓，数据量上万就开始卡。课程级项目里我的处理方式是：标题和简介拼接成一个search_text字段，用LIKE '关键词%'做前缀匹配（能走索引），同时对搜索结果按“标题命中优先、简介命中其次”排序。第三种订单查询，建(user_id, status, create_time)组合索引，用户中心的订单列表基本就是这个查询模式。

还有一个容易被忽略的点：详情页的 N+1 查询。线路详情要展示目的地名、行程日列表、每天的景点、评价列表、评价人昵称——如果你一个线路查一次，然后循环里再查，五次查询变五十次。解决办法是用联表查询一次拿到主数据，再用IN批量查关联数据，在服务层组装。我实测过一条线路详情：改成批量查询之后，接口耗时从 800ms 降到 90ms 左右，差距全在往返次数上。

3. 后端核心功能：把主链路一条条打通

3.1 用户认证与权限：别自己发明加密方案

用户模块看着简单，但它是安全问题的重灾区。我见过最离谱的做法是数据库里存明文密码，稍微好一点的是 MD5 直接存。这两种都不行。

正确做法是每个用户一个随机盐 + 慢哈希。注册时生成 16 位随机盐，密码和盐一起做哈希（比如 BCrypt 或者 PBKDF2，迭代次数别太低），数据库只存盐和哈希值。登录时用同样的方式算一遍对比，全程不落明文。这里我要强调一句：不要自己写加密算法，也不要用简单的“MD5(密码 + 固定字符串)”，固定盐等于没盐，撞库一撞一个准。

登录态用 Token 方案比较省事：登录成功后服务端签发一个带过期时间的 Token，前端存起来，之后每次请求放在请求头里，服务端拦截器统一校验。Token 里放用户 ID 和角色，不要放敏感信息，因为它是可解码的。拦截器里顺便把“哪些接口需要登录、哪些接口需要管理员角色”配置成白名单/黑名单，比在每个接口里写判断要干净：

// 拦截器中的权限判断（示意） @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String uri = request.getRequestURI(); // 白名单直接放行 if (WHITE_LIST.contains(uri)) { return true; } String token = request.getHeader("Authorization"); Claims claims = tokenService.parse(token); // 解析失败会抛异常 if (claims == null) { throw new BizException(401, "登录已过期，请重新登录"); } Integer role = claims.get("role", Integer.class); // 后台接口统一前缀 /admin，要求管理员角色 if (uri.startsWith("/admin") && (role == null || role != 1)) { throw new BizException(403, "无权限访问"); } request.setAttribute("userId", claims.get("uid", Long.class)); return true; }

这里有个实操细节：Token 过期时间别设太长也别太短。设 30 分钟，用户下单填一半被踢出去，体验极差；设 30 天，安全性又成问题。我的做法是访问 Token 设 2 小时，同时前端在快过期时静默刷新一次，用户几乎感知不到。另外，退出登录不是把前端存的 Token 删掉就完事——最好在服务端维护一个短期的失效名单（比如存到缓存里，键是 Token 的哈希，过期时间和 Token 一致），否则被截获的 Token 在过期前一直有效。

3.2 线路检索与分页：排序规则的细节决定体验

列表页是旅游网站的门面，用户在这里做决策。排序、筛选、分页三件事必须做好。

分页我建议服务端分页，别图省事一次查出全部然后前端切页。线路数据上万条的时候，一次全查内存直接爆。服务端分页的关键是“查询总数 + 查询当页数据”两条 SQL，且两条 SQL 的 where 条件必须完全一致——我遇到过很多人写的时候，count 语句漏了一个筛选条件，导致分页器显示 20 页，点到第 8 页就没数据了。

排序规则要写清楚优先级。默认排序我一般这么定：上架状态优先 > 是否有库存 > 销量降序 > 价格升序 > 上架时间降序。为什么要加“是否有库存”这一层？因为用户看到一个卖完的线路排第一，点击进去发现不能买，体验很糟。库存为 0 的线路应该沉底或者打上“已售罄”标签。

筛选条件里价格区间的处理要注意：用户传进来的是“最低价-最高价”，但你的数据库存的是单价。这时候不能简单price BETWEEN min AND max，因为线路可能有成人价和儿童价，用户期望的是“这条线路有任何一种价格落在区间内”。这是个业务理解问题，不是技术问题，但很多人想不起来。我的处理是给线路冗余一个min_price字段，下单时按最便宜的算，筛选只查这一个字段。

3.3 下单与库存：并发超卖的三种解法

这是整个项目最有技术含量的一块，也是答辩时最容易被追问的地方。“如果两个人同时买最后一张票，会怎么样？”——这个问题你答不好，前面的功能做得再花哨也会被扣分。

问题本质是：UPDATE t_route SET stock = stock - 1 WHERE id = ?这条语句在并发下会读到同一个库存值，然后各自减一，库存变成 -1，也就是超卖。

解法一，悲观锁：在事务里SELECT ... FOR UPDATE锁住这行，其他人排队等。简单可靠，但并发一高就排队，响应变慢。解法二，乐观锁：表里加个version字段，更新时带WHERE version = 旧值，影响行数为 0 就说明被改过，重试或报错。适合冲突不频繁的场景。解法三，条件更新：直接UPDATE t_route SET stock = stock - 1, sold = sold + 1 WHERE id = ? AND stock >= 1，看影响行数判断是否成功。这是我最推荐的方式，一条 SQL 搞定，不需要额外字段，也不会有长时间锁等待。

@Transactional(rollbackFor = Exception.class) public Long createOrder(Long userId, Long routeId, int quantity) { // 1. 条件更新扣减库存，影响行数 = 0 说明库存不足 int affected = routeMapper.deductStock(routeId, quantity); if (affected == 0) { throw new BizException("该线路库存不足，请选择其他日期或线路"); } // 2. 生成订单主表 Order order = new Order(); order.setOrderNo(orderNoGenerator.next()); order.setUserId(userId); order.setStatus(OrderStatus.UNPAID.getCode()); orderMapper.insert(order); // 3. 生成订单明细（价格从数据库重新读取，绝不信任前端传值） Route route = routeMapper.selectById(routeId); OrderItem item = new OrderItem(); item.setOrderId(order.getId()); item.setRouteId(routeId); item.setPrice(route.getPrice()); item.setQuantity(quantity); orderItemMapper.insert(item); return order.getId(); }

对应的 Mapper SQL：

<update id="deductStock"> UPDATE t_route SET stock = stock - #{quantity}, sold = sold + #{quantity} WHERE id = #{routeId} AND status = 1 AND stock &gt;= #{quantity} </update>

这段代码里有两个细节值得强调。第一，价格必须从数据库重新查，前端传来的价格一律不信，否则改个请求参数就能一元游全国。第二，扣库存和建订单必须在同一个事务里，否则扣了库存订单没生成，库存就白白少了一个。第三，如果后面加了“超时未支付自动取消”，取消时要反向补库存，而且要用“只补一次”的幂等控制（比如状态更新带WHERE status = 0），不然重复回调会把库存补多。

注意：下单接口一定要做防重复提交。用户在手机上网络卡，连点两下“提交订单”，就生成两笔订单。做法很简单：前端提交后按钮置灰，后端对一个用户短时间内的重复请求做拦截（比如 3 秒内的相同参数只处理一次）。

3.4 图片上传：旅游网站的“半条命”

旅游网站是重图片的，封面图、轮播图、行程图、评价图，全是图。图片这块如果处理不好，会出现三个典型问题：上传后本地能看、部署后 404；图片太大导致列表页加载慢；换台电脑跑起来图片全丢了。

第一个问题，根源在存储路径。很多人把上传目录写成D:/upload/这种绝对路径，本地跑得好好的，部署到服务器上当然找不到。正确做法是配置一个可外部化的根路径，代码里拼相对路径存库，访问时通过静态资源映射或者统一的文件访问接口输出。

第二个问题，上传时必须压缩。手机拍的照片动辄三五兆，一个列表页二十张图就是上百兆。我一般在上传接口里做两件事：限制大小（比如单张不超过 5MB）、按最长边等比缩放到 1600px 以内再存。缩略图另外生成一份 400px 的，列表页用缩略图，详情页用大图。这一套做下来，列表页的加载时间能砍掉一大半。

第三个问题，本地存储换成对象存储。课程级项目用本地目录完全够用，但你要在文档里写清楚“如果上生产，建议替换为对象存储，只需改配置不用改业务代码”——这句话体现的是架构意识，评审老师很吃这一套。实现的技巧是把文件上传抽成一个接口（FileStorageService），本地实现和对象存储实现都实现这个接口，通过配置切换。

4. 前端页面与交互：让系统看起来像那么回事

4.1 页面结构规划：先画路由再写组件

前端最容易失控的地方是页面散、组件乱、接口调用到处写。开工前先把路由表列出来，我一般这么分：

路由规划清楚之后，组件拆分就有依据了：列表页的筛选栏、线路卡片、分页器，详情页的图片轮播、行程时间轴、评价列表、下单弹层——这些都是可复用的独立组件。新手常犯的错误是把所有东西写在一个页面文件里，一个.vue文件写到两千行，改一个地方要滚半天。

4.2 列表页与详情页的关键实现

列表页的核心是状态与 URL 同步。筛选条件、排序方式、页码都应该反映在 URL 上，这样用户刷新页面筛选不丢、分享链接别人能打开同样的结果。实现上就是监听路由参数变化，参数变了重新请求。很多人把筛选条件放在组件内部变量里，用户一刷新回到初始状态，这是个很小但很影响体验的细节。

详情页的核心是首屏速度。图片懒加载必须做，行程时间轴的数据可以随主接口一起返回（数据量不大），但评价列表单独分页请求，不要塞进主接口。下单弹层里的日期选择要限制“只能选今天之后”，数量要限制“不超过剩余库存”，这些约束前端要做，后端也要再做一遍——前端是体验，后端是底线。

4.3 接口封装与错误处理：统一比聪明重要

前端的接口调用一定要统一封装。我的做法是建一个请求工具文件，统一处理四件事：基础地址拼接、Token 自动携带、响应码统一判断、异常统一提示。

// 统一的请求封装（示意） async function request(url, options = {}) { const token = storage.get('token'); const res = await fetch(API_BASE + url, { ...options, headers: { 'Content-Type': 'application/json', ...(token ? { Authorization: token } : {}), ...(options.headers || {}) } }); const data = await res.json(); if (data.code === 401) { storage.remove('token'); router.push('/login'); throw new Error('请先登录'); } if (data.code !== 0) { // 统一弹提示，业务层就不用每处都写 toast(data.message || '请求失败'); throw new Error(data.message); } return data.data; }

这样写的好处是：后端改返回结构，你只改一处；登录过期统一跳转，不用每个页面都判断。坏处是容易把“业务错误”和“系统错误”混在一起，所以我在封装里区分了code的含义——401走登录跳转，403走无权限提示，其他业务错误统一 toast。

5. 开题报告：怎么写才不像模板填空

5.1 开题的标准结构与本项目的对应关系

开题报告的结构基本是固定的：选题背景与意义、国内外研究现状、研究内容与目标、技术路线与方案、进度安排、参考文献。真正拉开差距的是背景意义和技术路线两节，其他部分只要信息准确、格式规范就行。

背景意义不要写成“旅游业发展迅速，互联网普及率高”这种空话。要落到具体问题上：用户在做旅游决策时面临信息分散、比价困难、行程规划成本高；中小型旅游服务商缺乏低成本的自有展示与预订渠道。你的系统解决的是“把分散的目的地信息、线路产品、用户评价整合到一个可检索、可预订的入口”，这就是意义。前后呼应，评审一看就知道你想过。

技术路线要写选型理由，而不是罗列名词。写“后端采用某主流开发框架，前端采用某主流前端框架，数据库采用关系型数据库”是零分的写法。要写“后端选择该框架是因为其内置的依赖注入与事务管理能简化订单这类强一致性业务；前端选择该框架是因为组件化开发便于线路卡片、评价列表等模块复用；数据库选关系型是因为用户-订单-线路之间关联紧密，需要事务保证”。同样的技术，不同的表述，分数不一样。

5.2 创新点怎么写才不尴尬

“创新点”这个词对本科生项目很不友好，因为大部分项目确实没有学术创新。我的建议是不硬造创新，写“设计特点”，把你在工程上做的取舍讲出来，这本身就是价值。

比如这几条就很实在：一是库存扣减采用条件更新避免超卖，在高并发下单场景下保证数据一致；二是图片分级存储与压缩，通过缩略图与原图分离降低列表页加载压力；三是订单状态机设计，用单一状态字段配合流转校验，避免非法状态组合；四是前后端分离 + 统一响应封装，降低接口维护成本。这些话术不夸张，但每一条都能对应到你代码里的具体位置，答辩时被问到能立刻打开文件指给老师看，这就是底气。

5.3 进度安排和参考文献的两个小技巧

进度安排要倒推。别从今天往后排，从交付日期往前倒：最后两周留给论文撰写和修改，倒数第三周留给系统测试和演示准备，再往前是联调和补功能。这样排出来的计划才现实，不会出现“第 10 周完成所有功能，第 11 周写论文”这种一看就不可能完成的安排。

参考文献别凑数。三五个英文文献加十个中文文献是常规配置，但每一篇最好都能在你的正文里被引用到——比如讲前后端分离的时候引用一篇架构相关的，讲库存并发的时候引用一篇数据库事务相关的。参考文献和你正文对不上，是最容易被挑出来的问题。

6. 部署、演示与验收：最后一公里

6.1 本地环境与打包注意事项

打包之前先做一次全量自测清单：注册登录、搜索筛选、详情浏览、下单、支付（模拟）、取消订单、后台增删改查、图片上传。每一项都点一遍，别只测自己刚改的那个。

打包时最容易忽略的是环境配置分离。数据库地址、账号密码、文件存储路径、跨域配置，这些都不能写死在代码里。用配置文件加环境区分（开发/生产两套配置），占位符里填真实值，提交到仓库前把真实密码去掉，换成示例值——这是个很小的动作，但在评审眼里是专业度的体现。

数据库脚本也要整理出来：建表语句按依赖顺序排（先用户、目的地，再线路，最后订单）、初始化数据（管理员账号、几条示例线路、目的地）。这样别人拿到你的源码能一把跑起来，这是“可复现”的关键。

6.2 演示环节的几个实用细节

演示最怕的不是功能少，是演示中途崩了。我的经验是准备三层保险：第一层，演示用的数据提前录好，别现场输；第二层，把演示流程写成一个清单，按顺序点，不即兴发挥；第三层，准备一个录屏，网络或环境出问题时直接放录屏，讲的时候心里不慌。

时间分配上，二十分钟的演示，五分钟讲背景和功能概览，十分钟走主流程（浏览 → 检索 → 详情 → 下单 → 后台处理订单），五分钟讲技术亮点（库存并发、图片处理、状态机）。技术亮点一定要主动讲，不要让老师去问，你主动讲出来是加分，被问出来是应试。

7. 常见问题与排查实录

7.1 高频报错速查表

下面这张表是我这些年被问得最多的问题，基本覆盖了八成新手卡点：

7.2 几个只有踩过才知道的坑

第一，订单号重复。用“时间戳 + 随机数”生成订单号的，在压测或者快速连点时会撞。要么加机器标识，要么用数据库自增做后缀，要么直接用雪花算法类的方案。别觉得概率低就不管，撞一次排查半天。

第二，金额计算的分歧。前端算一遍总价用于展示，后端算一遍总价用于入库，两边算法不一致就会出现“显示 998，实付 1000”。解决办法是以后端为准，前端展示的价格只做参考，提交后以后端返回的订单金额为准刷新页面。

第三，删除操作的连锁反应。后台删除一条线路，如果已经有订单关联，直接物理删除会导致订单详情查不到线路信息，页面报空指针。正确做法是逻辑删除（加is_deleted字段）或者下架处理，同时对已关联订单做保护：有未完成订单的线路不允许删除。

第四，时间与时区。订单创建时间、支付时间、出行日期，这三个时间类型不一样。创建和支付是时间点，用 DATETIME；出行日期是日期，用 DATE。混用会导致“出行日期显示成前一天 23:59:59”这种问题。这一点在跨时区部署时更明显，课程项目里统一用服务器本地时区就行，但要在文档里写清楚约定。

第五，测试数据太假。演示的时候线路全是“测试线路1、测试线路2”，封面图是一张灰色占位图，整个系统看起来就像没做完。花两个小时录入十条真实感强的数据（目的地介绍、行程安排、几张好看的风景图），观感提升是数量级的。这件事投入产出比极高，但大部分人最后才想起来。

最后分享一个我在做这类项目时一直坚持的习惯：每完成一个模块，就把这个模块的表结构、接口、关键代码位置记在一个小本子上。等到写论文、做答辩 PPT、回答老师提问的时候，这个本子就是你的索引。项目做完了你未必记得每个类在哪，但你一定记得“库存扣减在订单服务里，用的是条件更新”。这个习惯看着笨，但它能让你在整个交付周期里始终保持对项目的掌控感，而不是到最后两周疯狂翻代码找自己在哪写过什么。