用户信息管理系统课程设计全攻略：从技术选型到Lodop打印

简介：武汉理工大学计算机学院Web技术课程设计大作业，基于Spring、Spring MVC、MyBatis三大框架搭建的用户信息管理系统，适合正在完成SSM项目作业或入门Java Web开发的高校学生参考。系统实现了用户注册、登录、注销、密码修改、个人资料编辑，以及用户信息的列表展示、分页查询、编辑和删除等完整功能；前端采用响应式布局，屏幕宽度小于800px时自动隐藏左侧菜单，并支持蓝色、橘黄等主题风格切换。资源包共78个文件，约1.81MB，以java源码、xml配置、sql数据库脚本、css样式、js脚本和png界面截图为主，附带README说明文档，目录结构清晰，便于对照学习。通过完整源码和数据库脚本，可以快速运行项目，并理解SSM整合、拦截器、分页查询、Ajax交互等关键实现细节。已有3054人学习下载，对课程设计或SSM框架实践具有不错的参考价值。 用户信息管理系统，这大概是Web技术课程设计里出现频率最高的题目了。每年期末都能看到一批人在问：JSP到底要不要学、数据库连不上怎么办、用户列表分页怎么做、最后那个打印功能到底怎么实现。说实话，这个题目看起来简单，做起来坑非常多，我在做课程设计的时候踩过不少雷，后来帮学弟学妹看项目时也发现，八成问题都集中在几个相同的环节。

这篇就把我从需求拆解、技术选型、数据库设计、前后端实现，到Lodop打印控件接入、答辩准备，完整梳理一遍。适合正在做Web技术大作业的同学参考，也适合想把这个项目包装成毕业设计或简历项目的朋友看看。

1. 需求拆解与技术选型：先想清楚再动手，别急着写代码

1.1 把大作业需求拆成功能清单

课程设计题目通常要求一个完整的用户管理闭环，不要拿到题目就直接去写代码。我的习惯是先画功能清单：登录注册、用户信息列表展示、新增/编辑/删除、按条件搜索、分页浏览、会话控制与退出登录，再加上一个用户信息的打印导出。

这些功能拆开看都很基础，但拼在一起正好覆盖Web开发里最核心的三层概念：前端页面展示、后端业务处理、数据库持久化。说白了，老师要考察的本质不是用了多炫的框架，而是这三个层面是否理顺了。如果你的题目是多用户权限版本，可以再加上管理员和普通用户两种角色，给权限判断预留逻辑。

这个环节有一个很实用的技巧：把功能清单分两档写。第一档是必须完成的保底功能，第二档是加分功能。保底功能确保能跑通，加分功能用来展示设计深度。我当时给自己定的加分项就是打印控件、批量删除、数据导出，事实证明真的有用。

1.2 技术栈选型：课程设计阶段最怕什么

这个阶段最怕的不是功能难题，而是环境搭不起来、运行时到处报错、答辩时讲不清原理。

我自己比较推荐Servlet + JSP + MySQL这套经典组合。原因很实际：第一，Java Web课程配套资源最丰富，网上能找到大量相似案例；第二，Servlet处理请求和响应的过程足够基础，答辩时你可以把整个请求生命周期讲给老师听；第三，部署到Tomcat上简单直接，不需要额外构建工具。如果你已经能熟练使用Spring Boot，当然也可以换成Spring Boot + Thymeleaf，做完以后项目看起来更现代，但要注意必须讲清楚自动配置和依赖注入的原理，否则容易被追问到卡壳。

前端方面我不建议花太多时间搞框架。用原生HTML + CSS + JavaScript加一点Ajax就足够。表格展示用普通样式或Bootstrap都行，重点是交互流程完整、代码能读。界面丑一点真心问题不大，课程设计看中的是逻辑闭环，不是视觉设计比赛。

数据库方面，MySQL和SQLite都可以。SQLite胜在无配置、文件型数据库，交作业方便；MySQL更贴近真实业务。如果电脑内存紧张或安装MySQL时老出问题，可以选SQLite，但设计文档里要说明为什么做这个替代。我个人的建议是如果是课程设计，直接上MySQL，因为企业里基本都用它，早接触早熟悉。

2. 数据库设计与后端核心逻辑：建表建不好，后面全是泪

2.1 用户表到底怎么设计才不给自己埋雷

很多同学会直接写一张user表，字段无外乎用户名、密码、姓名、手机号。但做完几个项目之后你会发现，有几个字段必须提前加上，不然后面改起来很痛苦。

我的建议是核心字段至少包括：id（自增主键）、username（登录名）、password（加密后的密码）、real_name（真实姓名）、phone（手机号）、email（邮箱）、status（账号状态，1正常0禁用）、create_time（创建时间）、update_time（更新时间）、role（角色，admin/user）。

