1. 项目概述与技术选型思路1.1 这个项目到底在解决什么问题小说阅读网站这一类项目在我接触过的毕业设计里出现频率相当高。它看似是个常规的CRUD项目但真正动手做过的人才知道里面涉及的知识点远比想象中复杂。一个完整的小说阅读网站至少要涵盖用户注册登录、小说分类浏览、章节列表展示、阅读页面、书架管理、阅读记录、后台内容管理这些模块而且每个模块之间还有数据关联。如果只是简单地把增删改查堆上去答辩的时候老师一问数据表设计和业务逻辑很容易漏馅。用ThinkPHP5来做这个项目是一个比较稳妥的选择。它的文档完善、社区活跃、上手门槛低而且MVC分层结构非常清晰用来做毕业设计的项目骨架再合适不过。ThinkPHP5的ORM操作、模板引擎、路由配置、验证器这些功能正好覆盖了小说阅读网站开发过程中需要用到的核心技术点做完这个项目相当于把框架的核心用法都过了一遍。1.2 为什么选ThinkPHP5而不是其他框架我在实际指导过程中经常被问到这个问题。很多同学会纠结是选ThinkPHP5还是Laravel或者干脆用Spring Boot。我的看法是毕业设计的核心目标不是炫技而是把软件开发的基本流程吃透把业务逻辑理清楚把代码规范做到位。ThinkPHP5在这三个方面都能给你足够的支撑。对比一下其他方案Laravel功能强大但学习曲线陡对新手不太友好Spring Boot适合Java方向的同学但PHP项目用不上原生PHP写起来虽然能锻炼底层能力但开发效率低后期维护也麻烦。ThinkPHP5恰好处在中间位置——它的语法风格接近原生PHP理解起来没有障碍同时又帮你封装好了数据库操作、请求处理、模板渲染这些基础工作让你把精力集中在业务流程本身的实现上。还有一个很实际的原因ThinkPHP5的中文文档和社区资源非常丰富。做毕业设计的过程中一定会遇到各种报错搜索解决方案的时候中文资料多不多直接决定了你排查问题的效率。这一点在答辩前那几天尤其重要。1.3 小说阅读网站的核心功能定位在动手写代码之前一定要先想清楚你的小说阅读网站到底要做什么给谁用用到什么程度。我见过不少同学一上来就开写结果做到一半发现功能越加越多数据库改来改去最后自己都被绕晕了。正确的做法是先把功能边界划清楚。一个标准的小说阅读网站前台用户端应该包含这些内容用户注册登录手机号或邮箱 密码需要做密码加密小说分类浏览按分类、按状态、按更新时间筛选小说详情页封面、简介、作者、最新章节信息章节目录与阅读页上一章/下一章切换、章节内容展示书架管理加入书架、移除书架、查看阅读进度搜索功能按小说名、作者名模糊搜索后台管理端则需要这些模块管理员登录小说管理添加、编辑、下架、删除章节管理按小说维度管理章节内容分类管理增删改查小说分类用户管理查看用户列表、禁用账号如果时间充裕还可以加一些加分项比如阅读历史、评论功能、阅读量统计、推荐位管理。但核心功能必须先保证稳定可靠再去考虑锦上添花的事。2. 核心细节解析与实操要点2.1 数据库设计的几个关键决策数据库设计是整个项目的根基表结构设计得好不好直接决定了后面写业务代码是顺畅还是拧巴。小说阅读网站的数据库表其实不算复杂但有几个设计细节需要特别注意。首先是小说表和章节表的关系。小说和章节是一对多的关系这个大家都能想到。但章节表怎么存储章节内容不同人有不同做法。我建议用TEXT类型直接存正文不要拆分成多个字段。一章节的正文通常在几千到几万字之间TEXT类型最大支持65KB完全够用。如果你用MEDIUMTEXT也没问题但没必要。拆分存储只会给自己找麻烦。第二是章节排序字段。章节目录的展示顺序必须稳定不能依赖插入时间的排序。一定要设计一个单独的排序字段sort_order章节添加的时候自动取当前小说下最大的sort_order加1。这样即使你插入章节时时间戳一样顺序也不会乱。第三是阅读记录的设计。我建议单独建一张reading_record表记录用户ID、小说ID、最后阅读的章节ID、阅读时间。每次用户点击章节阅读的时候就更新这条记录。这样用户在书架里点开一本书可以直接跳到最后阅读的章节这个交互体验很自然。下面是核心表结构的设计参考-- 小说表 CREATE TABLE novel ( id int(11) NOT NULL AUTO_INCREMENT, category_id int(11) NOT NULL COMMENT 所属分类ID, title varchar(100) NOT NULL COMMENT 小说名称, author varchar(50) NOT NULL COMMENT 作者, cover varchar(255) DEFAULT NULL COMMENT 封面图URL, description text COMMENT 简介, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 状态1连载中 2已完结, click_count int(11) NOT NULL DEFAULT 0 COMMENT 点击量, is_show tinyint(1) NOT NULL DEFAULT 1 COMMENT 是否上架1是 0否, create_time int(11) NOT NULL COMMENT 创建时间, update_time int(11) NOT NULL COMMENT 更新时间, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 章节表 CREATE TABLE novel_chapter ( id int(11) NOT NULL AUTO_INCREMENT, novel_id int(11) NOT NULL COMMENT 所属小说ID, title varchar(200) NOT NULL COMMENT 章节标题, content text NOT NULL COMMENT 章节正文, sort_order int(11) NOT NULL DEFAULT 0 COMMENT 排序值, create_time int(11) NOT NULL COMMENT 创建时间, PRIMARY KEY (id), KEY idx_novel_sort (novel_id, sort_order) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有个细节所有时间字段我都建议用int类型存时间戳而不是用datetime类型。这样做的好处是前后端交互时统一用时间戳格式化交给模板层去处理避免时区问题和字符串比较的麻烦。数据库表设计一定要用utf8mb4字符集这个不能妥协。小说内容里不可避免会有些特殊字符比如Emoji表情utf8mb4才能完整支持。2.2 前台路由规划与URL美化ThinkPHP5的路由功能很强大用好了不仅URL好看对SEO也友好。小说阅读网站的URL结构最适合做成伪静态的形式一方面看起来专业另一方面答辩的时候能多一个可以讲的亮点。我建议配置 RESTful 风格的路由规则/novel/ 显示小说详情页/novel/ /chapter/chapter_id 显示具体章节内容/category/ 显示分类列表页/search?keywordxxx 搜索页在ThinkPHP5里配置这些路由非常简单在application/route.php里定义即可novel/:id index/novel/detail, novel/:id/chapter/:chapter_id index/novel/readChapter, category/:id index/category/index,为什么要特意配置路由而不是直接用默认的模块/控制器/方法这种URL结构除了好看之外还有一个很实际的考虑。你的项目以后如果要迁移到其他框架或者做接口化改造清晰的路由定义能让你省大量的事。而且用语义化的URL结构在答辩演示的时候也更有说服力——老师看到地址栏里是这种干净的URL第一印象就不同。2.3 阅读进度的核心业务逻辑阅读进度功能是整个网站交互里最体现细节的地方也是很多同学容易做漏的地方。它涉及的不只是记录一个章节ID那么简单还需要考虑用户行为触发的时机和数据一致性的问题。我的实现思路是这样的用户打开某个章节页面时先判断当前是否登录。如果未登录不记录阅读进度引导用户登录后使用书架功能。如果已登录则查询reading_record表里有没有这本书的记录有就更新章节ID和时间没有就插入一条新记录。这里有一个性能上的考虑。每次阅读都写数据库会带来不必要的压力。实际开发中更合理的做法是用户在页面停留一定时间比如10秒后前端发起一个AJAX请求上报阅读进度或者只在用户点击上一章/下一章时同步更新进度。我推荐后者因为点击上一章/下一章是明确的切换行为这时候更新记录在逻辑上最合理实现也简单——在跳转链接的控制器方法里顺手把进度更新了。书架页展示的时候需要从reading_record表和novel表做关联查询读出每本书最后阅读的章节标题和阅读时间。这里要注意关联查询的效率用ThinkPHP5的模型关联就能优雅实现不需要手动写复杂的JOIN语句。2.4 后台内容管理的高效方案后台管理是整个项目的工作量大头也是最容易被低估的部分。很多同学认为后台就是简单的CRUD结果做着做着发现表单验证、图片上传、列表筛选、分页排序这些功能一个都少不了。后台我建议用单独的后台模块Admin来组织代码和前台模块完全分离。ThinkPHP5的模块化设计在这里非常有优势你只需要在application目录下分别建index前台和admin后台两个模块目录各自维护自己的控制器、模型和视图。小说管理的核心操作是添加/编辑小说时需要同时处理封面图片上传和信息入库。封面上传建议用ThinkPHP5自带的文件上传功能限制图片格式和大小生成缩略图文件名用时间戳加随机串的方式防止重复。入库时存相对路径模板渲染时加上域名前缀即可。章节管理这块有个提升效率的小技巧批量添加章节内容。小说网站的管理员经常需要把一段完整的文本按章节切分导入如果让管理员一章一章地手动录入体验太差。可以做一个文本分章功能——后台提供一个多行文本域粘贴整本小说的文本按特定的分隔符比如第X章这样的正则自动拆分成章节数组一次性批量入库。这个功能做完整个后台的使用体验会提升一个档次。3. 实操过程与核心环节实现3.1 环境搭建与项目初始化项目开发的第一步是搭建环境。我推荐直接使用集成环境Windows下用PHPStudymacOS下用MAMP或Docker把PHP版本固定在7.1到7.3之间。这里有个注意点ThinkPHP5.0系列在PHP 7.4以上运行会有些兼容性警告如果的集成环境默认给了PHP 8.x最好手动切换到7.x版本否则运行的时候可能遇到一些莫名其妙的报错。创建ThinkPHP5项目的命令是通过composer拉取composer create-project topthink/think5.0.* tp5-novel --prefer-dist项目创建完成后马上配置虚拟域名。以PHPStudy为例在网站列表里新建一个站点域名填www.novel.test网站目录指定到项目的public目录。这一步很关键一定要指向public目录因为ThinkPHP5的入口文件在public/index.php只有这样才能保证URL正确解析。然后打开application/database.php配置数据库连接信息return [ type mysql, hostname 127.0.0.1, database novel_db, username root, password root, hostport 3306, charset utf8mb4, prefix tp_, ];这里建议给数据库表加上统一前缀tp_这样以后一个数据库里就算有其他项目的表也不会冲突这是一个好习惯。3.2 前台用户端的核心代码实现用户注册登录模块没有太多复杂的逻辑但有两点想特别强调。第一密码必须使用ThinkPHP5自带的加密函数password_hash或ThinkPHP的md5加盐方式绝对不要明文存库。使用PHP原生的password_hash其实是更好的选择它自动加盐且每次生成的哈希值不同安全性远高于简单的md5。第二登录状态用Session保持用户在登录后把用户ID存进Session后续所有需要身份验证的操作都从Session里取用户信息。小说列表和详情页的核心是数据查询。这里我建议用模型层来写数据逻辑控制器只负责接收参数和返回结果保持代码清晰。小说列表页需要展示分类筛选、排序方式最新发布、点击最高和分页功能ThinkPHP5的paginate方法使用起来还是很顺手的。而小说详情页则除了基本信息外还需要统计章节总数、最新章节更新时间、点击量。点击量的更新逻辑要注意应该在用户打开详情页时对click_count字段自增1但不要用先查询再更新的方式直接Db::name(novel)-where(id, $id)-setInc(click_count);这样一步到位避免了并发场景下的数据误差也精简了代码量。章节阅读页是重点。除了展示章节正文外还要有上一章、下一章的切换按钮一个好的实现方式是按当前章节的sort_order查找相邻章节。上一章的查询条件就是同一小说ID、sort_order小于当前值的最大值下一章则相反取大于当前值的最小值。用ThinkPHP5的ORM描述出来非常清晰$prev NovelChapter::where(novel_id, $novelId) -where(sort_order, , $currentSort) -order(sort_order desc) -find(); $next NovelChapter::where(novel_id, $novelId) -where(sort_order, , $currentSort) -order(sort_order asc) -find();这段代码就是阅读页切换功能的全部核心逻辑简洁、没有坑效率也不错。3.3 后台管理端的权限与验证后台的登录认证和前台要做区分不能直接复用前台的Session。我的做法是后台登录成功后单独设置admin_session这个Session标记后台模块的每个控制器都继承一个BaseController在初始化方法里统一做登录状态检查class BaseController extends Controller { public function _initialize() { if (!session(admin_id)) { $this-error(请先登录, Login/index); } } }这样写的好处是所有后台控制器只需要继承BaseController就自动带有登录拦截功能不用每个控制器里重复写验证代码。同时新增的功能控制器也天然继承了这套逻辑做到了一劳永逸。后台的列表页尽量都用分页和筛选条件。比如小说管理列表要有按分类筛选、按上架状态筛选、按关键词搜索列表展示小说名、作者、分类、状态、点击量、更新时间并放编辑、删除按钮。这些功能写起来不难但要注意操作顺序——删除小说前务必要同时删除这本书的所有章节。这个操作在事务里执行才能保证数据一致性任何一步失败就整体回滚Db::startTrans(); try { Db::name(novel_chapter)-where(novel_id, $id)-delete(); Db::name(novel)-where(id, $id)-delete(); Db::commit(); } catch (\Exception $e) { Db::rollback(); }3.4 书架功能的完整实现流程书架功能的业务逻辑相对独立很适合作为核心功能重点实现。数据表结构是用户ID 小说ID 加入时间 最后阅读章节ID。用户加入书架时先判断是否已加入避免重复添加——用一个唯一索引或者查询判断都可以。书架列表页需要展示每本小说的封面、名称、最新章节标题、最后阅读时间。这个查询要关联novel表、novel_chapter表取每本书最新章节和最后阅读章节。写SQL的时候关联查询加子查询的方式最直接但也可以用ThinkPHP5的模型关联预载入。为了性能和代码可读性的平衡我建议直接写查询构造器的JOIN语句Db::name(bookshelf) -alias(b) -join(tp_novel n, b.novel_id n.id) -where(b.user_id, $userId) -field(b.*, n.title, n.cover, n.author) -order(b.update_time desc) -paginate(10);阅读进度信息从reading_record表取如果关联查询比较麻烦可以在循环里用novelId和userId再查一次。这个场景下N1查询问题其实不严重因为每本书只需要一条记录而且书架一般不会展示超过几十本。代码的可读性远比细微的性能优化重要。4. 常见问题与排查技巧实录4.1 模板渲染的坑与解决办法ThinkPHP5的模板引擎在开发效率上确实有帮助但使用过程中也有些细节容易踩坑。最常见的莫过于模板继承和引入的路径问题。很多人会在include公共头部或者footer时用相对路径或者绝对路径结果换一个目录层级就找不到文件了。我个人的建议是模板布局用ThinkPHP5自带的layout功能在视图中设置layout模板页面模板只写主体内容。这样代码的复用率很高也避免每个页面都去include公共文件。另一个坑是模板里的URL生成。之前在template里直接写死链接后来改了路由规则页面上的链接全部失效。正确的姿势是使用Url类或者模板的url函数来动态生成链接a href{:url(novel/detail, [id $novel.id])}这样做的好处是代码中不固化URL结构路由怎么改都不影响页面。这一习惯在你以后做任何PHP框架项目时都用得上。4.2 数据库乱码和数据不一致问题小说网站的数据有大量中文内容如果数据库和代码的字符集配置不一致很容易出现乱码。我的建议是在三个方面统一设置数据库表的字符集用utf8mb4ThinkPHP5的数据库配置里charset设为utf8mb4HTML页面的meta标签里charsetUTF-8。三处一致基本就不会有乱码问题。之前遇到过一个问题导入小说内容到数据库时页面显示正常但后台编辑时看到的内容是断行的回车符全部丢失了。排查下来发现是textarea标签的问题——换行符需要在输出时做nl2br转换。解决方式是编辑时输出原样内容展示时使用nl2br()函数转换或者把编辑器的值用JavaScript的escape函数做特殊处理。后来我把章节编辑改成了纯textarea 前端预览模式问题就彻底消失了。4.3 分页样式和页面跳转问题ThinkPHP5的分页类非常好用但默认的分页样式比较简陋直接套用到前端页面上会显得很难看。解决方式有两种一种是自己写分页HTML结构渲染时替换默认的输出另一种是使用自定义分页样式模板。我推荐后者在paginate方法中指定分页模板路径$list Db::name(novel)-paginate(10, false, [ path url(category/index, [id $categoryId]) ]);这里有一个很关键的细节如果列表页有额外的查询参数比如分类ID不能只分页而忘了把参数传到下一页链接中去否则用户点击第二页时筛选条件就消失了。如果你用了带参数的路由只要在配置数组里加上path这一项就能完美解决。我还想强调一个容易被忽视的问题分页的page参数在URL里是问号参数?page2如果你配置了路由规则是强制伪静态的可能会导致分页链接的URL格式变得不那么好看。实际测试下来用问号参数并不会影响功能所以不必过度纠结URL的美观问题。4.4 性能优化建议与常见踩坑小说阅读网站的并发压力不算特别大但也有几个场景需要关注性能问题。第一个是章节列表页的查询。一本长篇小说可能有上千个章节如果每次访问详情页都把这上千条记录全部查出来数据库压力还是不小的。但用ThinkPHP5的时候也没必要特意做复杂优化我的做法是按章节ID倒序只取最近更新的100条通过查询字段限制$chapters NovelChapter::where(novel_id, $novelId) -order(sort_order desc) -limit(100) -select();这样既能满足绝大多数用户查看最新章节的需求又不至于一次加载太多数据。完整的目录页单独做一个全量列表URL与详情页的章节列表区分开来即可。第二个是图片资源的问题。小说封面如果直接上传原图不做压缩页面加载速度会受影响。最简单的做法是在模板里使用缩略图函数或者在上传时用ThinkPHP5的图像处理库自动生成一张固定尺寸的缩略图。我在项目中推荐后者因为储存在磁盘上更可控$image \think\Image::open($file-getInfo(tmp_name)); $image-thumb(300, 400, \think\Image::THUMB_CENTER)-save($savePath);给封面统一生成300×400的缩略图列表页和详情页都用这张图加载速度和页面视觉整齐度都大幅提升。这个方法我在多个项目中反复验证过很稳。第三个常见的坑是Session失效导致用户登录后马上被踢回登录页。这个问题的主要原因还是系统时间不准确和Session存储路径没有写权限。排查时可以先检查php.ini的session.save_path是否指向一个可写目录再用浏览器开发者工具确认Cookie的过期时间设置是否正常。只要这两处没问题Session失效问题基本就解决了。5. 测试要点与项目亮点提炼5.1 功能测试的优先级划分做完功能后一定要给自己列一个测试清单按照业务优先级逐项验证。小说阅读网站的核心链路是注册登录 → 浏览分类 → 查看详情 → 阅读章节 → 加入书架 → 后台发布新章节 → 前台看到更新。这条主链路必须百分之百通畅。我的建议是把测试用例按优先级分成三层来执行第一层是核心链路注册登录、小说浏览、章节阅读、书架操作、后台小说发布。这层有任何问题都必须修完才能算项目完成。第二层是数据完整性更新章节后详情页的最新章节号是否正确、删除小说后是否有残留脏数据、用户阅读记录是否实时更新。第三层是异常场景未登录用户点击加入书架时的跳转、访问不存在的章节ID时的错误提示、后台无权限访问时的拦截。在测试过程中我习惯使用浏览器无痕窗口来模拟未登录状态避免缓存带来的判断干扰这比直接开着登录窗口乱点要可靠得多。5.2 答辩演示时候的加分设计一个小说阅读网站要拿到高分光有功能还不够还得有几个能突出设计水平的点。我总结出三个性价比很高的加分项能够在答辩演示时引起老师的兴趣第一个是缓存层设计。小说内容的访问量远高于更新频率针对章节详情页做缓存能显著提升性能。ThinkPHP5内置了多种缓存驱动最简单的是文件缓存。把章节内容存到缓存里下次访问直接取缓存后台更新章节时删除对应缓存这样既有效率提升又能作为亮点讲清楚负载优化思路。第二个是搜索功能的优化。如果你的搜索是直接用LIKE %关键字%虽然能跑但包含的优化思路很浅。至少可以把搜索关键词做分词处理支持按小说名和作者分别搜索还可以加一个搜索热度排行。用ThinkPHP5实现并不复杂但在答辩中可以讲出搜索引擎基础原理的扩展话题。第三个是后台的图表统计。如果时间允许统计小说点击量走势用ECharts画一张折线图放在后台首页会让整体完成度看起来比同学高很多。实现方法就是用SQL按日期分组统计阅读日志表如果前期设计了该表输出JSON给前端图表渲染。这个功能强烈建议做视觉冲击和加分效果都很直接。5.3 项目经验如何沉淀到简历上做完项目之后还有一个容易被忽略的重要动作就是把你从项目中锻炼到的能力整理出来沉淀到简历和作品集里。很多同学写项目经验的时候就写一行字“开发了一个小说阅读网站”这种描述几乎等于没写。面试官想知道的不是你做了什么而是你怎么做的、用了什么方法、遇到了什么问题、怎么解决的。我的建议是按照项目描述、技术栈、个人职责与难点突破、项目成果这几块组织你的项目说明。比如技术在描述里不只是写ThinkPHP5还可以写MySQL数据库设计与优化、Redis缓存策略、伪静态路由配置、基于角色权限的后台控制这些是面试官能很快捕获到有效信息的关键词。在个人职责与难点突破里可以写自己如何设计阅读进度与书架的数据关联、如何用事务保证删除小说时章节数据的清理一致性。这样措辞的实质是把你做毕业设计的思考过程用专业的表达封装起来转化成面试中的谈资。做完这个项目你不只是会写一个网站你背后的数据库设计能力、调试能力、业务抽象能力都得到了真实的提升这些才是最值得呈现的部分。6. 项目扩展与后续优化方向6.1 从网站到小程序的技术迁移思路很多人做完整套Web端小说阅读网站后会想进一步探索延伸方向。把网站改造成微信小程序或者H5移动端是一个自然的进化路径。这一过程的技术思路是后端不需要推翻重写只需要提供符合接口规范的JSON数据接口也就是把现有的控制器改造成接口模式前端改用小程序原生或uni-app去适配页面。改造时优先开放几个核心接口登录接口、小说列表接口、详情接口、章节内容接口、加入书架接口。使用ThinkPHP5时可以通过设置不同的返回格式来快速实现接口支持配置了response的json类型后控制器里正常的return数组就会自动变成JSON返回。Token鉴权可以用JWT方式实现不过对于毕业设计的扩展来说用Session Token的折中方案更简单一些。这类扩展改造做起来相对快速但体现在简历“项目亮点”里就很加分因为有从单端到多端的改造经验充分说明你不只会写Web页面对前后端分离甚至跨端开发也有理解和实践。6.2 数据采集与版权问题的边界小说网站的项目开发过程中很多同学会想去爬其他网站的小说数据来充实自己的库。这里一定要慎重有两个问题需要特别注意。第一是技术问题爬虫涉及反爬机制、IP封禁、动态渲染等复杂情景做起来会耗费大量时间精力性价比很低。第二是版权问题未经授权采集有版权的网络小说用于公开传播在合法性上是存在风险的。自己开发学习用的项目数据可以自己整理、可以公版内容、甚至可以自己写一些测试内容即可。如果你确实需要批量测试数据我的建议是写一个简单的脚本自动生成指定数量的模拟小说信息——标题、作者、简介、章节内容都可以用占位文本拼接。重点是为了测试页面展示和分页逻辑而不是真的要做内容平台。6.3 上线部署时的注意事项项目做完如果想放到线上让同学朋友体验部署环节也有几个容易踩坑的地方。首先是PHP版本问题建议提前确认线上环境是PHP 7.x避免因为PHP版本过高导致ThinkPHP5某些组件报Warning级别的错误。其次是上传目录的权限如果你使用了文件上传功能确保服务器上对应upload目录具备写权限同时注意设置Nginx/Apache禁止PHP脚本在该目录下执行这是安全底线。数据库导入方面本地数据库导出SQL文件后线上导入时注意检查字符集和前缀是否一致。正式环境建议关闭调试模式修改application/config.php中的app_debug为false避免页面报错时暴露代码结构和服务器路径信息。域名和伪静态配置要提前处理好尽量保持和本地开发时相同的URL结构减少线上和本地的行为差异。个人经验总结写到这里回顾这个项目最核心的价值其实不只是做出来一个能跑的小说阅读网站而是通过这个完整的项目把一个Web应用从设计、开发、测试到部署的全流程走通了一遍。我在实际教学和指导过程中看到太多人卡在某个细节上出不来比如路由不生效、分页参数丢失、表单验证不通过、Session失效等等这些问题本身都不难但需要在真实项目中摸索一遍才能根深蒂固。最后再分享一个小技巧也是我踩过几次坑之后形成的习惯任何功能上线哪怕是毕业设计这种规模之前把项目的所有操作流程完整走三遍第一遍按正常路径操作第二遍刻意乱点第三遍用无痕浏览器模拟新用户操作你会发现很多平时注意不到的问题就这样被提前揪出来。这个小习惯帮我省了非常多在答辩现场被老师问住的时间也推荐给你试试。
