简介面向武汉理工大学计算机学院Web技术课程设计这份资源基于Spring、Spring MVC和MyBatis的SSM整合框架实现了包含用户注册、登录、个人资料修改、密码找回与修改、用户信息增删改查及分页搜索在内的完整用户信息管理系统。前端页面采用响应式设计当屏幕宽度小于800像素时自动隐藏左侧菜单并提供蓝色、橘黄等多主题风格切换兼顾电脑与移动设备。压缩包共78个文件包含9个Java类、6个XML配置文件、6个HTML页面、15个CSS样式、7个JavaScript脚本、1个SQL数据库脚本和README说明文档等包体仅1.81MB结构按document、sql、img等目录划分便于查阅。目前已有3054人学习/下载适合SSM初学者跟随项目理解框架运作流程也适合课程设计或综合实践直接参考。项目附带可直接执行的数据库脚本和完整界面截图可快速搭建环境并对照验证各模块功能减少从零搭建的时间成本。1. 项目选题与整体设计思路为什么我选了用户信息管理系统每年到了Web技术课程设计的时候计算机学院的同学们就集体犯难。题目发下来从电商网站到在线考试系统看起来选择很多但真要动手就会发现要么业务逻辑太复杂——比如带秒杀、带支付、带推荐算法的电商凭一门课的知识量根本兜不住要么又太简单随便堆几个页面交上去答辩的时候一问三不知直接被老师盯上追问到底。最后我选的是“用户信息管理系统”原因其实很简单CRUD是Web开发的骨架把这个骨架搭扎实了后面加什么功能都不慌。用户信息管理系统说穿了就是做一套增删改查管理员登录、用户列表展示、按条件搜索、新增用户、编辑用户、删除用户再把数据存进数据库。听起来平平无奇但恰恰是这种“平平无奇”最适合当课程设计。一方面它覆盖了Web开发最核心的全链路——前端页面、后端接口、数据库设计、权限控制、异常处理一个都不少另一方面它的业务边界很清楚不会让你陷入“功能太多做不完”的泥潭你有足够精力把每个环节做到完整、规范甚至有余力加一些出彩的细节。我在这套系统里加的“出彩细节”就是Lodop打印控件。用户列表里可以勾选几条记录一键打印成纸质档案这个功能在答辩演示时非常直观老师看一眼就知道你对Web打印方案有过实际调研。后面我会专门用一整个章节来讲Lodop的集成过程和踩坑记录这也是这次大作业里最有技术含金量的部分。1.1 课程设计题目的通病与破局点选过课设题目的同学应该都有体会不是题目不好做的才坑反而是那些看起来“人人都会做”的题目最容易翻车。因为做的人太多了老师一眼就能看出你是自己写的还是网上抄的。很多同学交上来的用户管理系统清一色Bootstrap jQuery列表分页是假分页——数据一次性全查出来前端靠JS切片删除用户没有二次确认点一下就直接执行密码明文存数据库连个MD5都懒得加密。这种项目拿去验收能过是运气过不了是本分。我给自己定的破局方向是不搞花哨的前端框架把后端工程化做到位找一个别人不常用的技术点打开差异化。所以整个项目采用了Spring Boot MyBatis-Plus Thymeleaf MySQL的组合前端没有引入Vue这类重框架而是用服务端渲染加原生JS处理页面交互。这样做的考量很简单——课程设计的评分重点在“对Web技术的综合掌握”老老实实把服务端渲染、模板引擎、拦截器、参数校验这些基本功做明白比套一个现成的前后端分离脚手架更有说服力。1.2 功能模块划分与技术栈选型功能模块我只规划了四个用户管理增删改查加批量删除、部门管理给用户挂一个归属部门列表筛选用、操作日志记录谁在什么时间做了什么操作、打印模块Lodop打印用户档案。为什么要把操作日志也算进去因为“用户信息管理系统”如果连操作日志都没有那管理端的“管理”二字就站不住脚。加了日志模块之后项目的技术层次立刻就不一样了——你需要处理AOP拦截、异步记录、日志列表查询这些东西写起来不难但对答辩来讲是实打实的亮点。技术栈这一块我没有用太新的东西。Spring Boot的版本用的2.7.x刚好是稳定期MyBatis-Plus做单表CRUD确实能省掉大量重复的XML配置模板引擎选了Thymeleaf和Spring Boot是原生一家人集成几乎零成本。前端样式我偷了个懒直接用的Bootstrap 5的CDN真要我从零写一套响应式布局课设周期根本不够。但这里有个小建议用CDN没问题但要在论文里写清楚为什么选Bootstrap而不是自己写CSS——因为开发效率高、浏览器兼容性好重点突出你做过技术选型对比而不是单纯偷懒。2. 数据库设计先把表结构想明白再写代码很多同学上手就写代码写到一半发现表结构缺字段改来改去全是泪。我在这个大作业里吃过同样的亏所以这次学乖了建表之前先花了半天时间把表结构定清楚。数据库设计这件事直接决定了后续开发是坦途还是天坑尤其是用户信息管理系统这种以数据为核心的项目表结构一旦定了后面改动的成本非常高。在写第一行业务代码之前先把SQL脚本写好这是课设项目不翻车的第一条铁律。实操中我建议把SQL脚本维护成一个独立的schema.sql文件并且要保证这个脚本“从头执行一遍就能把库建出来”这是检验表结构是否完整、依赖顺序是否正确的唯一标准。如果你需要给老师演示他问你“数据库怎么建的”你直接把这个文件拿给他看比在MySQL里翻半天强得多。2.1 用户主表与角色权限表设计用户主表是所有系统的核心表我在设计时除了基础字段还加入了状态字段和逻辑删除标记。先看这张表的结构这是按通用场景整理的核心字段具体项目可以按需增减CREATE TABLE sys_user ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, username varchar(50) NOT NULL COMMENT 登录用户名, password varchar(100) NOT NULL COMMENT 密码加密存储, real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, gender tinyint(1) DEFAULT NULL COMMENT 性别0未知 1男 2女, phone varchar(20) DEFAULT NULL COMMENT 手机号, email varchar(100) DEFAULT NULL COMMENT 邮箱, dept_id bigint(20) DEFAULT NULL COMMENT 所属部门ID, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 状态1启用 0禁用, deleted tinyint(1) NOT NULL DEFAULT 0 COMMENT 逻辑删除0未删 1已删, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB AUTO_INCREMENT1001 DEFAULT CHARSETutf8mb4 COMMENT用户信息表;这张表的几个关键设计点值得展开说。第一password字段的长度我留了100个字符而不是传统的32位因为现在推荐用BCrypt加密BCrypt生成的哈希字符串是60位32位的MD5字段根本存不下。很多课设做完才发现密码加密串存不进去就是因为字段长度设计时没考虑算法变化。第二deleted字段用于逻辑删除删除用户时执行的是UPDATE而不是DELETE这样做的好处是数据可恢复而且不会破坏外键关系。MyBatis-Plus的TableLogic注解可以自动帮你在查询时拼接deleted 0条件非常省心。第三AUTO_INCREMENT我从1001开始这是个小细节——演示的时候前端展示的ID不会是从1开始的“教学号”看起来更像真实系统的数据。角色权限这块因为用户信息管理系统本身不算大我并没有引入Spring Security或者Shiro这样重型的权限框架而是自己用一张角色表和一张用户角色关联表来模拟RBAC基于角色的访问控制。具体做法是用户表关联角色表角色表里有一个role_code字段登录成功后把角色编码存进Session在拦截器里判断role_code是否允许访问当前接口。这套方案做起来很快应对课设答辩完全够用。如果你时间充裕后端可以引入Spring Security做更规范的权限控制但要注意学习成本别因为框架反而拖慢了进度。2.2 操作日志表与数据字典的设计细节操作日志表我单独设计了一张sys_operation_log表用来记录关键操作行为。日志表不一定需要记录非常明细的信息但“谁、在什么时间、做了什么操作、操作是否成功”这四要素一定要覆盖到。我用MyBatis-Plus的字段自动填充功能处理create_time再结合Spring AOP切面统一记录日志核心代码逻辑写在切面里业务代码完全无侵入。CREATE TABLE sys_operation_log ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) DEFAULT NULL COMMENT 操作人用户名, operation varchar(100) DEFAULT NULL COMMENT 操作描述, method varchar(200) DEFAULT NULL COMMENT 请求方法, params text COMMENT 请求参数, ip varchar(50) DEFAULT NULL COMMENT 请求IP, status tinyint(1) DEFAULT NULL COMMENT 1成功 0失败, error_msg text COMMENT 异常信息, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT操作日志表;关于这个表我踩过一个坑一开始我用TEXT类型存params参数结果某个接口传了很长的JSON导致日志表比业务表还大。后来我加了限制只截取前500个字符存入日志。这提醒我日志记录不是越多越好合理控制日志体积和有效信息量才是关键。数据字典则是考虑到这个系统以后可能扩展比如性别、状态、部门层级这些字段如果硬编码在代码里将来改起来非常痛苦。我设计了一张简单的sys_dict表用dict_type和dict_value两个字段来标识字典项前端页面通过接口读取字典渲染下拉框。虽然这个系统里字典表的用处只体现在性别和状态下拉框但整个设计思路是通用的也让数据库设计更有层次感。3. 后端接口与鉴权实现骨架和第一道门槛后台管理类的系统登录鉴权是第一道门槛。用户信息管理系统里有多个接口如果不做鉴权任何人都可以绕过登录页直接调用接口这在答辩时是个大槽点。我采用的方案是Session 拦截器没有引入JWT、Redis这些偏分布式的东西。原因很简单课程设计是单体应用Session天然够用而且实现起来非常直观代码量少逻辑也容易讲清楚。整套鉴权的思路是这样的用户提交用户名密码后端校验通过后在Session里存入用户ID和角色信息写一个LoginInterceptor拦截器注册到Spring MVC的拦截器链中凡是匹配/api/**的请求都先检查Session里有没有用户信息没有就直接返回401状态码并跳转到登录页。这里有一个细节——放行策略/api/login这个登录接口肯定不能拦但其他接口全部要拦。拦截器里放行规则的配置顺序其实很关键addPathPatterns写要拦截的路由excludePathPatterns写要放行的路由别把顺序搞反了否则会出现“所有接口都进不去”的诡异问题。3.1 登录与Token鉴权的实现要点登录接口的核心代码逻辑看起来简单但要做得完整有几个容易被忽略的检查点。首先是用户不存在和密码错误的区分——业务上要尽量减少“用户是否存在”的泄露以免被人遍历用户名但在课设项目里我选择了直接提示“用户名或密码错误”这样更安全。其次登录成功后要把用户信息放进Session我存的是用户ID和用户名避免在Session里塞一个完整的用户对象后续修改用户信息时Session里的数据过期反而会出问题。密码校验方面我给用户密码做了BCrypt加密存储登录时用BCryptPasswordEncoder的matches方法校验。这里顺带提一个我踩过的坑如果你是从旧代码里复制的SQL脚本里面可能已经存了明文密码BCrypt校验时就会一直失败。开发阶段随便怎么改都行但为了让自己记牢我写了个小工具类专门把明文密码批量转换成BCrypt哈希格式然后再导入数据库。还有一个容易被忽略的点退出登录时要让Session失效不要只是跳回登录页。session.invalidate()这一行代码能避免用户按浏览器后退键时看到登录前的页面缓存。3.2 用户增删改查接口的参数校验细节增删改查是整个系统的核心功能接口实现基本就是Controller Service Mapper三层。但写接口的过程中参数校验是最能看出工程素养的地方。新增用户时用户名不能为空、手机号和邮箱格式要合法、用户名不能重复修改用户时用户名如果不变则跳过重复校验删除用户时要判断用户是否存在还要关联判断该用户是否已被分配订单等业务数据如果项目有其他业务表的话。我用的校验方式是JSR 303规范的Valid注解加NotBlank、Email、Pattern等约束注解配合全局异常处理器统一返回校验错误信息。例如手机号的正则表达式我直接写了一个常用的校验规则。框架会帮你完成校验你再也不用在Controller里写一堆if-else判断了代码清爽得多。NotBlank(message 用户名不能为空) Pattern(regexp ^[a-zA-Z0-9_]{3,20}$, message 用户名格式不正确) private String username; NotBlank(message 手机号不能为空) Pattern(regexp ^1[3-9]\\d{9}$, message 手机号格式不正确) private String phone;这里有一个新手很容易犯的错把前端校验当成了后端校验的全部。前端用JS拦截了非法输入后端接口却没做校验导致用Postman直接调接口就能写入脏数据。前端校验是为了体验后端校验才是真正的防线。我这次把两套校验都做了答辩时老师用Postman测试我的接口发现传了非法手机号会被拦下来当场给了肯定。删除接口我也做了优化——支持单个删除和批量删除。批量删除接收一个ID数组生成IN条件进行逻辑删除。这里有个经验逻辑删除场景下的批量删除SQL要写成UPDATE ... WHERE id IN (...) AND deleted 0否则可能把已经删除的数据再“删”一遍虽然不影响业务但这种细节经不起老师追问。4. 前端页面与交互没有框架也能做出不错的UI前端这部分我选择用Thymeleaf做服务端渲染配合Bootstrap和原生JavaScript。这个组合的开发效率可能比不上Vue Element UI这种前后端分离方案但课程设计答辩更看重“你是否理解Web请求的完整链路”。服务端渲染时后端返回一个渲染好的HTML页面你天然就把Model和View的关系讲清楚了而前后端分离的话经常出现“前端代码不是自己写的”之类的质疑。页面结构上我规划了三个主要页面登录页、主页面包含左侧菜单和内容区、用户管理页包含搜索区、表格区、分页区、新增/编辑弹窗。用户名和密码输入框加了自动聚焦功能回车可以触发登录主页面顶部是一个简单的导航栏展示当前登录用户和退出按钮用户管理页的表格每一行都有操作按钮——编辑、删除、打印该用户档案。4.1 登录页与列表页的页面架构登录页面我没有花太多心思做炫酷的动效而是把重点放在了“完整闭环”上用户登录成功后跳转到主页未登录直接访问主页会被拦截器重定向到登录页登录失败时页面显示错误提示信息。这里用Thymeleaf的th:if条件判断配合th:text输出错误消息实现很简单但演示起来很流畅。列表页是另一个重头戏功能区要清晰信息层级要分明。搜索区放在最上面支持按用户名、姓名、手机号、部门、状态这些条件组合查询中间是操作按钮区有“新增用户”“批量删除”“打印选中档案”三个按钮然后是表格表格的列定义了选择框、ID、用户名、姓名、部门、手机号、邮箱、状态、创建时间、操作表格下面的分页条默认每页10条。每个搜索条件都要和后端的查询参数一一对应前端把表单序列化后拼成查询字符串点击搜索后重新加载表格。这里有一个特别值得注意的点分页必须由后端来做。前端只负责传pageNum和pageSize两个参数后端用PageHelper或者MyBatis-Plus的分页插件查询返回总记录数和当前页数据列表。如果课设里用假分页数据量几百条的时候看不出来问题答辩老师一旦往数据库里灌几千条测试数据页面立刻卡成PPT这种低级失误特别影响印象分。4.2 表单校验、分页搜索与状态回显新增和编辑用户我用的同一个弹窗表单通过一个隐藏的id字段区分是“新增”还是“编辑”。打开弹窗时如果是编辑操作需要从后端查出用户数据回显到表单如果是新增操作则把表单清空、id置空。这种设计减少了很多重复的HTML代码也让你理解“一个表单两种模式”的开发套路。前端校验我用了jquery-validation插件配置规则时手机号的正则和后端保持一致确保前后端校验的一致性。保存的时候用$.ajax提交表单数据成功之后关闭弹窗并刷新表格。这里有一个交互细节我花了不少心思操作成功后页面顶部要弹一个轻量的提示条提醒“保存成功”或“删除成功”。如果没有这个反馈用户点了半天按钮以为没生效再点一次结果重复提交了。状态列的回显也要处理好。数据库里存的status是0和1两个数字但页面上不能直接显示0和1要显示“启用”和“禁用”并且配上不同颜色的徽标。我的做法是前端JS处理用一个映射函数把数字转成对应的HTML标签。这个逻辑放在前端还是后端都可以但建议放在前端——因为用Thymeleaf渲染的时候后端确实可以把状态文本直接拼到页面上但如果要用于JQuery动态刷新表格前端统一处理状态映射会更灵活。另外分页搜索还有一个极易踩坑的地方点击搜索后页码要重置为1。否则你在第5页搜索结果还是停留在第5页而符合条件的记录可能总共只有1页用户猛然一看以为搜索结果为空体验非常差。5. Lodop打印控件集成把用户信息一键打印成档案当初选Lodop其实是看了很多技术博客之后才决定的。Web应用里做打印方案有好几种浏览器自带的window.print()只能打印整个页面样式控制能力弱还经常把按钮、菜单栏一股脑打印出来用CSS写专门的打印样式遇到复杂表格和数据分页时根本控制不住生成PDF再打印虽然可行但要在服务端装插件增加系统复杂度。Lodop是这套方案里成本最低、做出来效果最专业的——它是一个ActiveX插件也有兼容Chrome/Firefox的新版CLodop通过JavaScript调用本地的打印服务可以实现精确的坐标定位、套打、批量打印。课程设计里用了它“打印这块”基本就没什么可挑的了。5.1 为什么选Lodop作为打印方案Lodop的全称是“云打印控件”在Web系统中它干的事情简单说就是把网页前端的数据按照你设计好的版式通过网络发送给本地打印服务由它驱动打印机工作。它最大的两个优势是精确和稳定你可以用毫米为单位控制每个文本、图片、表格在纸张上打印的位置批量打印、循环打印、条码二维码打印这些场景它都支持。我在这个系统里用Lodop做了两个功能单条用户档案打印、批量用户档案打印。单条打印是从列表页点击某行的“打印”按钮弹出一个预览窗口显示该用户基本信息批量打印是先勾选表格中的多条记录点击“打印选中档案”后端一次查出所有用户数据前端循环调用Lodop的接口逐条添加打印项。这里有一个技术细节Lodop控件的调用分为两步——页面引入LodopFuncs.js然后通过getLodop()函数拿到打印对象实例。由于新版浏览器对ActiveX控件的限制常规做法是在页面加载时检测控件是否安装、是否可用如果缺失就提示用户下载安装。5.2 Lodop集成步骤与标签打印实战Lodop的集成过程刚上手时会觉得有点懵因为它的API风格和普通前端库差别很大全是ADD_PRINT_TEXT、SET_PRINT_PAGESIZE这类大写函数。但其实核心步骤非常固定我梳理成一个可以直接套用的模板第一步官网下载Lodop安装包安装到本机。安装完成后系统里会多出一个名为“CLodop”的服务进程。对开发环境和演示机器这一步必须在本地执行。我建议写进项目的README文档中避免答辩换了一台电脑后打印功能瘫痪。第二步在resources/static/js目录下放置LodopFuncs.js页面里用script标签引入。LodopFuncs.js会判断浏览器类型自动决定使用Lodop还是CLodop的调用方式这一段是官方提供好的一般不用修改。第三步写一个打印用户档案的函数核心代码如下function printUserInfo(user) { var LODOP getLodop(); if (!LODOP) { alert(打印控件未安装请先安装Lodop打印控件); return; } LODOP.PRINT_INIT(用户信息档案打印); LODOP.SET_PRINT_PAGESIZE(1, 1000, 1400, 用户档案); LODOP.ADD_PRINT_TEXT(20, 20, 200, 22, 用户信息档案); LODOP.ADD_PRINT_TEXT(60, 20, 120, 22, 用户名 user.username); LODOP.ADD_PRINT_TEXT(90, 20, 120, 22, 姓名 user.realName); LODOP.ADD_PRINT_TEXT(120, 20, 220, 22, 手机号 user.phone); LODOP.ADD_PRINT_TEXT(150, 20, 220, 22, 邮箱 user.email); LODOP.PREVIEW(); }这段代码干的事情在注释里看起来显而易见但有一个点必须强调PRINT_INIT的字符串参数不能为空否则控件可能拒绝初始化SET_PRINT_PAGESIZE的宽高单位是0.1mm所以1000×1400表示100mm×140mm的纸张。这个单位容易坑人如果把它理解成像素打印预览就会错乱。批量打印的思路类似只要在PRINT_INIT和PRINT之间循环添加打印项即可但要注意每一条用户记录之间要留出足够的垂直间距或者用NEWPAGE换页。我采取的做法是每条记录占一个页面小节用ADD_PRINT_TEXT的纵坐标递增来分页Lodop控件在超出当前纸张高度时会自动分页不用手动换页。打印完调用LODOP.PRINT()会直接发往打印机而PREVIEW()则是先弹出预览窗口。正式演示时我推荐用PREVIEW先预览确认内容没问题再打印避免直接打印出错后纸张浪费。6. 常见问题与排查技巧实录用户信息管理系统整体开发周期不到两周但中间的坑一点都不少。这些问题有的是开发过程中的经典错误有的是Lodop集成特有的古怪现象。我把它们整理成了一张排查速查表并在后面详细解释几个典型的排查思路希望能帮大家少走弯路。问题现象可能原因解决办法数据库中文乱码数据库/表/连接串字符集不一致统一使用utf8mb4JDBC URL加characterEncodingUTF-8密码加密后登录失败旧数据是明文密码写批量脚本把明文转成BCrypt哈希再导入删除用户后列表还显示逻辑删除字段没有生效检查实体类是否加了TableLogic注解分页查询总条数为0前端传参起始页码从0开始统一约定前端页码从1开始PageHelper默认也从1开始Lodop预览显示空白控件未安装或服务未启动检查CLodop服务状态重新安装控件Lodop打印中文乱码字体设置不正确添加文本时指定中文字体如“宋体”搜索后分页页码错乱搜索后页码未重置为1点击搜索时强制设置pageNum 16.1 高频踩坑中文乱码、日期格式、重复提交中文乱码算是Web开发的“老大难”问题。用户信息管理系统里用户名、姓名、部门这些字段全是中文乱码一旦出现几乎全盘崩溃。排查思路按层次走先看数据库连接串jdbc:mysql://localhost:3306/db_name?useUnicodetruecharacterEncodingUTF-8这句绝不能少再看MySQL服务端的配置文件看character-set-server是否等于utf8mb4最后看表结构CHARSETutf8mb4和上面SQL保持一致。如果这三层都统一了还乱码那就是前端页面本身的编码问题检查HTML里是否声明了meta charsetUTF-8。日期格式的问题典型表现是列表页显示的时间是2023-03-14T10:30:00这种带字母T的格式非常不美观。根本原因是Jackson在序列化Java的LocalDateTime类型时默认输出ISO格式。解决办法是全局配置日期格式在application.yml里配置spring.jackson.date-format或者在LocalDateTime字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。这里要注意JsonFormat对LocalDateTime生效但对java.util.Date不一定生效两个都要确认。重复提交是非常容易被忽视又极其影响体验的问题网络慢的时候用户点了几次“保存”按钮数据库里出现好几条一模一样的记录。我的解决方案前后端双管齐下前端在保存按钮点击后立即置灰setTimeout恢复后端在保存接口里做一次数据库唯一性校验如果用户名相同且未删除直接返回“用户名已存在”的错误。其实这里还可以用Redis做分布式锁项目规模不需要我就没有引入但这在扩展思路上是可以和老师聊的加分点。6.2 打印相关的问题排查Lodop控件的坑主要集中在“控件装不上”“打印乱码”“坐标不准”这三个问题上。第一控件装不上。新版的Chrome、Edge对ActiveX插件是直接屏蔽的老版本的Lodop在这类浏览器里根本无法运行。所以一定要用官网最新的Lodop第10版之后的方案它会顺带安装一个本地服务“CLodop”由网页脚本通过HTTP请求与本地服务通信从而绕开浏览器的插件限制。安装完CLodop之后浏览器左下角如果出现一个提示框说明服务已经在运行了。如果打印功能没反应第一件事就是去Windows服务列表里检查CLodop服务是不是启动状态。第二打印乱码。Lodop打印控件默认的字体可能不支持中文所以添加文本时需要显式指定中文字体LODOP.ADD_PRINT_TEXT(20, 20, 200, 30, 用户信息档案)后面再加一个参数设置为宋体。如果不指定打印出来的中文就是一堆???或者方框这和浏览器里的显示完全是两码事浏览器显示正常不代表打印正常。第三坐标不准。Lodop的坐标系原点是纸张左上角单位是0.1毫米。很多人一开始会把坐标单位当成像素结果打印出来的内容要么挤成一团要么跑到纸张外面去。我的经验是先量好纸张的宽度和高度用毫米换算成0.1毫米的单位值再利用PREVIEW模式反复调整坐标最终找到合适的坐标值存档。开发阶段多花几分钟做预览调试打印阶段才能少浪费几十张纸。另外提醒一个容易被忽略的细节Lodop较新版本有免费版和收费版的区别免费版在打印时会在右上角打一个水印。课设演示可以用免费版但如果是要放到正式业务系统里建议评估一下是否购买授权或者换成开源的打印方案。这个点写进课程设计报告里也能体现你做过商业与技术选型的综合考量。7. 一点个人体会整套系统从选题、设计、编码到测试大约用了两周多的课余时间。说实话用户信息管理系统本身的难度不算高但它像一块标准的练功靶让你把Web开发中每一个基础环节都过了一遍数据库设计、后端接口、前端页面、鉴权拦截、日志记录、打印输出。做完之后最大的感受是课程设计的核心不是“做出来”而是“能讲明白”。你在答辩时要能清清楚楚地说出每个表为什么这么建、每个接口为什么做校验、每个按钮点击后浏览器和后端分别发生了什么。这套系统里的每一个细节Lodop打印、逻辑删除、操作日志、参数校验都是可以展开讲的“答辩弹药”。如果你也正在做类似的Web课设项目我的建议是先把数据库表建好再把最核心的增删改查跑通然后挑一个自己感兴趣的方向做深——打印、权限、日志都行千万别贪多。把一件小事情做透比做十个半成品页面有价值得多。这个项目里积累的经验等你以后做真实的Web系统时就会发现全是底子。本文还有配套的精品资源点击获取