企业官网建设流程全解析

基于Web的长江游轮公共服务系统，这个项目代号j225o57w，我第一眼看到的时候就知道它是个非常典型的Java Web业务系统。名字里信号很足：长江游轮、公共服务、Web端，再加上程序、源码、数据库、调试部署、开发环境这一长串关键词，说明这大概率是一个完整的交付项目，而不是一个只写了几个页面就交差的Demo。

我之所以先盯着这类项目看，是因为它特别适合拿来练手和复刻。游轮旅游是一个很有行业特色的场景，既包含信息展示这种C端内容，又有订单、班次、库存管理这类B端逻辑，业务链路比普通的“新闻发布系统”长得多，但又没有电商平台那么复杂。把这样一个系统完整跑通，从建表到接口、从调试到部署，整个过程几乎能把Web开发的主干技能全部过一遍。

这篇文章我就把这个项目的需求、架构、数据库、功能、部署一条线拆开讲，把我实际做这类项目总结下来的经验也都放进去，给没接触过完整项目或者想复刻一个类似系统的读者做个参考。

1. 项目思路拆解：长江游轮公共服务系统到底在解决什么问题

1.1 先看业务链条：不是简单做一个购票网站

很多人在拿到“游轮公共服务系统”这个题目的时候，第一反应是“这就是一个卖船票的网站”，其实这个理解太窄了。如果只做买票功能，那系统根本撑不起“公共服务”这几个字。

公共服务系统的关键特点是面向公众、多角色、多入口。放到长江游轮这个场景里，产业链条是很长的：

• 游客端的核心动作是查看游轮信息、浏览航线、挑选班次、下单预订、管理个人订单；
• 运营人员的核心动作是维护游轮档案、设置航线班次、管理余票库存、发布公告、处理退改订单；
• 管理员还额外承担用户管理、数据统计、系统参数配置这类工作。

也就是说，整个系统至少要覆盖“信息展示—在线预订—运营管理”三个层次。只有把这三层都打通了，才是完整的公共服务系统，而不是一个静态介绍页。

1.2 从标题关键词反推功能边界

项目标题里出现的“长江游轮公共服务系统”这个词，本身就把业务范围框得很清楚。长江是地理范围，游轮是业务载体，公共服务是产品的性质。

如果让我对这个项目做一轮需求反推，核心功能模块至少包含这几块：

这个表一出来，开发任务基本就清晰了。前端要做什么、后端要写哪些接口、数据库要建几张表，全都能对应上。我建议所有同学拿到类似题目后都先做这一步——不要急着写代码，先用表格把功能边界划出来，这一步省下来的时间远大于它消耗的时间。

1.3 目标用户和使用场景决定了技术方案

长江游轮的服务对象并不完全是年轻人，很多游客年龄偏大，对复杂App的接受度不高，浏览器直接访问是最友好的方式。同时运营人员需要频繁进行批量性操作，比如调整班次的余票数量、编辑游轮船期，这些工作显然更适合在电脑大屏上完成。

这也是为什么这类系统选Web方案而不是小程序或者App的原因：

• Web系统无需安装、无需应用商店审核，打开浏览器输入地址就能用；
• 一套代码适配电脑、平板、手机不同终端；
• 服务端和浏览器只要保持HTTP协议互通，开发调试成本最低；
• 对毕业设计和课程项目来说，演示也最方便，不需要折腾真机、证书、打包。

有不少人纠结“要不要做成小程序”，我的观点是：如果题目明确写了“基于Web”，就安心做Web。把Web版本的服务端逻辑、数据建模做扎实，后续换一套小程序前端也只是时间问题，核心价值还是在后端业务上。

2. 系统架构与技术选型：前后端该用什么样的组合最稳

2.1 技术栈选型的底层逻辑

这类公共服务系统最常见的技术组合是前端Vue + 后端Spring Boot + MySQL。为什么这套组合几乎成了标准答案？不是因为它新潮，而是因为它稳定、资料多、上手门槛合理。

后端用Spring Boot，好处是内置Tomcat，不用额外配置复杂的服务容器；Spring MVC的请求映射、参数绑定、异常处理都很成熟；配合MyBatis-Plus以后，单表CRUD几乎不用写SQL，开发效率非常高。

