企业官网建设流程全解析

从一个残缺的标题说起——“基于的旅游网站的设计与开发”，中间那截技术栈定语被漏掉了。这个现象在实际项目里太常见了：选题先定，方案后补，代码边写边改，等到要交开题报告和源码的时候，才发现自己挖的坑比写的功能还多。旅游网站这个方向每年都有一批人在做，图纸画得一个比一个大，真跑起来能点的往往只有登录页和列表页。源码交付、开题文档、答辩演示这三件事，本质上是一件事的三个切面：你得先想清楚这个系统到底替谁解决了什么问题，才写得动开题；想清楚了数据怎么流转，才写得动核心业务；结构理顺了，源码才能被人看懂、被自己讲明白。下面就把从这句残缺标题走到一套能跑、能演示、能交付的完整过程拆开讲，包括技术栈怎么选、旅游业务的数据模型和普通电商差在哪、订单并发怎么处理、开题报告哪些段落最容易被打回来。

1. 先把标题补全：这个旅游网站究竟要解决谁的什么问题

1.1 从一句残缺的标题里读出三层信息

“基于的旅游网站”这句话本身是不成立的，中间缺了技术栈定语。但把这句话当成一个真实项目来看，它其实已经透露了三层信息，第一层是领域：旅游。这个领域和普通商品零售有本质区别，旅游产品的售卖单元不是“一件商品”，而是“某条线路在某一天的若干个名额”。第二层是角色：至少有两类人要用这个系统，一类是浏览和下单的游客，另一类是维护线路、处理订单的运营人员。第三层是交付形态：标题后面跟着“源码+开题”，说明这不只是一个能跑的工程，还得配一份能被看懂、被审核的设计文档。

把这三层信息摊开之后，技术栈的补全才有意义。补成什么？业界最常见的默认答案是 Java 语言配合 Spring Boot 框架、MyBatis 做持久层、MySQL 存数据、Vue 做前端。这个组合之所以成为默认答案，原因并不复杂：资料密度高，遇到报错大概率能搜到同类问题；分层结构清晰，答辩时能讲明白每一层在干什么；部署简单，一台普通配置的机器跑起来不吃力。我不认为它是最优解，但在“一个人、有限时间、要交付可运行系统”这个约束下，它是最省心的解。

这里有个经验：不要为了显得技术含量高，硬塞进消息队列、搜索引擎、容器编排这些东西。见过有人给旅游网站上了全文检索中间件，结果启动脚本写了三页，答辩时被问“为什么不用数据库的 like”，答不上来。技术选型的加分项从来不是数量，而是每个选择都能说清楚“不用它会怎样”。

1.2 需求边界的划线：哪些功能必须有，哪些必须砍

功能清单是这类项目最容易失控的地方。很多人一上手就列二三十条，最后交付时能稳定运行的不到一半。我的做法是先划一条“最低可交付线”，这条线以内的功能必须做完并且稳定，线以外的按时间余量往上加。

最低可交付线通常包含这几块：

• 用户侧：注册、登录、个人信息维护、密码修改；
• 浏览侧：线路列表、多条件筛选（目的地、天数、价格区间、关键词）、线路详情（含图集、行程安排、费用说明）、景点介绍；
• 交易侧：选择出发日期、填写出行人信息、提交订单、订单列表与详情、取消订单；
• 管理侧：线路的增删改查、出发日期与价格的维护、订单查询与状态变更、用户管理、图片上传；
• 基础侧：权限拦截、登录态校验、统一异常返回。

明确要砍掉的，通常是这几类。支付对接排第一位，接真实支付需要资质和商户号，个人项目根本走不通，做一个模拟支付页面，点击后把订单状态从“待支付”改成“已支付”，逻辑闭环就成立了，答辩时说明这是模拟实现即可。实时客服聊天也砍，做出来是玩具，做不完是负债。推荐算法同样可以砍，用“按浏览量排序”或“按销量排序”替代，效果上看得见，实现上几十行代码。