这张表里要特别提醒三个点。

第一，密码永远不要存明文。课程设计里哪怕用MD5加固定盐值做一次散列，也比明文强太多。答辩时老师看到你做了一步密码保护，印象分会明显不一样。

第二，时间字段建议默认值自动填充。create_time用datetime类型加default current_timestamp，update_time可以由数据库自动更新。这样你查数据时能看到注册时间，很多页面展示细节就不缺数据了。

第三，status字段很多人会漏掉。但它一旦设计出来，账号禁用、注销这类功能就有了基础，甚至能扩展出更完整的后台管理逻辑，属于投入产出比极高的一个字段。

建表SQL示例：

CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(128) NOT NULL, real_name VARCHAR(50), phone VARCHAR(20), email VARCHAR(100), status TINYINT DEFAULT 1, role VARCHAR(10) DEFAULT 'user', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

如果你用不同数据库，注意UNIQUE约束和默认时间戳写法略有差异。字段命名统一用下划线风格，Java实体类里用驼峰，用MyBatis或手写映射配置处理即可，避免出现大小写不一致查不到字段的怪问题。

2.2 登录会话与权限控制：过滤器这一个点能救你一命

用户信息管理系统里，登录逻辑不难，难在登录之后怎么知道你是谁，以及谁有权限访问什么页面。

我的做法是：用户登录成功后，把用户id、用户名、角色塞进Session，同时生成一个会话标识。每次访问受保护资源时，由一个Filter统一判断Session是否存在，不存在就跳回登录页。这样你不用在每个Servlet里重复写判断代码。

核心代码示例如下：

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; HttpSession session = req.getSession(false); String uri = req.getRequestURI(); // 登录页、静态资源直接放行 if (uri.endsWith("login.jsp") || uri.endsWith("/login") || uri.contains("/static/")) { chain.doFilter(request, response); return; } if (session == null || session.getAttribute("loginUser") == null) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); }

这段代码里有一个特别容易被忽略的细节：getSession(false) 和 getSession() 的区别很大。如果当前没有会话，getSession()会自动创建一个新Session，导致你判断“是否登录”时永远不为空，过滤器形同虚设。用getSession(false)不会自动创建，才能正确判断登录态。

权限控制如果做双角色，可以在Filter里继续判断role，或者在需要管理员操作的Servlet里单独校验。管理员删除用户、批量操作这类接口一定要做后端权限判断，不能只在前端隐藏按钮，否则别人直接构造请求就能绕过，这个安全点必须守住。

3. 前端页面与交互实现：先把流程跑通，再考虑优化体验

3.1 页面划分与路由设计

对这种课程设计，页面建议规划为：login.jsp登录页、register.jsp注册页、list.jsp用户列表页、edit.jsp编辑页（或者用弹窗实现），再加顶部导航和退出登录按钮。

如果用Servlet做后端，路由就映射到对应Servlet路径。例如/listUser请求进入用户查询逻辑，返回转发到list.jsp；/addUser处理新增表单提交；/updateUser处理修改；/deleteUser处理删除。这个路径规划最好在动手前画一张简单的表格，列出每个功能对应的URL、Servlet、JSP页面，避免写到一半乱套。

我见过很多同学把业务逻辑直接写进JSP页面里。JSP页面里偶尔用一点JSTL或EL表达式没问题，但大段Java代码写在<% %>块里非常难看，答辩时也讲不出分层。建议至少做到：JSP只负责展示，Servlet负责接收参数和调用业务，DAO层负责数据库操作。哪怕只是物理上分成三个包，也足以体现分层思想了。

3.2 列表分页与条件搜索

用户列表不夸张地说，是整个项目的核心展示点。很多同学的实现是一次查出所有数据，在前端JS里做翻页，这在小数据量下能跑，但完全经不起追问。老师只要问一句“如果有一百万条用户记录怎么处理”，就答不上来了。

正确做法是后端分页。页码page和每页条数pageSize由前端传参，SQL里用LIMIT offset, pageSize，同时计算总记录数total，前端根据total和pageSize算出总页数。查询接口接收到page和pageSize之后，先查总条数，再查当前页数据，把结果封装成一个Page对象传给前端。Page对象包含list、total、pageNum、pageSize、pages等字段，前端拿到后渲染表格和页码按钮即可。

搜索条件同理，不要在前端过滤数据集。将keyword参数传到后端，在SQL的WHERE子句里做模糊查询，和分页条件合并。这里必须强调：SQL拼接时一定要用预编译的PreparedStatement或参数绑定，绝对不要用字符串拼接SQL，这是最基本的安全底线。

前端调用接口的代码可以简洁一些：

async function loadPage(page) { const resp = await fetch(`/listUser?page=${page}&pageSize=10&keyword=${keyword}`); const data = await resp.json(); renderTable(data.list); renderPagination(data.pages, data.pageNum); }

