企业官网建设流程全解析

古城景区管理系统这种项目，做过的都知道，看着模块不多，真要把业务闭环理清楚也得花不少功夫。这套基于SpringBoot + Vue的前后端分离系统，涵盖游客端在线购票、景区信息展示、公告发布、订单管理、后台数据统计这些核心功能，源码、数据库脚本和设计文档都齐全，算是这类管理系统里结构比较完整的一套。不管是拿来交课程设计、毕业设计，还是给中小型景区做信息化管理做参考，都挺有借鉴价值。

这篇文章不打算从头到尾罗列代码，而是把项目从数据库建模到前后端联调，再到部署踩坑的完整链路拆开讲一遍。我会把当时设计表结构的思路、购票扣库存为什么必须加事务、前端路由守卫怎么拦截未登录用户、打包部署时遇到的几个经典问题，全部摊在明面上说清楚。如果你正准备动手写一个类似的管理系统，这篇文章应该能帮你绕开不少弯路。

1. 项目定位与整体技术选型思路

1.1 古城景区管理的核心业务范围

先明确这套系统到底在解决什么问题。古城类景区的日常管理，表面上看着简单，实际跑一遍业务流程就会发现环节不少：游客要在线查看景区介绍、选择游玩日期、下单买票；景区运营方要维护景区基本信息、发布公告通知、核销门票；管理人员还得能实时掌握每天卖了多少票、收了多少钱、哪个时间段是客流高峰。

我把这些需求归拢了一下，大致可以划分成两条业务主线：

• 游客端（前台）：景区列表与详情、在线选票下单、查看个人订单、提交评价。
• 管理端（后台）：景区信息维护、门票库存与价格管理、订单查询与统计、公告发布、用户管理。

系统本身不追求大而全，核心就是把这套“游客在线买票、管理员后台管票”的闭环走通。边界划清楚之后，后面做数据库设计和接口设计就顺畅很多。其实很多项目做到一半开始改需求、加表加字段，根本原因就是前期没有把业务边界和角色权限想明白，导致代码越写越乱。

1.2 技术栈选择的逻辑与取舍

技术选型这部分，我用的是SpringBoot + Vue + MySQL这套经典组合，而且SpringBoot版本选的是2.x。为什么这么选，说几个实际考虑：

• 大多数教学环境和现有模板都基于SpringBoot 2.x，网上资料多，遇到问题容易搜到解决方案。SpringBoot 3.x虽然新，但要求JDK 17起步，很多学校机房和老服务器不一定能跑起来。
• Vue 2 + Element UI（或Vue 3 + Element Plus）这类后台管理组件库非常成熟，表格、表单、弹窗、分页整套UI组件拿来即用，不用自己造轮子。
• MySQL 5.7或8.0作为关系型数据库，对于景区这种数据量级完全够用，事务支持和统计查询都很稳定。

还有一个容易被忽略的点：为什么不用微服务？因为景区管理系统本质上属于中小型单体应用，用户量级和业务复杂度都远没到需要拆分的程度。如果一上来就上微服务、消息队列、分布式缓存，反而会把简单项目搞复杂。做技术选型的核心逻辑是“够用就好”，把余力放在业务实现和代码质量上。

2. 数据库建模与关键表结构设计

2.1 业务表拆解与关系梳理

数据库设计是整个系统的基础，表结构如果设计得不合理，后面写接口时就会到处补字段、拼SQL。我当时梳理出来的核心表一共七张，每张表都对应一条清晰的业务链路。

订单表和订单明细表为什么要拆成两张？因为一个订单可能包含多张票，比如游客一次性买了两张成人票、一张儿童票。如果只做一张订单表，每张票就要存一条订单记录，订单状态、下单时间、总金额这些信息全都要重复存一遍，不但冗余，统计“单量”的时候也会算错。拆成主表和子表之后，订单表存一次下单信息，订单明细表存三种票的明细，逻辑就顺了。

景区库存字段我直接设计在景区表里，字段叫stock，表示每日可售门票总数。这种设计在中小景区场景下是够用的。如果景区分淡旺季、不同日期库存不同，就要单独拆一张库存表，按日期维度去控制，那是更复杂的场景，这里不做扩展。

2.2 字段类型、索引与订单金额的细节处理

字段设计看着琐碎，其实里面藏着很多坑。我重点说三个地方。

第一，金额字段必须用DECIMAL而不是float或double。浮点数在计算时会有精度丢失问题，比如19.99加上0.01，用浮点算出来可能变成20.00000000004。我最初做的时候图省事用了double，结果月底对账时差了五分钱，排查了半天才发现是精度问题。金额统一用DECIMAL(10,2)最稳妥。

第二，订单号不要用自增ID。自增ID暴露在客户端容易被人猜到订单量，而且多表联查时容易混淆。我用的策略是时间戳加随机数：订单号 = 年月日时分秒 + 四位数随机数，单机场景下基本不会重复。如果要更严格，可以加一个流水号表统一生成。