提示：功能清单定稿后立刻冻结，后面所有数据库表、接口、页面都围绕这份清单展开。中途加功能是这个类目里返工率最高的原因，加一个“收藏”看似简单，实际上要动表、动接口、动三个页面的按钮状态。

1.3 那个经常被忽略的角色：运营端

只做游客端是这类项目最典型的失误。演示时老师或者评审随口一句“这些线路是谁传上去的”，如果没有后台，整个系统就露馅了——数据全靠手动往数据库里插，说明这个系统还不是一个完整的系统。

运营端不需要做得花哨，但必须闭环。核心是三张管理页：线路管理（含封面图上传、行程富文本、上下架开关）、日期库存管理（给某条线路批量生成未来若干天的出发日期，设置每天的价格和名额）、订单管理（按状态筛选、查看详情、标记出行完成）。这三张页面做扎实，整个系统的数据就能自己流动起来，演示时可以从后台新建一条线路，切到前台刷新就能看到，这条链路的说服力比任何功能描述都强。

还有一个细节：管理端的账号不要和游客账号混在一张表里用同一个登录入口。分成两张表、两套拦截规则，虽然代码多了一点，但权限边界清楚，也避免了“普通用户改个字段就能进后台”这种明显漏洞。

2. 技术栈怎么定：不是越新越好，而是让每一步都能被验证

2.1 三种常见组合的横向对比

同一条业务需求，不同的技术组合实现起来的摩擦系数差别很大。我把常见的三类放在一起比一比，方便按自己的基础和机器条件做选择。

我为什么在多数情况下推荐第一列？不是因为 Java 更好，而是因为这个组合强制你把“控制器、业务、数据访问”三层切开。这种强制分层对一个还在建立工程习惯的人来说是有价值的，它逼着你想清楚“这段逻辑该放哪”。而 Django 那种一个文件里写完的路子，跑得快，但后期改动容易乱。

当然也有例外。如果手上只有 Python 基础，为了凑技术栈硬啃 Spring 的注解和配置文件，时间会全部消耗在环境问题上。选自己已经能跑通 hello world 的那一套，把精力留给业务逻辑，这才是正确的资源分配。

2.2 为什么我倾向于前后端分离 + 单体部署

前后端分离在这个体量下依然值得做，理由很实际：前端页面里大量的列表、筛选、卡片可以抽成组件复用，改一次样式全站生效；后端只返回 JSON，调试时可以直接用接口工具打，不用在页面里翻控制台；两边可以并行推进，前端先用假数据把页面搭出来，后端接口好了直接换地址。

但“分离”不等于“拆微服务”。一个人开发，把所有业务放在一个工程里，打成一个包部署，是最稳的。引入注册中心、网关、服务间调用，只会让启动流程变长、排查变难。单体应用在这个规模下没有任何性能问题，反而让“改一个字段要动几个工程”这种事不会发生。

跨域是分离之后第一个撞上的问题。开发阶段前端跑在一个端口、后端跑在另一个端口，浏览器会拦请求。处理方式有两种：后端加全局跨域配置，或者前端配代理。我一般两边都配，前端代理解决开发期，后端配置给部署后留后路。

@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); } }

注意：allowedOrigins("*")和allowCredentials(true)在较新的规范里不能同时生效，必须换成allowedOriginPatterns。这个报错信息很不直观，表现出来就是“请求发出去了但拿不到响应”，第一次遇到能耗掉半天。

2.3 环境准备中最容易被忽略的几个细节

环境问题占了新手期故障的一大半，而且大多不是代码写错，是版本对不上。列几个高频的：

第一，JDK 版本和框架版本必须匹配。较新的大版本框架要求 JDK 17 及以上，用 JDK 8 编译会直接报不支持的类文件版本。反过来，一些老教程里的配置项在新版本里已经废弃，比如某些路径匹配规则的变化，照抄会启动失败。

