点此查看 所有教程、项目、源码导航
文章目录
- [1. 本篇任务说明](#1. 本篇任务说明)
- [2. 项目整体回顾](#2. 项目整体回顾)
- [3. 当前方案已经实现的能力](#3. 当前方案已经实现的能力)
- [4. 当前项目存在的问题](#4. 当前项目存在的问题)
- [5. 如果继续升级，可以往哪些方向走](#5. 如果继续升级，可以往哪些方向走)
- [6. 结束语](#6. 结束语)
- [7. 作者后话](#7. 作者后话)
1. 本篇任务说明
毛哥：副队，我们全部功能都写完了，是不是可以收尾了？
副队：对，这是整个教程的最后一篇。我们一起回顾一下整个项目，同时聊聊这套方案现存的短板，重点把项目里一处很关键的业务漏洞拿出来说清楚，知道它能做什么，以及为什么不能直接上线商用。
2. 项目整体回顾
副队：咱们从头到尾搭建的是一个社团活动发布报名平台，整套项目采用前后端分离，前端使用原生 HTML、CSS、JavaScript，后端基于 SpringBoot(当然后端其实不用管具体使用的什么技术)，约定全部接口使用 POST，统一返回
{code, msg, data}。毛哥：我梳理一下，最开始我们先敲定接口文档，之后搭建静态页面，接着对接接口，实现活动的查询、新增、修改、删除，再完成学生端查看活动与报名功能，最后补上登录校验、角色区分。
副队：没错。文件结构简单，所有页面、JS、CSS 放在同一目录；公共样式、通用请求函数单独抽离，弹窗、表格、导航都作为复用组件。登录采用 token 方案，前端用 localStorage 保存凭证，页面加载时增加访问拦截，未登录或者角色不匹配就跳转到登录页。
毛哥：跑起来效果确实没问题：管理员维护活动，学生浏览活动、提交报名，没有登录的用户无法直接访问后台和学生页面。
3. 当前方案已经实现的能力
副队：我们先整理已经落地的功能。
- ✅ 接口规范统一 ：全部使用 POST 请求，后端返回固定结构；前端封装通用
postRequest，统一发送请求、解析响应、捕获异常、处理 401 登录失效。- ✅ 活动管理后台：管理员查看活动列表、新增、编辑、删除活动；新增和编辑复用同一弹窗，减少重复代码。
- ✅ 学生端页面：学生浏览活动，提交活动报名。
- ✅ 登录与权限：独立登录页面，凭证持久化存储；学生页面、管理员页面都增加前端拦截；登录成功根据角色自动跳转对应页面。
- ✅ 基础交互规范：弹窗居中，样式统一，导航栏右侧放置用户信息与退出按钮；CSS 拆分为公共样式和页面专属样式。
4. 当前项目存在的问题
毛哥：看起来功能齐全，但是应该还有不少缺陷吧？
副队：是的，这只是入门实战项目，目标是打通流程，很多生产环境需要考虑的地方都做了简化，其中有一个非常关键的业务漏洞。
毛哥：是什么漏洞？
副队：就是报名逻辑没有和当前登录用户身份强制绑定。现在前端提交报名的时候，如果我们只是手动传入姓名、学号这类信息，用户可以随便填写，哪怕已经登录，也可以填别人的学号，或者反复提交报名。正确的做法是：后端从请求携带的 token 里面解析出当前登录用户的学号、用户 ID，报名信息以 token 解析出来的身份为准，前端传入的身份信息只做展示，不做信任来源。就算前端篡改表单里面的学号，后端也会忽略，以 token 里面解析到的用户为准。
毛哥：我懂了！也就是说，不能相信前端传过来是谁，是谁在操作，由 token 说了算。
副队：没错。这个是业务层面的核心安全点。除此之外还有其他问题，我们分开来说。
副队：先继续说前端这边的问题。
第一，使用原生 JavaScript，没有框架。如果业务持续扩张，大量 DOM 操作会越来越杂乱，不容易维护，缺少组件化能力，新增页面时重复代码会持续变多。
第二，交互提示简陋，全部依靠 alert，没有优雅的消息提示框、加载 loading；网络延迟的时候，用户不知道请求正在处理，容易连续点击，造成重复提交。
第三，表单校验薄弱，目前只做简单的非空判断，缺少长度、格式实时校验，也没有防重复提交标记。
第四，localStorage 里面存放的角色仅仅只能用来做前端体验拦截，用户可以手动修改存储内容，不能依靠它实现真正的权限控制，权限校验必须放在后端。
第五，没有分页功能，如果活动数量变多，一次性返回全部数据，加载缓慢，消耗流量。
毛哥：那后端还有哪些不足？
副队：后端同样有很多简化点。
第一，我们当前使用的 token，默认无法主动作废。现在只是前端删除 token，如果拿到 token 的人在过期之前使用，依然可以调用接口；想要实现退出立刻失效，需要维护 token 黑名单。
第二，密码保护不足，如果直接明文传递密码，抓包可以获取；正式环境必须部署 HTTPS，增加对应的加密处理。
第三，参数校验、全局异常处理不够完善，非法参数传入时返回提示粗糙；缺少接口限流，容易遭到恶意频繁调用。
第四，没有操作日志，无法记录是谁、在什么时候执行新增、删除操作，如果出现误操作很难追溯。
第五，权限粒度比较粗，只有管理员和学生两种角色，如果后续需要社团审核人、活动负责人等角色，这套权限模型不够灵活。
除此之外，项目还缺少活动封面上传、报名名单导出、消息通知，移动端适配也只是基础，没有深度优化。
5. 如果继续升级，可以往哪些方向走
毛哥：如果我想继续完善这个项目，优先做哪些改动？
副队：优先补上刚才说到的身份绑定，再依次迭代其他功能，推荐这个顺序。
- 修复报名身份绑定：改造报名接口，后端从 token 获取当前登录用户信息，报名记录绑定 token 对应的用户，不再信任前端提交的学号、身份信息；同时增加限制，同一个用户不能重复报名同一个活动。
- 体验优化：替换 alert，增加 loading 和消息提示，增加防重复提交逻辑，完善表单校验。
- 增加分页：活动列表、报名列表改为后端分页返回，降低数据传输压力。
- 安全加固：部署 HTTPS，完善后端参数校验，增加接口限流，实现 token 黑名单。
- 拓展业务功能：活动封面上传、报名名单导出、活动上下架、消息通知。
- 技术进阶：如果想要继续学习，可以把前端迁移到 Vue，后端搭建一套更加完善的权限系统。
6. 结束语
毛哥：听你说完这么多缺点，那咱们这个项目是不是算做得比较差？
副队：倒不能这么理解。虽然还有一堆待优化的地方，但是整体是完整、可用的，作为学习项目来说已经非常不错了。一条完整的前后端链路我们从头到尾亲手走完，从定接口、写静态页面、对接 AJAX，到增删改查、登录鉴权，每一块都动手实现，该踩的坑也都认识到了。
毛哥：对，我感觉跟着做完一遍，终于明白前后端是怎么配合的了，之前看书总是很抽象。
副队：这就是咱们这个教程最核心的目标。它不需要一步到位做成商用产品，只要帮你建立起整套开发思维，弄懂流程、分清安全边界，这次学习的目的就完全达到了。后面你再去学框架、做更复杂的系统，心里就有底。
毛哥：明白了！先跑通，再慢慢打磨，这就是学习做项目的节奏。
副队：没错。如果之后想拓展新功能，或者尝试使用其他技术栈重写，这个项目都可以作为很好的基础。
7. 作者后话
其实写这么多东西，我个人感觉已经太多了。如果把其他功能再完善，在这个时期反而会大大增加初学者的难度。
我从心底认为，一个初学者在学习了HTML+CSS+JS之后，能把一个项目完整做到这个程度，已经是完完全全可以了。
所以后续的内容，我们会在学习更多知识后，进一步完善吧。
不积跬步，无以至千里，不积小流，无以成江海。
学习编程，莫不如是。