每年毕业设计选题季“旅游网站”都是计算机专业列表里的常客而一旦加上NodeJS这个方向基本就锁定了目标是轻量全栈应用。今天聊的这套编号27648的NodeJS旅游网站毕设源码是一个典型的ExpressMySQL项目游客能浏览景点和旅游线路注册用户能下单、评论、收藏管理员能在后台维护景点、审核订单前后端通过服务端模板渲染串成一条完整的业务链路。我拿到这套代码的第一印象是它没有为了凑功能而堆技术栈而是把“能答辩、能演示、能二次开发”三个目标平衡得很好。对正在发愁选题的同学来说它是一条能看清完整路径的Node全栈学习样本对已经学过JS基础、但没独立做过完整网站的新手它又是一份可以直接上手的参考工程。接下来我会从技术选型的理由、环境配置的实际坑点、核心模块的实现细节到运行期最容易踩的坑一条条掰开讲。1. 项目概述为什么说旅游网站是毕业设计的“黄金选题”1.1 这套源码到底做了什么从功能面板来看这套系统分前台和后台两条线。前台面向游客和注册用户包含网站的首页轮播、热门景点推荐、景点列表与详情页、旅游线路查询与线路详情、在线下单、个人中心里的订单查看、评论和收藏管理以及旅游攻略文章的阅读页。后台则面向管理员提供景点信息管理、旅游线路上下架、订单状态查询与处理、用户管理、评论审核和基础数据统计。这套功能范围选得很有讲究。如果做社交、做UGC视频、做实时聊天那复杂度会直接失控答辩时自己都讲不清如果只做静态的景点展示又撑不起“系统设计与实现”的体量。而“查景点、选线路、下订单、写点评”这条主线恰好把CRUD、关联查询、状态流转、会话管理、文件上传这些Web开发的核心知识点全部覆盖到了。这是它作为毕业设计最有价值的地方。1.2 为什么推荐NodeJS这个方向在学校课程里JavaWeb和PHP往往是主流但NodeJS近些年在不少高校已经进入选修课而且它的生态落地性极强。对毕设而言用NodeJSExpress有几个非常现实的优势不需要装Tomcat或其他重量级容器一个node命令就能服务起来演示环节非常干脆。npm生态极其庞大常见功能几乎都有成熟库可用不必重复造轮子。与前端同构学JS的人对回调、异步、模块机制天然熟悉上手快。Express框架本身非常轻中间件机制直观路由与处理函数界限清楚评审老师理解起来没有门槛。我曾经带过几个学弟做毕设选JavaWeb的那批光配置环境就折腾了两天选NodeJS的基本一个晚上就能把首页跑起来。不是JavaWeb不好而是对多数毕设场景来说NodeJS的投入产出比更高更容易把精力花在业务逻辑而不是框架配置上。2. 技术选型与系统架构拆解2.1 Express MySQL EJS为什么是这组搭配服务端框架选Express而不是Koa或NestJS考虑很直接。Koa的洋葱模型虽然设计漂亮但对新手来说理解中间件执行顺序要费一番功夫NestJS引入了装饰器、依赖注入、模块化这些企业级概念虽然工程化很强但学习曲线陡峭用在毕设里容易让代码看起来像“黑盒”。Express作为Node生态中最老牌、文档最齐全的框架路由、中间件、错误处理都足够直白能让评审老师在源码里快速读到你写的业务逻辑。数据库用MySQL而不是MongoDB也经过权衡。旅游网站这类业务有非常强的实体关联用户关联订单、订单关联线路、线路关联景点、评论又关联用户和景点。用关系型数据库做联表查询SQL写出来一目了然数据一致性也有保障。MongoDB对Node的友好度确实更高但做这类强关联业务时嵌入文档或引用方式反而容易绕晕。再加上MySQL在高校和企业里的普及度最高以“毕设应该采用成熟可靠技术”的答辩原则来说选MySQL是不二之选。模板引擎用EJS而没有做前后端分离这个选择很多人不理解。我说明一下毕设如果上Vue或React工作量会直接翻倍——要处理跨域、Token认证、动态路由、打包构建还要维护两套项目。而服务端渲染只需一套Node工程数据通过render直接注入模板浏览器一刷新就是最新数据。整套链路短、出错面小、演示方便代码量也更聚焦在业务逻辑上。等以后工作了再学前后端分离完全来得及毕业设计阶段追求的是“完整跑通”和“逻辑清晰”。2.2 数据库表结构设计思路这套源码的表结构不算复杂但每一张表都是围绕业务线设计出来的。核心是六张表表名作用关键字段user用户表username唯一、password哈希、role权限、phone、avatarscenic景点表name、category分类、region地区、intro、ticket_price、score、view_counttravel_line旅游线路表title、days天数、price、max_num上限、booked_num已报名、itinerary行程orders订单表order_no唯一订单号、user_id、line_id、total_price、status状态comments评论表user_id、target_type、target_id多态关联、content、scorecollect收藏表user_id、scenic_id、create_time这里最值得学习的是comments表的设计。评论既可以针对景点也可以针对旅游线路如果分别建表会非常啰嗦而且扩展性差。用target_type target_id的多态关联方式一张表就解决了两类评论需求查询时用WHERE target_type scenic AND target_id ?这样的条件即可。数据库字段设计合理与否直接决定后端的SQL好不好写这是我在改这套源码时最深的体会。2.3 目录分层与代码组织拿到源码后第一件事就是看目录结构。这套工程采用了标准的MVC分层travel-site/ ├── app.js # 入口文件 ├── config/ │ └── db.config.js # 数据库配置 ├── routes/ # 路由层 │ ├── index.js # 前台路由 │ ├── user.js # 用户相关 │ ├── scenic.js # 景点相关 │ ├── order.js # 订单相关 │ └── admin.js # 后台管理路由 ├── controllers/ # 控制器层业务逻辑 ├── models/ # 模型层SQL操作 ├── views/ # EJS模板 │ ├── front/ │ └── admin/ ├── middleware/ # 中间件 │ ├── auth.js # 登录校验 │ └── upload.js # 文件上传 ├── public/ # 静态资源 └── utils/ # 工具函数routes只管“这个URL交给谁处理”controllers里写具体业务逻辑models里写SQLviews只负责展示数据。这样的分层有很现实的好处后期加功能时不用在某个巨型文件里翻代码答辩时你可以很自信地跟评委说“我对代码做了模块化拆分遵循MVC设计模式”。很多拿高分的毕设并不一定功能多炫酷而是代码结构让人看着舒服。3. 环境搭建与运行前置准备3.1 NodeJS安装与环境变量配置这套项目要跑起来第一步是装NodeJS。我建议装官方LTS版本而不是最新的Current版本。LTS代表长期支持维护依赖兼容性更稳目前用v18或v20都是很不错的选择。下载Windows安装包或macOS安装包后一路Next安装关键在第二步那个“Add to PATH”一定要勾选。安装完成后打开终端验证node -v npm -v如果提示“node不是内部或外部命令”说明安装时的PATH没生效。手动打开系统环境变量把NodeJS安装目录默认是C:\Program Files\nodejs加到系统变量Path里重新打开终端即可。macOS用户则检查/usr/local/bin是否在PATH里。之所以强调环境变量这一步是因为后面所有npm操作都依赖node和npm这两个命令能全局识别。这一步没做好后面每一步都会报错而且报错信息还不直观。3.2 npm国内镜像源配置环境装好之后先别急着npm install一定要先把镜像源配好否则下载Express那一堆依赖能让你怀疑人生。由于默认npm源在境外国内网络环境下下载速度慢、超时是常态。这里直接配置国内镜像源也就是npmmirror它是淘宝npm镜像的继承者npm config set registry https://registry.npmmirror.com配置完成后验证一下npm config get registry也能用临时指定源的方式装包一次性的npm install express --registryhttps://registry.npmmirror.com这里提醒一句不要随便设置来路不明的私有源地址防止依赖包被篡改。如果你在学校或公司有内网npm源优先用内网源速度和安全都有保障。另外新开项目前可以先看一眼项目目录下的.npmrc文件确认当前registry指向是不是自己预期的地址。3.3 数据库导入与连接配置源码包一般会附带一个SQL文件比如travel.sql。你需要先在本地创建数据库并导入mysql -u root -p travel.sql或者用Navicat、MySQL Workbench这类图形工具直接执行SQL文件。导入完成后打开config/db.config.js把数据库账号密码改成你自己的。这一步看起来简单却是99%的启动失败源头——源码里的默认配置往往是root/123456跟你的实际环境对不上node起服务的时候连不上数据库报错一片红。字符集特别需要注意所有表建议使用utf8mb4而不是utf8。utf8mb4是utf8的超集能完整支持emoji和一些生僻字避免用户在评论里发个表情页面显示出来变成问号。建表语句里如果有这样的设置基本说明源码作者是踩过坑的CREATE DATABASE travel_site CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;3.4 高频报错npm.ps1禁止运行脚本很多初次启动项目的人会卡在一个报错上信息是npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本这个报错看起来吓人其实原因很简单Windows PowerShell的安全策略默认是Restricted禁止执行本地.ps1脚本。npm命令本身是一个npm.ps1脚本所以PowerShell直接拒绝运行了。有三种解决办法按推荐程度排序第一种是修改当前用户的执行策略。用管理员身份打开PowerShell执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned输入Y确认。RemoteSigned的意思是本地脚本允许执行从网络下载的脚本必须经过签名。这是兼顾安全与便利的方案。第二种是直接换终端。CMD命令提示符不受PowerShell执行策略限制打开CMD跑npm命令完全没这个报错。如果你不依赖PowerShell这是最快的应急方案。第三种是修改编辑器的默认终端。VS Code或WebStorm里可以把终端shell从PowerShell改成CMD这样每次打开终端都是CMD环境也规避了这个问题。理解了执行策略的设计目的后就不会觉得这是系统bug了。这是Windows的安全机制在起作用我们只是把安全级别调整到“允许本地脚本执行”而已。4. 核心功能模块的实现思路4.1 用户系统注册、登录与会话控制用户模块是整个网站的基础。注册的逻辑是前端把用户名、密码、确认密码提交过来后端先做基础校验非空、长度、两次密码一致然后对密码做哈希处理绝不允许明文存库。源码用的是bcryptjs库const bcrypt require(bcryptjs); const hash bcrypt.hashSync(password, 10);这里的数字10是盐的轮数轮数越高加密越强但计算越慢。10是安全性和性能的平衡点也是社区默认值。入库前还要做一次用户名查重避免重复注册。插入成功后跳转登录页。登录时从数据库查出用户记录用bcrypt.compareSync比对哈希if (row.length bcrypt.compareSync(password, row[0].password)) { req.session.user { id: row[0].id, username: row[0].username, role: row[0].role }; }登录成功的用户信息挂到session上后续所有需要登录的接口都通过中间件判断session是否存在。源码里有个auth中间件核心逻辑非常简洁function auth(req, res, next) { if (!req.session.user) { return res.redirect(/login); } next(); }需要登录才能访问的路由后面挂上auth就完事了router.get(/order, auth, handleOrder)。这里有一个可以让代码更完善的小技巧把当前登录用户注入res.locals.user所有EJS模板就能直接读取用户状态顶部导航栏可以动态显示“登录/注册”或“欢迎回来xxx”。4.2 景点与线路展示查询、分页与搜索游客访问的核心场景是浏览景点。景点列表页用了分页查询避免一次加载全部数据把页面拖垮const pageSize 10; const offset (page - 1) * pageSize; const sql SELECT * FROM scenic WHERE status 1 ORDER BY view_count DESC LIMIT ? OFFSET ?;LIMIT和OFFSET两个参数就是分页的两个控制点前端传页码过来后端计算offset。这个写法是MySQL分页的标准姿势值得记下来。景点详情页做了一个“同类推荐”区块根据当前景点的分类查出同类景点const sql SELECT * FROM scenic WHERE category ? AND id ! ? AND status 1 LIMIT 4;搜索功能用的是LIKE模糊匹配对name和intro做全文匹配。这里有个至关重要的点SQL必须使用参数化查询也就是问号占位符的方式绝对不能拼字符串。一旦把用户输入直接拼进SQL等于把SQL注入的大门打开评审老师看到这种代码会直接对安全性扣分。4.3 下单流程订单生成与并发控制下单是整个系统里最能体现业务深度的环节。用户选择一条线路填写出行人数、联系人和电话后端先计算总价再生成唯一订单号const orderNo new Date().getTime() Math.floor(Math.random() * 9000 1000);这种时间戳加随机数的订单号生成方式在并发量不高的毕设场景下完全够用。接着插入订单记录初始状态为待支付。下单的同时还要同步更新旅行线路的已报名人数这里有个教科书级别的细节——防止超卖UPDATE travel_line SET booked_num booked_num ? WHERE id ? AND booked_num ? max_num;带上booked_num ? max_num这个条件执行后如果受影响的记录数为0说明该线路名额已满订单创建失败。这就是一次典型的乐观锁并发控制用一条SQL就避免了多个用户同时下单导致名额超卖的问题。这个点讲出来评委基本都会点头。模拟支付也非常实在点击“去支付”后直接把订单状态从待支付改成已支付记录支付时间。毕设阶段不需要真实接入支付网关但把支付状态的流转逻辑做完整了整个订单闭环就成立。5. 运行期常见问题与排查技巧5.1 五类高频故障项目跑起来之后真正耗时间的是排错。我把运行期最高频的几类问题整理成速查表现象可能原因解决方案npm.ps1报错PowerShell执行策略限制Set-ExecutionPolicy -Scope CurrentUser RemoteSignedECONNREFUSED localhost:3306MySQL没启动或密码不对启动MySQL服务检查db.config.js账号密码ER_NOT_SUPPORTED_AUTH_MODEMySQL 8默认认证插件不兼容将用户改为mysql_native_password认证EADDRINUSE :::30003000端口被占用换端口启动或用netstat -ano查PID结束进程页面中文显示问号或乱码字符集不一致数据库表用utf8mb4模板加charsetutf-8其中ER_NOT_SUPPORTED_AUTH_MODE这个报错特别典型。MySQL 8.0默认使用caching_sha2_password认证插件而node的mysql2老版本对这个认证方式兼容性不佳。解决办法是在MySQL里执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;如果源码里用的已经是新版本mysql2这个报错通常不会出现但以防万一这个命令还是记住比较好。5.2 调试经验与避坑笔记除了上面的硬错误我再分享几条自己调试这套系统时的经验。一是排错顺序要固定。先看终端启动时有没有堆栈输出再看是否有SQL相关的报错信息最后才去翻页面显示效果。不要一看到白屏就去怀疑代码逻辑多半是数据没传过去或模板路径写错了。二是session相关的问题。如果页面登录功能正常但刷新后一直跳回登录页大概率是session没有写入成功。检查一下cookie里有没有connect.sid这个值如果完全没有说明session中间件的初始化顺序可能不对。app.use(session())一定要放在路由挂载之前。三是文件上传问题。攻略模块上传封面图用的是Multer中间件前端表单的name属性必须和后端multer.single(file)里的字段名完全一致否则req.file就是undefined接口报错。这类问题不看前端就永远找不到原因前后端联调是绕不开的基本功。四是部署到云服务器时别忘了设置环境变量NODE_ENVproduction。Express在生产模式下会禁用对外的错误栈信息泄露对安全性是有实际帮助的。很多同学在本地跑得好好的一部署就各种报错往往是忽略了环境变量的差异。在最后多说几句实际上手跑完这套源码之后我最想跟读者强调的是“流程大于功能”。第一次启动项目不要急着改页面样式先把注册、登录、看景点、下订单、看订单、写评论这条主链路完整走一遍。当你把数据从一张表流到另一张表的路径摸清楚后面改任何功能都有了底气。另外给一个很实用的建议答辩演示前把开发环境里所有版本号心里默背一遍——NodeJS版本、npm版本、MySQL版本、核心依赖express的版本。评委非常喜欢问“你这个项目的版本环境是什么”“如果换一个环境能不能跑起来”。这些细节问题答得顺比任何炫酷功能都加分。准备好的环境就是你给“系统可复现”这个命题交出的最扎实答案。