第二，MySQL 8 的驱动类名和连接串参数变了。驱动类要用com.mysql.cj.jdbc.Driver，连接串必须带上时区参数，否则时间字段会莫名其妙差几个小时：

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

第三，端口占用。后端默认端口被别的程序占了，启动日志里只写一句“应用启动失败”，实际原因藏在更上面的异常堆栈里。养成习惯：启动失败先往上翻，找Caused by那一行。

第四，前端依赖安装失败。多数是源的问题或者 Node 版本过新导致某些包不兼容。遇到装不上，先降 Node 大版本，比逐个改依赖版本号省事得多。

第五，建库时字符集要显式指定。建库语句写上DEFAULT CHARSET=utf8mb4，否则存中文和特殊符号时会出问题，而这个问题往往要到演示当天才暴露。

3. 数据库设计：旅游类业务的数据模型和普通电商差在哪

3.1 核心表与它们的职责划分

把表设计对了，后面的接口写起来是顺的；表设计歪了，业务逻辑会到处打补丁。旅游网站的核心表大概是这么几组：

这张表里最关键的是route_departure。它把“线路”和“日期”拆开了，这一步拆不拆，直接决定了系统是玩具还是能用的东西。

3.2 线路-日期-价格三层结构，避免把价格写死在产品表里

很多初版设计是把价格和库存直接写在tour_route上：一条线路一个价格、一个库存数。这样做的后果是，同一趟行程在淡季和旺季卖一个价，同一个产品在节假日没有独立的名额控制，用户选了日期也没法验证那天还有没有位置。

正确的结构是三层：线路是“卖什么”，日期是“哪天卖”，价格库存挂在日期上。一条线路可以生成未来 90 天的出发记录，每天独立定价、独立控量。前台用户先选线路，再选日期，价格随日期变化，余位随日期变化，整个交互就自然了。