第三，常用查询字段必须建索引。这张表结构设计里最容易被忽略的就是索引。景区列表查询按景区名称模糊搜索、订单查询按用户ID和时间范围筛选，这些字段如果不加索引，数据量一旦上千条就会明显变慢。我当时给users表的id、orders表的user_id和order_no、order_item表的order_id和scenic_id都加了索引，查询性能完全不用担心。

给一段核心表结构的示意，实际字段可以按需调整：

CREATE TABLE scenic_area ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT '景区名称', description TEXT COMMENT '景区介绍', price DECIMAL(10,2) NOT NULL COMMENT '门票单价', stock INT NOT NULL DEFAULT 0 COMMENT '可售票数', image_url VARCHAR(255) COMMENT '展示图片', status TINYINT DEFAULT 1 COMMENT '1上架 0下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

status字段用TINYINT存枚举值，而不是直接用字符串，这样数据库占空间小、查询效率高，Java端用常量或枚举类去映射，可读性也不差。

3. 后端SpringBoot核心功能实现详解

3.1 工程骨架与接口层设计规范

后端工程我是按标准的分层结构来搭的：controller、service、mapper、entity、config、common这几个包各司其职。Controller只负责接收参数和返回结果，Service层写业务逻辑，Mapper层操作数据库。很多新手容易犯的错误是把业务逻辑全部堆在Controller里，一个接口方法写几百行，后面想复用或排查问题都很痛苦。

接口设计上用了RESTful风格，比如：

• GET /api/scenic/list获取景区列表
• GET /api/scenic/{id}获取景区详情
• POST /api/order/create创建订单
• GET /api/order/myOrders查看我的订单
• POST /api/admin/login管理员登录

所有接口统一返回一个Result对象，包含code、message、data三个字段。这样前端在axios响应拦截器里只要判断code就能知道请求成不成功，不用每个接口单独处理异常。全局异常处理用@RestControllerAdvice，Service层抛出业务异常时，统一转换成对应的错误码返回给前端。

MyBatis-Plus这个工具非常推荐使用，它对单表CRUD提供了现成的BaseMapper，像景区列表的分页查询、用户信息的增删改查，基本不需要手写SQL。只有订单统计这类多表聚合查询才需要写自定义SQL。

3.2 购票扣库存与登录鉴权的关键逻辑

购票下单是整个系统的核心业务流程，这里有一条必须守住的红线：扣库存和生成订单必须放在同一个事务里，否则就会出现超卖或者数据不一致。我当时是这么写的：

@Transactional public OrderResult createOrder(OrderRequest req) { // 1. 校验景区是否存在且上架 ScenicArea scenic = scenicMapper.selectById(req.getScenicId()); if (scenic == null || scenic.getStatus() != 1) { throw new BizException("景区不存在或已下架"); } // 2. 校验库存是否充足 if (scenic.getStock() < req.getTicketCount()) { throw new BizException("库存不足"); } // 3. 扣减库存 scenic.setStock(scenic.getStock() - req.getTicketCount()); scenicMapper.updateById(scenic); // 4. 生成订单和订单明细 // 5. 返回订单号 }

这里我只做了逻辑层面的防超卖，用updateById直接覆盖库存字段，在高并发下其实是存在线程安全问题的。如果门票抢购峰值很高，更稳妥的是用乐观锁：更新库存时加上stock >= 扣减数量的条件，同时判断受影响行数。不过对于大部分景区管理系统，并发量远没到这个级别，逻辑校验加事务已经够用了。

登录鉴权我用的JWT方案。用户登录成功后，后端签发一个带过期时间的token返回给前端。前端每次请求在请求头带上token，后端通过一个拦截器统一校验。校验token的拦截器要排除登录、注册、获取景区列表这些不需要鉴权的公开接口，避免游客都进不来。

有一点提醒大家注意，JWT的密钥不要硬编码在代码里，放到application.yml配置文件中管理。如果要改造权限系统，可以从简单的角色字段开始，给用户表加一个role字段，拦截器里判断角色的接口权限即可，不需要一上来就引入Spring Security，那套东西学习成本不低，对小型项目是过度设计。

4. 前端Vue页面构建与联调实战

4.1 工程结构与路由权限设计

前端工程我用的Vue CLI脚手架，目录结构按功能拆：api目录统一放接口请求，views目录放页面组件，router目录配路由，store目录做全局状态管理。组件不追求过度封装，但api请求统一集中到一个文件里，方便管理接口地址。

路由设计上分了两个层级：游客可访问的公开页面和管理员的后台页面。游客页面包括首页景区列表、景区详情、登录注册；后台页面包括订单管理、景区管理、公告管理等。用路由守卫实现访问控制：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path.startsWith('/admin') && !token) { next('/login') } else { next() } })