前端用Vue，组件化开发让页面拆分成一个个独立模块，登录页、游轮列表页、订单详情页各管各的状态，不会出现一堆jQuery代码纠缠在一起改一处崩三处的局面。配合Element UI组件库，表格、表单、弹窗、分页这些后台管理常用的界面组件都是现成的，视觉风格也比较统一。

MySQL则是最稳妥的关系型数据库选择。业务数据量在这个项目中不会到海量级别，MySQL在可靠性、易用性和生态上面完全能扛住。商业数据库虽然在某些场景性能更强，但许可和部署成本完全没有必要。

2.2 采用前后端分离还是服务端渲染

这是做Web项目时绕不开的一个决策点。我实际做下来，这个项目更适合前后端分离。原因很简单：系统里C端页面和B端管理后台是两个差异较大的界面体系，如果全部依赖服务端渲染模板，前端逻辑会混在后端代码里，维护起来非常痛苦。

前后端分离之后，工作流是这样的：

• 前端工程独立维护，开发时通过Vite或Webpack启动一个开发服务器，登录、列表、下单这些页面独立调试；
• 后端只负责提供RESTful接口，返回JSON数据；
• 开发联调阶段，前端代理把请求转发到本地的8080端口后端服务；
• 上线时前端打包成静态文件，交给Nginx托管，后端打成Jar包在独立端口运行。

这套结构非常简单清晰，也符合目前大多数真实项目的形态。

2.3 项目目录结构和模块划分

在搭建开发环境的时候，一定要先把目录结构规划好。这个项目我建议采用标准Maven多模块思想，但不需要真的拆成多个工程，把包结构分清楚就好。

后端代码分层结构：

com.cruise.system ├── controller // 接口层：接收请求、返回结果 ├── service // 业务层：处理核心逻辑 │ └── impl ├── mapper // 数据访问层：MyBatis-Plus的Mapper接口 ├── entity // 实体类：对应数据库表结构 ├── dto // 数据传输对象：接口入参、出参 ├── vo // 视图对象：组合展示字段 ├── config // 配置类：跨域、拦截器、WebMvc配置 ├── common // 公共部分：统一返回结果、异常处理、工具类 └── CruiseApplication.java

前端如果用的Vue，结构大致是：

src ├── api // 接口请求封装 ├── views // 页面组件 ├── components // 公共组件 ├── router // 路由配置 ├── store // 全局状态管理 └── utils // 工具函数

这样的分层结构核心价值在于：每个层级只做自己职责内的事情。Controller不写业务逻辑，Service不直接拼SQL，Mapper只管数据库交互。后续如果要加功能，修改范围都能控制在尽量小的区域内，排查问题时也只需要顺着“页面—接口—Service—SQL”这一条线往下找。

3. 数据库设计：游轮、航线、订单是怎么串起来的

3.1 核心实体关系梳理

前面把功能模块列出来以后，数据库表模型基本就呼之欲出了。这个项目里最重要的四个核心实体是：用户、游轮、航线班次、订单。

它们的关系我梳理下来是这样的：

• 一个用户可以有多个订单，所以用户表与订单表是一对多关系；
• 一条航线班次归属于某条游轮线路，班次表通过游轮ID关联游轮表；
• 一个订单只能选择一个班次，所以订单表通过班次ID关联班次表。

为了把旅游内容支撑起来，还需要公告表、景点攻略表、用户评论表这些辅助表。整体设计并不追求高深复杂，关系型数据库的核心就是把业务关系模型化，表之间用外键字段关联起来，查询时用JOIN或者分步查询都能拿到完整数据。

3.2 关键表结构说明

我直接把我实际设计过的核心表结构列出来，大家可以参考着调整。

用户表：

CREATE TABLE `t_user` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT '加密后的密码', `real_name` varchar(30) DEFAULT NULL COMMENT '真实姓名', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `role` tinyint NOT NULL DEFAULT 0 COMMENT '角色：0游客 1运营 2管理员', `status` tinyint NOT NULL DEFAULT 1 COMMENT '状态：1正常 0禁用', `create_time` datetime NOT NULL COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

游轮表：