表单校验这块说一个实用经验：前端校验为了用户体验，后端必须再校验一遍，这是安全防线。用户名是否已存在、手机号格式、邮箱格式这类逻辑，两边都要有，各写一份，千万不能因为后端麻烦就省略。

4. 打印报表功能：Lodop控件的接入与避坑

4.1 为什么课程设计里要加打印功能

用户信息管理系统如果只做增删改查，总感觉单薄了一点。把打印用户列表或打印用户信息卡片做进去，等于把项目从Web数据库应用向实际业务系统靠了一步。Lodop是一个非常经典的选择，它是一款Web打印控件，原理是网页通过JavaScript调用本地打印服务，把页面内容或模板输出到打印机。

它解决的问题很明确：浏览器自带的打印排版不可控，页眉页脚难处理，表格、标签这类场景很难做。Lodop可以在网页里精确控制纸张大小、边距、打印项坐标，所以实际开发里很多管理系统的打印都靠它。课程设计里加上这个功能，加分是实实在在的，而且这个技能在工作后也经常能用上。

4.2 Lodop接入的4个步骤

第一步，下载并安装Lodop本地打印服务程序。注意，控件是客户端程序，需要在这台电脑上运行，网页JS才能调用到它。很多同学第一次写的时候只写了前端JS，没有安装服务端程序，一调用就报错，这个顺序一定要搞清楚。

第二步，在页面里引入Lodop的JS文件。下载包里有一个LodopFuncs.js，里面封装了获取Lodop对象的逻辑，处理了不同浏览器下的对象创建方式，不要自己凭感觉手写，拿过来直接用就好。

<script src="js/LodopFuncs.js"></script>

第三步是核心，写打印模板代码。Lodop的打印原理是拼一个指令序列，然后调用PRINT或PREVIEW方法输出。我最常用的组合是初始化LODOP对象、设置打印纸张、向页面添加文本或表格项，最后预览打印。

这里给一个精简示例：

var LODOP = getLodop(); if (!LODOP) { alert("请先安装打印控件"); return; } LODOP.PRINT_INIT("用户信息打印"); LODOP.SET_PRINT_PAGESIZE(1, 2000, 1000, "用户信息表"); var html = document.getElementById("printArea").innerHTML; LODOP.ADD_PRINT_HTM(20, 20, 700, 900, html); LODOP.PREVIEW();

第四步是测试。答辩现场强烈建议用PREVIEW预览模式，不要直接调PRINT直接送打印机，因为演示环境未必有物理打印机，预览打印效果给老师看就足以说明功能实现。

4.3 Lodop最常见问题自查

整理几个高频问题的排查方向，遇到报错先对照检查。

5. 高频问题自查与答辩准备

5.1 这些Bug我几乎每年都见

做课程设计，最浪费时间的就是排查环境问题。我把真实遇到过高频问题整理成自查表，按这个找基本能解决。

5.2 答辩前必须想清楚的几个问题

答辩时老师常问的问题其实高度重复，提前准备就能稳定发挥。

第一个问题是项目分了几层，每层职责是什么。如果你做了Servlet + Service + DAO分层，就直接说：Servlet接收请求参数并控制页面跳转，Service处理业务规则，DAO做数据库读写。

第二个问题是登录状态怎么保持。要把Session机制讲清楚，最好能提到Filter过滤器统一校验登录态，体现出你对会话管理的理解。

第三个问题是密码怎么存储的。如果不小心用了明文，答辩时真的会很尴尬。提前改成MD5加盐，或者用更通用的哈希算法，一句话就能解释清楚。

第四个问题是分页怎么实现。能说出LIMIT offset, pageSize，再解释一下为什么数据量大时不能一次性查全部，这个点就过了。

还有一个加分技巧：提前准备演示数据。答辩前在系统里预置20到30条测试数据，覆盖各种状态，比如不同角色、不同账号状态、包含特殊字符的用户名。现场演示时快速展示分页、搜索、编辑、打印，整个过程就不会冷场，也显得你对系统更熟悉。

从拿到题目到完成，我自己的时间安排是：需求拆解和技术选型占一成，数据库设计和后端逻辑占三成，前端页面占两成，打印等扩展功能和整体测试打磨占四成。很多人把时间花在调界面上，结果核心功能反而不稳定，到了答辩才来补救，这是把顺序搞反了。如果你正在做这个项目，先把不带页面样式的完整流程跑通，再加打印、导出、批量操作这些亮点功能。能稳定地完整演示一遍，比做十个界面精美的半成品都有用。后面如果有余力，还可以继续加入图片上传、操作日志、多条件组合筛选等功能，让项目在课程设计基础上更进一步。

本文还有配套的精品资源，点击获取