CREATE TABLE route_departure ( id BIGINT PRIMARY KEY AUTO_INCREMENT, route_id BIGINT NOT NULL COMMENT '线路ID', depart_date DATE NOT NULL COMMENT '出发日期', price DECIMAL(10,2) NOT NULL COMMENT '当日单价', stock INT NOT NULL DEFAULT 0 COMMENT '总名额', sold INT NOT NULL DEFAULT 0 COMMENT '已售', status TINYINT NOT NULL DEFAULT 1 COMMENT '1可售 0停售', UNIQUE KEY uk_route_date (route_id, depart_date), KEY idx_route_status (route_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='出发日期与库存';

那个唯一索引uk_route_date是个保险丝。后台批量生成日期时如果不小心点两次，没有它就会插出重复记录，前台下单时按日期查出来两条，到底扣哪一条的库存就成了随机事件。

3.3 字段类型和索引上的实际取舍

几个具体的坑，都是踩过才记住的。

金额一定用DECIMAL(10,2)，不要用FLOAT或DOUBLE。浮点数存钱会出现199.99999999这种情况，前端格式化之后看起来正常，但累加计算会对不上账。这个错误在订单总价的计算上特别致命。

状态字段用TINYINT加字典注释，不要用字符串。字符串占空间、比较慢，而且容易因为大小写或空格写错导致查询查不到。约定好 0 待支付、1 已支付、2 已完成、3 已取消、4 已退款，写进注释里，前后端共用这一套。

删除一律用逻辑删除，加一个is_deleted字段。物理删除在有关联表的情况下会制造孤儿数据，订单指向一条不存在的线路，页面直接崩。

索引不要乱加，只加在真正会出现在WHERE和ORDER BY里的列。订单表的user_id要加，因为“我的订单”必然按用户查；order_no要加唯一索引，它是幂等控制的关键。反过来，给status单独加索引意义不大，因为状态值少、区分度低，数据库优化器多半不走它。

还有一个反直觉的点：LIKE '%关键词%'这种前置通配的模糊查询走不了索引。旅游网站的搜索框基本都会用这种写法，数据量小的时候感觉不到，数据量一上来就是全表扫描。这个体量下可以接受，但心里要知道它的代价。

4. 三个最难写的功能：线路检索、订单占用、图片处理

4.1 多条件线路检索的动态拼接与分页

线路列表的筛选条件通常有目的地、行程天数、价格区间、关键词，而且这些条件是可选的，用户可能只填一个，也可能全填。硬编码几十个if拼 SQL 显然不行，用持久层框架的动态标签来拼。

<select id="pageQuery" resultType="RouteVO"> SELECT r.id, r.title, r.days, r.cover, r.price_min, MIN(d.price) AS minPrice FROM tour_route r LEFT JOIN route_departure d ON d.route_id = r.id AND d.status = 1 AND d.depart_date &gt;= CURDATE() <where> r.status = 1 AND r.is_deleted = 0 <if test="city != null and city != ''"> AND r.city = #{city} </if> <if test="days != null"> AND r.days = #{days} </if> <if test="keyword != null and keyword != ''"> AND r.title LIKE CONCAT('%', #{keyword}, '%') </if> <if test="minPrice != null"> AND d.price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND d.price &lt;= #{maxPrice} </if> </where> GROUP BY r.id ORDER BY r.sort_weight DESC, r.id DESC </select>

这段 SQL 有两个要点。第一，关联出发表时过滤掉已过期的日期，用户看到的“起价”必须是未来还能买的价格，不能是上个月的。第二，按线路 ID 分组，否则一条线路有多个日期就会在列表里重复出现好几条，这是一个非常典型的现象级 bug，页面看起来像“数据重复了”，实际是 join 之后没聚合。

分页这层要额外留意总数查询。用了分页插件之后，它会自动生成一条 count 语句，如果原 SQL 带GROUP BY，count 的结果可能不准，表现出来就是“总数是 8，翻页翻到第 3 页就空了”。解决办法是手动提供 count 语句，或者把分组逻辑挪到子查询里。

4.2 下单流程里的库存扣减：先查再减为什么会出事

库存扣减是这个系统里唯一真正有并发的地方，也是最容易写出 bug 的地方。最直觉的写法是：先select查当前库存，判断够不够，够的话再update减去相应数量。单线程跑没问题，两个用户同时下单就出事——两个人同时读到剩余 2 个名额，都判断“够”，然后各自扣 2，最后卖出 4 个。

正确的做法是把判断和扣减合并成一条原子语句，让数据库来做这个判断：

UPDATE route_departure SET sold = sold + #{count} WHERE id = #{departureId} AND status = 1 AND stock - sold >= #{count};

执行之后取影响行数，返回 0 就是没抢到名额，直接给用户返回“该日期余位不足”，返回 1 才继续往下走创建订单。这条语句在数据库层面是原子的，两个并发请求会排队执行，第二个执行时stock - sold已经变了，条件不成立，自然扣不动。

用stock - sold而不是直接维护一个remain字段，是因为总名额和已售分开存，运营调整名额的时候不用反算，数据也更可追溯。代价是每次都要做减法，但这个计算成本可以忽略。

订单状态流转也要成体系，不能想到哪改到哪：

提示：取消订单回滚库存时，别忘了同时把sold减回去，并且加一个状态判断防止重复回滚。见过一个案例，取消接口被连续点了两次，库存加回去两次，系统凭空多出了名额。

超时未支付的处理用定时任务扫一遍，把创建超过 30 分钟还停留在“待支付”的订单改成“已取消”并回滚库存。这个任务建议加个开关，开发和演示阶段关掉，避免演示到一半订单被自动取消。

4.3 图片上传：本地存储够用，但路径和命名要讲究

景点和线路都得有图，图片上传是绕不开的。这个体量下用本地磁盘存储完全够，不需要引入对象存储服务——多一个外部依赖就多一个演示时可能挂掉的环节。

上传接口要处理四件事：大小限制、格式白名单、文件名重命名、存储路径规划。

@PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.fail("文件为空"); } if (file.getSize() > 5 * 1024 * 1024) { return Result.fail("图片不能超过5MB"); } String original = file.getOriginalFilename(); String ext = original.substring(original.lastIndexOf(".")).toLowerCase(); if (!Arrays.asList(".jpg", ".jpeg", ".png", ".webp").contains(ext)) { return Result.fail("仅支持 jpg/png/webp 格式"); } String fileName = UUID.randomUUID().toString().replace("-", "") + ext; String datePath = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy/MM")); File dir = new File(uploadRoot + "/" + datePath); if (!dir.exists() && !dir.mkdirs()) { return Result.fail("目录创建失败"); } file.transferTo(new File(dir, fileName)); return Result.ok("/upload/" + datePath + "/" + fileName); }

几个细节值得说。用 UUID 重命名是必须的，用户上传的文件名经常重复，比如一堆微信图片_2024.jpg，不重命名就会互相覆盖。按年月分目录，是为了单个目录下文件数不会膨胀到影响遍历性能。格式白名单要写成后缀白名单，不要只看Content-Type，那个字段是可以伪造的。

后端还需要一个静态资源映射，把/upload/**的请求指向磁盘目录，否则上传成功的图片在前端访问时是 404：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${upload.root}") private String uploadRoot; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadRoot + "/"); } }

注意file:前缀和结尾的斜杠，少一个就 404，而且报错信息完全不提示原因。

5. 开题报告怎么写才不被退回：结构、重点与常见驳回原因

5.1 开题报告每一块的真实作用

开题报告不是走形式，它的每一节都在回答评审心里的一个问题。理解了这个，就知道该怎么写，也就知道哪些地方最容易被打回来。

研究背景与意义，回答的是“为什么做这个”。这一节最常见的失败是写成行业宏大叙事，全是空话。有效的写法是收到具体场景：某个城市的周边游信息分散在多个渠道，用户查一条线路要对比好几个页面，本系统把线路、日期、价格、余位集中到一处。范围缩小，说服力反而变强。

国内外研究现状，回答的是“你了解过别人怎么做吗”。这一节不用写成学术综述，挑三到五个同类系统，说清楚它们的功能侧重，再点出你的系统在这批功能里做了哪些取舍。写“现有平台偏重全品类，本系统聚焦周边短途线路，结构更轻”这种句子，比堆十篇参考文献有用。

研究内容，把功能清单按模块列出来，一段一个模块，说清楚这个模块解决什么。

技术路线，说清楚用什么技术、为什么用、模块之间怎么组织。

可行性分析，从技术、经济、操作三个角度各说两三点。

进度安排，按周排表。

参考文献，别全列教材，掺几篇近年的期刊或者会议论文。

5.2 技术路线和可行性分析怎么写才不是空话

这两节是最容易写成一堆形容词的地方。技术路线写成“采用先进的技术架构，保证系统的高可用性和可扩展性”，评审看一眼就划掉了，因为这句话放在任何系统上都成立，等于没说。

技术路线应该写成“谁调用谁”的具体描述。比如：前端通过 HTTP 接口访问后端，后端按控制器、业务、数据访问三层组织，业务层负责订单状态流转和库存扣减，数据访问层通过持久层框架与数据库交互，图片资源由后端提供静态映射，数据库采用单一实例并在初始化脚本中预置基础数据。这样的描述是可以被追问、也可以被验证的。

可行性分析也分三条来写。技术可行性讲每个技术点你都有对应的实现方案，哪一块有风险、备选方案是什么；经济可行性讲这个系统用的是开源组件和本机环境，没有额外的软件采购成本；操作可行性讲界面形态和操作路径，普通用户不需要培训就能完成浏览和下单。三条各写两三句，落到具体的地方，不要泛泛而谈。

提示：开题报告里的功能清单，一定要和最终源码里的功能对得上。评审和答辩时经常拿着开题对照系统看，写了的没做出来，是最难圆回来的问题。宁可少写两条，也别写了自己都实现不了的。

5.3 进度计划表的排布经验

进度表按周排，但排法有讲究。多数人的错误是平均分配，每周都写“完成某某模块”，实际操作中前松后紧，最后两周崩盘。

我的建议是前紧后松，并且把环境搭建和数据库设计单独占一周。这两件事看起来简单，实际最容易拖，一旦拖进业务开发阶段，后面全部挤压。中间的业务开发按模块排，每个模块留半天做联调。最后留出整整一周做联调和文档，其中至少两天只做一件事：把自己当成第一次使用的用户，从注册开始完整走一遍所有流程，把发现的每个问题记下来逐个修。

还有一个细节，进度表里要有一行“演示数据准备”。演示当天现场建数据是很危险的，网络、环境、操作失误任何一个环节出问题都会冷场。提前准备好五到八条线路、几十条出发日期、几个不同状态的订单，演示时直接展示效果，把精力放在讲设计思路上。

6. 源码目录的组织方式与交付前的自检

6.1 包结构分层与命名约定

源码被人打开的第一眼，看到的就是目录结构。结构乱的代码，哪怕逻辑是对的，也很难被认可。

后端的包结构按职责分层，这是最通用的做法：

com.example.travel ├── controller 对外接口 ├── service 业务接口 │ └── impl 业务实现 ├── mapper 数据访问 ├── entity 数据库映射对象 ├── dto 接收前端参数 ├── vo 返回前端的视图对象 ├── config 配置类 ├── interceptor 登录与权限拦截 ├── common 统一返回、异常、常量 └── util 工具类

entity、dto、vo这三个分开是有必要的。直接用实体类接收前端参数，会带来两个问题：一是前端能传什么字段你就得接什么字段，用户 ID 这种敏感字段会被恶意覆盖；二是返回给前端时会把密码哈希这种不该出门的字段一起带出去。分开定义，虽然多写了几个类，但边界是清楚的。

前端目录按页面和组件分，views放页面，components放可复用组件（线路卡片、筛选栏、分页条），api放接口封装，utils放请求拦截和格式化工具。线路卡片这个组件在首页、列表页、搜索结果页都会用到，抽出来之后改一次样式三处生效，这是组件化带来的实际收益。

6.2 交付前必须亲手跑通的三条链路

写完代码不等于能交付。交付前至少要把这三条链路从零走一遍，中间不能借助数据库工具手动改数据。

第一条，新用户注册 → 登录 → 浏览列表 → 筛选 → 进详情 → 选日期 → 填出行人 → 提交订单 → 在“我的订单”里看到这条记录。这条链路串起了绝大部分核心逻辑，任何一环断了都说明主干有问题。

第二条，后台登录 → 新建一条线路并上传封面 → 为这条线路批量生成未来 30 天的出发日期 → 切回前台刷新 → 确认新线路出现在列表里且价格正确 → 后台查看刚才用户下的订单 → 修改订单状态。这条链路验证的是数据能否双向流动，也是演示时最有说服力的一段。

第三条，异常路径。提交一个名额不够的订单看提示是否正确；重复提交同一个订单看是否被拦截；不登录直接访问订单接口看是否被拦回登录页。异常路径处理得好不好，是“能用”和“看起来能用”的分水岭。

6.3 README 里必须写清楚的五件事

交付的源码包里，README 是最容易被忽略又最影响第一印象的文件。内容不用长，但这五件事必须写清楚：运行环境的具体版本号（JDK、数据库、Node）；数据库初始化脚本的位置和执行顺序；默认的管理员账号和密码；后端的启动命令和前端的启动命令，以及各自的端口；三个最常见的启动问题和解法。

尤其是初始账号这一条。评审拿到源码，第一件事就是想进后台看看，如果没有账号，他只能自己去翻数据库，体验就断了。

7. 实测踩坑记录与排查链路

7.1 中文乱码：从请求到落库的四段排查

中文乱码是这类项目的高频问题，表现是页面显示问号或者方块。它可能出现在四个位置，必须逐段排查，不能靠猜。

第一段是数据库。建库建表时字符集没指定，默认可能不是 utf8mb4。用SHOW CREATE TABLE 表名看一眼，如果不是就改。

第二段是连接串。JDBC 连接串里没带characterEncoding=utf8，传输过程就会按平台默认编码处理。这一条加上基本能解决大半问题。

第三段是后端响应。接口返回的 JSON 里中文正常，但浏览器显示乱码，多半是响应头里的字符集没设对。现在主流框架默认是 UTF-8，遇到问题可以加一个全局编码过滤器兜底。

第四段是前端页面。HTML 的meta标签里没声明字符集，或者声明的和实际文件编码不一致，也会乱。

排查顺序建议从数据库往上走，因为越靠下的问题影响面越大。改完一处就要重新插入一条中文数据验证，别一次改四个地方，最后不知道是哪一处起的作用。

7.2 分页总数对不上：那条被忽略的 count 语句

现象是列表能正常显示，但分页条上的总条数明显偏大或偏小，翻到后面几页是空的。

原因基本锁定在分页插件自动生成的 count 语句上。当原查询带GROUP BY、DISTINCT或者多表 join 时，插件把原 SQL 简单包一层SELECT COUNT(*) FROM (...)，得到的行数和用户认知里的“有多少条线路”不是一回事。

处理办法有两种。简单的是把分组逻辑挪进子查询，让外层查询是扁平的；更稳的是给这个查询单独写一条 count 语句，用@Select或者 XML 里的对应节点指定，插件检测到就会直接用它。后一种方式虽然多写几行，但结果可控。

7.3 时间差八小时：时区这条隐形的线

数据库里存的时间是 14:00，页面显示成 06:00，或者反过来。这是典型的时区问题，链路上有三个地方会各自按自己的理解解释时间：数据库连接的时区参数、应用进程的默认时区、前端格式化的方式。

处理的时候三处对齐到同一个时区。连接串加上serverTimezone=Asia/Shanghai；应用启动时固定时区，在启动类里设一次默认时区；前端不要自己做时间戳换算，直接展示后端返回的格式化字符串。三处统一之后，这个问题基本不会再出现。

还有一个相关的坑：实体类里的日期字段用Date还是LocalDateTime。用Date在序列化时容易出现格式不统一，用LocalDateTime配合全局的序列化配置，输出格式更稳定。

7.4 静态资源 404：路径映射的斜杠问题

上传成功的图片在数据库里存了路径，前端拼接域名访问却返回 404。这种情况先看两处：一是资源映射里的addResourceLocations结尾有没有斜杠，file:/data/upload和file:/data/upload/在路径拼接时结果完全不同；二是上传时写入的路径和映射时读取的路径是不是同一个根目录，尤其当上传目录是相对路径时，会因为启动位置不同而解析到不同地方。

我的习惯是把上传根目录配置成绝对路径，写在配置文件里，上传和映射两处都从这个配置项取值。这样就不会出现“上传时在一个地方，读取时在另一个地方”的错位。

最后分享一个贯穿整个项目的小习惯：每做完一个模块，就在本地把这条链路完整点一遍，包括成功路径和至少一个失败路径。这个动作花不了几分钟，但能在源头拦掉大部分问题。等到所有模块堆完再统一联调，问题会互相掩盖，排查成本翻好几倍。旅游网站这类项目真正的难点从来不在某个技术点多高深，而在几十个环节能不能串成一条稳定的线，这条线通了，系统就立住了。