CREATE TABLE `t_cruise` ( `id` bigint NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL COMMENT '游轮名称', `ship_number` varchar(50) DEFAULT NULL COMMENT '船号', `capacity` int DEFAULT 0 COMMENT '载客量', `decks` int DEFAULT 0 COMMENT '甲板层数', `length` decimal(10,2) DEFAULT 0 COMMENT '船体长度', `build_year` int DEFAULT NULL COMMENT '建造年份', `cover_img` varchar(255) DEFAULT NULL COMMENT '封面图片地址', `intro` text COMMENT '游轮介绍', `status` tinyint DEFAULT 1 COMMENT '1启用 0停用', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='游轮信息表';

班次表：

CREATE TABLE `t_schedule` ( `id` bigint NOT NULL AUTO_INCREMENT, `cruise_id` bigint NOT NULL COMMENT '关联游轮', `route_name` varchar(100) NOT NULL COMMENT '航线名称', `start_port` varchar(50) NOT NULL COMMENT '起点港', `end_port` varchar(50) NOT NULL COMMENT '终点港', `depart_time` datetime NOT NULL COMMENT '出发时间', `arrive_time` datetime DEFAULT NULL COMMENT '到达时间', `base_price` decimal(10,2) NOT NULL COMMENT '基础票价', `stock` int NOT NULL DEFAULT 0 COMMENT '余票总数', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_cruise_id` (`cruise_id`), KEY `idx_depart_time` (`depart_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='航线班次表';

订单表是业务逻辑最重的一张表，状态字段要单独设计。我用的方式是用一个整型状态表示订单所处阶段，配合创建时间、支付时间、取消时间几个时间戳来记录流转过程。对于这个项目体量，这种方式比引入状态机引擎要务实得多。

3.3 订单状态流转与库存扣减

订单状态设计是整个数据库设计里的重点，直接影响后续业务代码的复杂度。我在这类项目中通常用五个状态：

状态流转方向基本都是单向的：待支付只能走到已支付或已取消；已支付只能走到已出票或退款取消；已完成是终态。设计状态表的时候，我会顺手把状态变更接口的权限控制也定下来——用户只能取消自己的待支付订单，运营人员才能执行出票操作。

库存扣减这里有个容易踩坑的点。下单成功后不能只在订单表里新增一条记录，还要同时把班次表里的stock减一。这个操作必须放在同一个数据库事务里，否则就会出现订单生成了但余票没扣，或者余票扣了但订单没生成的异常情况。我在实际项目里还会加一个乐观锁版本字段来控制并发下的库存覆盖问题，避免两个用户同时抢最后一张票的场景下出现超卖。

4. 核心功能模块实操解析：从登录到下单

4.1 用户登录与权限控制

登录模块看起来简单，但权限控制经常在验收时被重点拷问。我建议直接采用基于拦截器的统一权限校验方案，而不是在每个Controller里手动判断角色。

具体做法是：登录成功后后端生成Token返回给前端，前端在请求头里带上Token；后端写一个拦截器，在请求进入Controller之前解析Token并获取当前用户的角色；然后根据访问接口所需的角色权限做判断，权限不足直接返回统一的401或403响应。

密码存储一定要做加密处理，不能明文存库。我用的是BCrypt加密，它对同一个密码生成的哈希结果每次都会掺杂随机盐值，比简单的MD5加盐更安全。这部分虽然多写几行代码，但属于安全管理里必须守住的基本底线。

4.2 游轮航线查询与余票管理

游轮列表页是这个系统的门面，在首页展示时通常要求包含游轮名称、封面图、简短的亮点介绍。查询接口只需要做一个分页查询，然后把游轮ID关联到班次表，算出未来一段时间内是否有可预订班次即可。

余票管理的逻辑在管理后台体现得更充分。运营人员需要能按游轮维度查看班次列表，可以手动调整某个班次的总票数和余票数。这里要注意的是，手动修改余票需要做好权限控制，且最好在操作日志里留下记录。虽然这是一个偏管理的功能，但实际业务中非常关键，因为航线班次经常因为包船、检修等原因调整。

4.3 在线预订下单流程

下单流程是系统的核心链路，我把它拆解成下面几步。

第一步，用户选择一个班次，进入订单确认页。后端接口要根据班次ID返回航线信息、游轮介绍、价格和舱型选项。

第二步，用户填写联系人姓名、手机号、乘客人数，选择房型后提交订单。后端要做参数校验，不能只在前端校验，因为接口是可以被直接调用的。这一步要检查手机号格式、人数是否超过余票数、班次是否还在有效期内。

第三步，生成订单号并锁定库存。订单号要具备唯一性和可读性，我的习惯是用日期加随机数的组合，比如202506071430128765这种。库存扣减和订单生成必须放在同一个事务方法里，一旦任何一步失败整体回滚。

第四步，模拟支付。这个项目不涉及真实支付，所以只需要设计一个支付页面，用户点击“确认支付”后，后端将订单状态从待支付改成已支付，同时记录支付时间。

整个链路里最容易出问题的是事务边界。有些同学会把库存扣减和订单生成写在两个Service方法里，然后调用方依次调用，这样一旦第二步失败，第一步的库存扣减已经提交了，数据库里就出现脏数据。正确做法是让Service层提供一个统一的下单方法，在这个方法上标注@Transactional，保证两个数据库操作在同一个事务里执行。

4.4 公告、攻略与用户评论

公共服务系统必须要有内容展示的模块，否则产品会显得非常“空”。公告用于发布航线调整、天气提醒、防疫须知等运营信息；旅游攻略则可以对长江沿线景点做介绍，增加系统的信息含量。

这些内容模块建议采用同一个内容管理框架：后台提供富文本编辑器，存储到数据库的文本字段中；前端列表页做分页展示，详情页展示完整内容。这里注意富文本内容会包含HTML标签，预览时需要用组件原样渲染，不能用{{ }}插值让它变成普通字符串。

用户评论可以挂在游轮详情下方，游客完成订单后才能评论，这样能避免恶意刷评。设计评论表时就加上用户ID、游轮ID和订单ID，查询时三表关联取出用户名和评论内容。

4.5 后台管理模块的实用设计

后台管理的设计原则是简单直接。左侧菜单列出游轮管理、班次管理、订单管理、用户管理、公告管理等入口，每个页面基本都是表格加搜索条件加弹窗表单的组合。

表格页面建议统一封装分页组件，后端接口统一返回页码、总条数、列表数据三要素。搜索条件用“页面传参与后端接收参数对齐”的方式实现，查询时动态拼接条件。MyBatis-Plus的LambdaQueryWrapper对这类动态条件查询支持已经非常完善，写起来也直观。

订单管理页面还需要提供导出功能。虽然题目未必硬性要求，但很多验收场景下导出Excel是一个加分项。用EasyExcel或者POI都可以实现，导出数据时记得按创建时间倒序，限制导出条数，避免一次导出全年订单导致接口超时。

5. 项目文件交付、调试部署与运行环境配置

5.1 拿到这类项目后怎么验收和启动

这个项目标题里提到的交付物很完整：程序源码、数据库脚本、调试部署步骤、开发环境说明、带论文文档。这里要给正在参考的读者提个醒：收到这类项目文件以后，不要急着看代码，先按顺序做三件事。

第一，检查数据库脚本能不能顺利执行。打开SQL文件后，先看建库语句用的字符集、版本兼容性，然后在本地MySQL里完整跑一遍。如果脚本报错，优先排查MySQL版本差异和字段类型兼容问题。

第二，检查后端配置文件。核心是数据库连接串、用户名密码、端口号。Spring Boot项目的配置文件一般在application.yml或application.properties里，确认起来很直接。

第三，检查前端是否需要安装依赖。Vue项目需要先执行依赖安装命令，然后在本地启动开发服务器。前端启动后先别管功能，确认能不能通过代理访问到后端接口，这一步打通了后面才有意义。

只要这三步走通，项目就成功跑起来了，后续再逐步去验证各个功能页面。

5.2 本地联调环境的关键配置

开发环境的搭建文档经常被当作附属品草草带过，其实它才是最容易卡住新手的地方。我单独说几个核心配置项。

后端数据库连接配置示例：

spring: datasource: url: jdbc:mysql://localhost:3306/cruise_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai

这里面有几个参数必须注意。characterEncoding=utf8负责解决中文乱码；serverTimezone=Asia/Shanghai解决时区报错问题，不然默认的美国时区会导致时间字段错乱，订单创建时间看到凌晨三点的记录是非常磨人的；useSSL=false则是避免本地MySQL出现SSL连接警告。

前端如果用了Vue，开发代理的配置也很关键。开发环境下前端页面在5173端口，后端接口在8080端口，跨域请求必须通过代理转发。配置好之后，前端请求/api开头的地址会被代理转发到http://localhost:8080，就不会出现浏览器拦截跨域请求的问题了。

5.3 上线部署的两种常用方案

部署这件事，对这个项目体量来说不需要引入复杂容器编排，两种方案足够用。

方案一是前后端分离部署。后端先把项目打成Jar包，在服务器上用java -jar命令启动。前端构建打包成dist静态目录，放到Nginx的html目录下，同时配置反向代理，把/api开头的请求转发到后端端口。

Nginx关键配置片段大概是这样的：

server { listen 80; server_name cruise.example.com; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://localhost:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

方案二是用Spring Boot直接托管前端静态资源。把前端打包后的文件复制到后端项目的src/main/resources/static目录下，再重新打包后端，这样只需要启动一个端口就能同时访问前后端。这种方式适合演示场景，但真实生产环境一般不会这么做，解耦性差一些。

5.4 最常出现的三个问题与排查思路

我在帮别人排查类似项目的时候，遇到过三个高频问题，这里整理成一个速查表。

比如404那个问题，我做过一个印象很深的排查经历：前端请求的是/api/cruise/list，后端Controller映射的路径是/cruise/list，前端代理把/api转发时又没做路径重写，请求打到后端就变成了/api/cruise/list，而后端根本没有这个路径，所有列表接口全部404。解决方案是把代理配置里的路径重写规则加上，或者统一调整后端接口的前缀。这类问题有个非常直观的排查套路：先看浏览器Network面板里的实际请求，再对比后端实际注册的路径，基本能一眼锁定问题。

6. 论文文档与项目演示的经验补充

这个项目的交付物里还包含论文文档，这也是国内很多课程设计、毕业设计类项目的固定配置。写这类项目文档时我的经验是：项目源码可以复用，但文档里的功能描述、系统设计、测试分析一定要跟自己的实际代码完全对应起来。

论文文档通常包含几个固定章节：绪论和背景意义、系统需求分析、系统设计、数据库设计、系统实现、系统测试、总结。写的时候最忌讳大段复制模板而代码和数据模型对不上。比如数据库设计章节里画了五张表，但代码里实体类有六个，这种明显的差异在评审时一眼就会被发现。

我在写这类文档的时候，一般会把系统实现章节写得最具体，每个功能模块配一段核心代码说明和界面截图，再配上功能测试表。文档的价值是辅助别人快速理解系统，不是简单的代码粘贴，所以每个模块讲清楚“做什么—怎么实现—效果是什么”就足够了。

7. 复刻这类项目的个人经验总结

把一个基于Web的长江游轮公共服务系统从零到一做完，我个人最大的体会是：这种业务型Web项目的难点不在某个单独的技术点上，而在“完整度”上。首页展示要做，用户注册要接，游轮列表要分页，班次查询要支持条件筛选，下单事务要保证一致性，后台要能管理数据，部署上线还要跑得通。任何一环缺失，系统就不完整。

如果让我给正在做类似系统的同学三个实用建议，第一条是先把数据库表结构完全想清楚再动手写接口。表设计做对了，后面所有业务逻辑都顺；表设计有问题，越写越痛苦。第二条是接口返回值要设计成统一结构，比如code + message + data这种固定格式，前端处理起来简单，后端也不用每个接口各写一套返回逻辑。第三条是不要花大量时间在美化商业系统Demo页面上，公共服务系统的核心评价标准是业务流程是否闭环、代码是否清晰、数据是否一致，界面干净整洁即可。

最后再分享一个小技巧：每完成一个模块就做一次整体的启动测试，不要攒到最后一起联调。我曾经就是一口气写了十几个接口，最后才发现数据库连接配置有问题，结果所有接口都返回500，排查起来完全没有头绪。改成“写一个模块测一个模块”以后，出问题能第一时间定位到代码位置，效率反而高很多。