这段逻辑很简单，但非常实用。前端守卫虽然拦不住刻意绕过的请求，但能提供正常用户的操作体验——未登录点后台菜单时直接被弹回登录页，而不是进入页面后才报接口错误。

4.2 核心页面交互与接口联调经验

页面实现这块，最核心的是景区列表页、购票页和后台管理页。景区列表页用了Element UI的卡片组件展示景区图片和简介，分页组件配合后端的分页接口。图片加载失败时要显示默认占位图，这个不起眼的细节如果忽略，列表页一旦有图片失效，整排卡片会很难看。

购票页的交互关键在于日期和数量选择。日期选择器禁用已售罄的日期，数量选择时实时计算总金额，并在提交前二次确认。这里我踩过一个坑：前端计算金额后在提交时又把金额传给后端，后端直接用前端传过来的金额入库。这样设计等于把金额控制权交给了前端，非常危险。正确做法是后端根据景区表里的单价重新计算金额，前端的金额只是展示用。

后台管理页主要在表格加弹窗的组合。景区信息编辑、公告发布都用Dialog弹窗完成，表格操作列放编辑和删除按钮。删除操作必须加一个二次确认的弹窗提示，防止误点把数据删了。订单列表的筛选条件包括订单号、用户账号、下单时间范围，后端用MyBatis-Plus的条件构造器拼动态查询条件。

axios封装这块也值得说。我在拦截器里统一做了token注入和错误提示：

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) service.interceptors.response.use( response => response.data, error => { if (error.response.status === 401) { router.push('/login') } Message.error(error.response.data.message || '请求失败') return Promise.reject(error) } )

统一在拦截器里处理401状态码，后端token过期时前端会自动跳转登录页，不用每个页面重复写一套判断逻辑。

5. 部署上线与高频问题排查记录

5.1 前后端环境搭建与打包部署

项目跑通本地联调之后，部署也是容易出问题的环节，我把整个流程和踩坑点一起说清楚。

后端打包部署比较标准：用IDEA里Maven的package命令打成jar包，然后在服务器上执行java -jar。打包前要注意application.yml里数据源的地址、用户名、密码，开发环境和生产环境要分开配置。我在一个项目里就吃过亏，把开发库的账号密码直接打进了生产包，上线后连接的是测试库，配置半天对不上。

前端部署麻烦一点。Vue项目构建后生成的是静态文件，需要放到Nginx的html目录下。Nginx还需要配置反向代理，把/api开头的请求转发到后端服务端口。同时要配置try_files解决前端路由刷新404的问题：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

这行配置很关键。如果不加try_files，Vue的BrowserRouter模式在访问/scenic/detail这类路径时，刷新页面就会返回404。原因在于前端路由是前端控制的，Nginx默认找不到对应的物理文件就报404，而try_files会把所有未匹配的路径都转回index.html，由Vue路由去解析。

前后端联调时的跨域问题，我推荐优先用前端开发服务器的proxy代理解决。在vue.config.js里配置：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

开发环境这么配，前端请求/api/xxx就会自动转发到后端地址，浏览器看到的请求是同源的，不会触发跨域。如果后端也同时配置了CORS，两者可能会重复处理，反而会导致部分请求出问题。我的经验是：开发环境用前端proxy，生产环境用Nginx反向代理，后端接口保持简洁，不在代码里加跨域处理。

5.2 常见问题速查与排查思路

项目开发过程中遇到的坑和解决思路，整理成表格方便查阅。

数据库时区这个问题值得多说一句。国内服务器时区默认是东八区，但MySQL连接如果没指定时区，JDBC驱动可能用系统默认时区去解析，前后会差出8个小时。排查的时候看着订单时间明明是下午三点下单，数据库里却存成了上午七点，这种问题仅靠看代码很难发现，一定要检查连接串参数。

还有一个非常常见的坑是图片上传后访问不到。系统里景区图片如果只是存在本地磁盘路径，部署后前端页面加载不出来。本地联调时后端http://localhost:8080/upload/xxx.jpg能访问，是因为后端应用直接暴露了静态资源。生产环境部署时，要么在后端配置静态资源映射，要么用独立的图片服务器，要么直接把图片转成Base64存库（不推荐）。最省事的方案是给SpringBoot配置虚拟路径映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath + "/"); } }

配置完这个，图片的访问路径才真正稳定。

最后说一个团队项目里容易“互相踩脚”的问题：多人写代码时接口变动频繁，前端调后端接口时发现字段对不上。我后来养成了一个习惯，每个接口写完先在Swagger或Knife4j上过一遍，确认返回字段和前端约定一致再进入联调。这个小动作能省掉大量“前端说缺字段、后端说没问题”的扯皮时间。这套古城景区管理系统做下来，最花时间的不是写代码，而是把业务边界和表结构梳理清楚。只要这两件事做扎实，后面的编码、联调、部署都是水到渠成的事。如果你正在做类似系统，可以从订单和库存表入手，先把核心表建全，再往细节里填，整体节奏会顺很多。