简介：面向Java学习者和毕业设计生，这份资源完整呈现基于Java的文本搜索引擎的设计与实现全过程，从爬虫采集、Lucene分词建索引，到MySQL存储和JSP前端展示均有对应代码支撑，可作毕设框架、课程设计或信息检索实战参考。压缩包共60个文件，包含14个Java源码、21个class编译文件、7个jar依赖库，以及JSP页面、CSS样式、数据库配置文件和论文文档、答辩PPT，整体3.97MB，目录按服务端、网页端、爬虫模块等拆分，便于逐层研读。已有198人学习下载。资源既有可运行的服务端与网页端工程，也有毕业设计论文和讲义PPT，详细讲解了爬虫策略、反爬应对、倒排索引构建、查询API调用和SQL优化等关键点，同时通过源码可学习页面解析、链接抓取、自定义分词规则等进阶内容，能帮助读者快速掌握搜索引擎核心机制，并可直接复用到自己的课题或实训项目中。
1. 基于 Java 的文本搜索引擎：能跑通抓取、索引、查询三段链路的毕业设计
看到“基于 java 的文本搜索引擎”这个题目，多数人的第一反应是做一个带搜索框的 CRUD。真正能写进简历的搜索引擎，至少要跑通抓取、索引、查询三段链路。这份毕业设计把 web_spider、searchEngine_server、anysearch、searchEngine_web 四个模块串成完整闭环：java 爬虫采集网页，Lucene 建立索引，MySQL 负责持久化，JSP + Servlet 做结果展示。
它适合正在准备 java 毕业设计的人，也适合想拿一份 java 课程设计案例源码、把信息检索原理讲明白的开发者。包里带着毕业论文和讲义，省去不少自己整理的时间。我拆过很多同类课设，多半只有增删改查，这份至少有四个独立工程可以一次跑完。
下面按启动顺序把每个模块过一遍，顺带说清参数、配置和踩坑点。
2. 工程模块拆解：四个工程的职责、启动顺序与最优先改的配置
2.1 四个模块的职责与一次搜索的完整调用链
在动手改代码前，先把四个工程各自的边界看清楚。web_spider 是 java 爬虫，负责从种子 URL 开始抓取网页，解析出标题和正文后写入 MySQL；searchEngine_server 是索引服务，它不直接面对浏览器，而是把 MySQL 里已经抓好的页面读出来，交给 Lucene 建立倒排索引，并对外提供查询接口；anysearch 是一个命令行查询工具，在不启动 Web 页面的情况下就能验证索引里的数据；searchEngine_web 才是用户看得见的 JSP 前端，用户在搜索框输入关键词，请求发给 Servlet，Servlet 调用 Lucene 查询，再把结果渲染回页面。
一次完整搜索的调用链是这样的：web_spider 先把网页存进数据库，searchEngine_server 从数据库批量读取数据写进 Lucene 索引目录。用户访问 searchEngine_web 时，输入的关键词经 Servlet 转发给 Lucene 的 QueryParser，Lucene 返回文档 ID 和评分，最后结果列表带着标题、链接、摘要回到 JSP。这个链路和工业界搜索引擎的基本模型一致，只是数据规模小很多。拆成四个工程而不是塞进一个 war，最大的好处是抓取和索引可以分别重启、分别写论文章节，答辩时每个模块都能讲清楚，而不是一锅端。
2.2 环境准备与参数配置：JDK、MySQL、Tomcat 的版本边界
老课设最怕环境不对。下面是我复现时用的环境组合，不一定和资源完全一致，但按这个方向排查基本不会翻车：JDK 1.8 最稳，Lucene 老版本在 JDK 11 以上容易因为缺少 javax.xml.bind 直接报 NoClassDefFoundError；MySQL 5.7 或 8.0 都可以，但连接串要显式指定 utf8；Tomcat 7/8 搭配 JDK 1.8 兼容性最好。资源里 lib 目录下的 jar 版本决定了 Lucene 的具体 API，先看一眼再决定用哪种写法。
项目根目录一般会有一个数据库配置文件，常见命名是 db.properties 或 jdbc.properties。我一般会先改这个文件，再启动任何模块：
jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/search_engine?useUnicode=true&characterEncoding=utf8&useSSL=false jdbc.username=root jdbc.password=123456 index.dir=D:/search_engine/index crawl.threads=5 crawl.timeout=10000这段配置里最值得说明的是 jdbc.url。useUnicode 和 characterEncoding=utf8 是中文不乱码的前提，少了任何一个，抓取的中文标题写进 MySQL 后都可能变成问号。useSSL=false 是为了避免高版本 MySQL 驱动在本地连接时弹出 SSL 警告，不影响功能。index.dir 是 Lucene 索引目录，必须提前创建，最好用绝对路径，因为 searchEngine_server 启动时 FSDirectory.open 会直接读这个目录，目录不存在会抛异常。crawl.threads 控制爬虫线程数，默认 5 比较安全，网上抓取不是线程越多越好。
2.3 从零到能搜索的启动顺序
我不太喜欢在 IDE 里点按钮启动整套东西，因为四个模块的依赖会互相干扰。用命令行更能看清 classpath 有没有问题。常见做法是先初始化数据库，再抓取，再建索引，最后部署 Web 页面：
# 1. 初始化表结构 mysql -uroot -p < sql/search_engine.sql # 2. 抓取网页，入库 java -cp web_spider.jar:lib/* com.search.spider.SpiderMain # 3. 读 MySQL 建索引并启动索引服务 java -cp searchEngine_server.jar:lib/* com.search.server.IndexServer # 4. 把 Web 端部署到 Tomcat cp searchEngine_web.war $TOMCAT_HOME/webapps/ $TOMCAT_HOME/bin/startup.sh这段命令的逻辑是：先建表，避免后面所有模块因为缺表而报错；抓取和建索引分开执行，抓取断掉时只需要重跑 web_spider，不用清掉索引目录重来。第 3 步的 IndexServer 是一个常驻进程，它会先遍历一次数据库建立全量索引，然后继续监听查询请求。第 4 步把 war 包复制到 Tomcat 的 webapps 目录后，Tomcat 启动时会自动解压，浏览器访问 http://localhost:8080/searchEngine_web 就能看到搜索页。
参数说明：-cp后面的 classpath 在 Windows 下要用分号分隔，Linux 和 macOS 下用冒号，很多人在这一步翻车。如果你的资源没有打包成 jar，直接从 IDE 运行主类也可以，但确保工作目录下有对应的配置文件，否则 ClassNotFoundException 会一直跟着你。
2.4 怎么确认四个模块真的起来了
启动成功不等于功能正常。我一般会在每个模块跑起来后做一次最小化验证，确认链路没有断：
| 模块 | 验证方式 | 看到什么才算通过 |
|---|---|---|
| web_spider | 控制台日志 | 每抓到一个页面打印“保存页面: URL”，数据库中记录数增长 |
| searchEngine_server | 控制台日志 | 启动后打印“索引完成：N docs”，N 等于数据库里的网页数 |
| anysearch | 命令行输入关键词 | 能返回文档 URL、标题和 Lucene 评分 |
| searchEngine_web | 浏览器访问搜索页 | 输入关键词能出结果，且结果标题不是乱码 |
如果 web_spider 没有打日志，先看数据库连接串和种子 URL 配置；如果 searchEngine_server 没有索引完成日志，八成是 index.dir 目录不存在或 MySQL 查不到数据；如果 anysearch 有结果而搜索页没有，问题基本出在 web 模块查询 Lucene 时的 Analyzer 不一致。这个表也是我后来写论文时“系统测试”章节的素材，一个模块一行，答辩时思路会很清晰。
2.5 端口、上下文路径和模块间调用的隐藏设定
searchEngine_server 如果作为独立查询服务，通常会监听一个端口，比如 9100；searchEngine_web 里的 Servlet 通过 HttpClient 或 Socket 去调用它。很多课设直接把 Lucene 查询代码写在 web 工程里，两种都能跑。但如果资源里 searchEngine_server 真的开了 REST 接口，你要确认 web 端连接的 host 和 port 配置与 server 一致。常见做法是 server 端启动一个 ServerSocket，监听 9100，web 端用一个 QueryClient 封装 socket 通信。这里最容易出的问题是本机启动没问题，部署到服务器后 web 模块还在请求 127.0.0.1，改成对应 IP 即可。
上下文路径也要注意：Tomcat 部署 war 后，访问路径默认是 war 包名。如果页面里的表单 action 写死 /searchEngine_web/search，而你换了目录，会出现 404。资源里的 JSP 若用了相对路径，则没有这个困扰。如果改了端口，记得同步修改 web 端配置里的 server.port，不然日志里全是 Connection refused。
3. Java 爬虫落地：Jsoup 解析、URL 去重与 MySQL 表结构设计
3.1 用 Jsoup 抓取正文的最小代码
爬虫是整个搜索引擎的基础。没有数据，后面索引和搜索全是空谈。资源里的 web_spider 模块用的是 Java 生态里最常见的 Jsoup，它既能发 HTTP 请求，也能把返回的 HTML 解析成 DOM，省去了用正则抓文本的痛苦。先看一个抓取正文的最小代码：
String html = Jsoup.connect(pageUrl) .userAgent("Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0 Safari/537.36") .timeout(10000) .ignoreHttpErrors(true) .execute() .body(); Document doc = Jsoup.parse(html, pageUrl); String title = doc.title(); Element contentNode = doc.selectFirst("article, #content, .content"); String content = contentNode == null ? doc.body().text() : contentNode.text();这段代码的逻辑是：先通过 Jsoup.connect 发起请求，拿到网页原始 HTML，再用 Jsoup.parse 把 HTML 解析成 Document 对象。doc.title() 取页面标题。正文部分优先选择常见的 article 标签或 id 为 content 的节点，因为这些区域通常是正文主体，能过滤掉导航和广告；如果找不到，就退回到 doc.body().text() 抓全文。
参数说明：userAgent 用来伪装成浏览器，很多站点对 Java 默认 UA 直接返回 403；timeout 设成 10000 毫秒，超过 10 秒就放弃这个页面，避免线程卡死；ignoreHttpErrors 很关键，它让 404、500 这类状态码也被接收，再由解析逻辑处理，而不是直接抛 HttpStatusException。content 字段建议截断到 5000 字左右再存库，否则一篇文章会撑爆整行数据。
3.2 URL 规范化与去重策略：内存加数据库双保险
爬虫最容易翻车的地方不是解析，而是重复抓取。同一个网页可能通过 http 和 https、带不带末尾斜杠、带不带锚点这几种形式出现。如果不去重，索引里会出现大量重复文档。我一般会先做 URL 规范化：
public String normalizeUrl(String url) { String norm = url .replaceAll("#.*$", "") // 去掉锚点 .replaceAll("/$", ""); // 去掉末尾斜杠 return norm; }这段代码把 # 后面的锚点去掉，把末尾的 / 去掉，得到一个相对稳定的去重键。更严格的做法是只保留协议和 host 再拼 path，但课设里这两种情况基本够用。拿到规范化 URL 后，用内存 Set 和数据库唯一索引双保险：
if (visitedUrls.contains(normalizedUrl)) { return; } String sql = "SELECT COUNT(*) FROM crawl_page WHERE url = ?"; if (jdbcTemplate.queryForObject(sql, Integer.class, normalizedUrl) > 0) { return; } visitedUrls.add(normalizedUrl);这里的逻辑是：内存 Set 解决单次运行内的重复访问，数据库查重解决进程重启后的重复入队。资源里的 crawl_page 表如果建了唯一索引，这里可以不用 SELECT 先查，直接插入时捕获 DuplicateKeyException 也行，但先查再插逻辑更直观。visitedUrls 要用 ConcurrentHashMap.newKeySet()，因为它会被多个爬虫线程同时读写。
3.3 crawl_page 与 fetch_queue 表结构设计
数据库表设计会直接影响建索引的代码。资源里的 web_spider 核心是两张表，一张存抓到的网页内容，一张做抓取队列：
CREATE TABLE `crawl_page` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `url` varchar(500) NOT NULL, `title` varchar(255) DEFAULT NULL, `content` longtext, `charset` varchar(20) DEFAULT 'utf-8', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_url` (`url`(255)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `fetch_queue` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `url` varchar(500) NOT NULL, `depth` int(11) DEFAULT 1, `status` tinyint(4) DEFAULT 0 COMMENT '0-等待抓取，1-成功，2-失败', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;两张表的逻辑关系很简单：fetch_queue 是待抓取队列，status 字段标记抓取状态；crawl_page 是抓取结果，url 字段建了唯一索引，重复插入时数据库会报错，这就是去重兜底。title 用 varchar(255)，content 用 longtext，因为网页正文长度不可控。charset 字段保存页面实际编码，后续解析时如果发现页面是 GBK，可以按对应编码读取，而不是默认按 UTF-8 硬解。
参数说明：depth 字段是爬取深度，比如种子页面的 depth=1，页面里的链接入队时 depth=2，超过最大深度 3 就不再继续解析链接。这能防止爬虫在站外链接上无限游走。如果资源里没有这个字段，也可以用 URL 前缀限制抓取范围，只允许同一个域名下。
3.4 多线程抓取与 robots 的朴素处理
毕业设计不需要做分布式爬虫，但单线程确实太慢。web_spider 里的常见写法是用固定线程池，每个线程负责一个 URL 的抓取和解析：
ExecutorService pool = Executors.newFixedThreadPool(5); for (String url : newUrlList) { pool.submit(() -> { try { Thread.sleep(200); crawlAndSave(url); } catch (InterruptedException ignored) { } }); } pool.shutdown(); pool.awaitTermination(1, TimeUnit.HOURS);这段代码的逻辑是：每取到一个新 URL，就丢给线程池执行 crawlAndSave。sleep(200) 是故意加的限速，200 毫秒一次请求，5 个线程大概每秒 5 个页面，对课设目标已经够用。如果不加限速，线程池会瞬间把目标站点打满，很快被对方封 IP。robots.txt 的处理也建议做在入口处：抓取前先请求目标域名下的 /robots.txt，把 Disallow 的路径记录下来，遇到底层连接异常就直接把该 URL 标记为失败，不要反复重试。这里特别提醒一句：课设不要去抓反爬严重的网站，绕验证码不是搜索引擎原理课该解决的问题。
4. Lucene 索引构建与中文分词：Analyzer、Document、IndexWriter 的关键细节
4.1 把一条网页记录写进索引的最小代码
Lucene 是整个系统的核心。严格来说它不是分词器，而是负责索引和检索的库，分词由 Lucene 的 Analyzer 完成。它的基本模型是 Document 加 Field，每个网页对应一个 Document，每个字段对应一个 Field。下面按 Lucene 7+ 的 API 写，如果你手里的包是 4.x，把 FSDirectory.open 的 Paths.get 换成 new File 即可：
Directory dir = FSDirectory.open(Paths.get("D:/search_engine/index")); Analyzer analyzer = new IKAnalyzer(); IndexWriterConfig config = new IndexWriterConfig(analyzer); config.setOpenMode(IndexWriterConfig.OpenMode.CREATE_OR_APPEND); IndexWriter writer = new IndexWriter(dir, config); for (CrawlPage page : pageList) { Document doc = new Document(); doc.add(new StringField("id", String.valueOf(page.getId()), Field.Store.YES)); doc.add(new StringField("url", page.getUrl(), Field.Store.YES)); doc.add(new TextField("title", page.getTitle(), Field.Store.YES)); doc.add(new TextField("content", page.getContent(), Field.Store.YES)); writer.addDocument(doc); } writer.commit(); writer.close();这段代码的逻辑是：把数据库里的一条 CrawlPage 记录转成一个 Lucene Document。StringField 只索引不切词，适合 id 和 url，查询时做精确匹配；TextField 会走 Analyzer 切词，适合 title 和 content。Field.Store.YES 表示把原文本存进索引，搜索结果页面展示标题和摘要时不需要回查 MySQL，直接从索引里拿。createTime 如果要参与排序，需要单独存一个 LongPoint 字段，后面第 6 章会再提到。
参数说明：CREATE_OR_APPEND 表示索引目录已有内容时追加，而不是清空。如果每次建索引都用这个模式，同一篇网页跑两次就会有两条记录，所以要配合全量重建逻辑，建索引前先删除整个 index.dir 目录。writer.commit() 把内存里的变更落盘，不 commit 就 close，数据有可能丢失。
4.2 中文分词选型：IKAnalyzer 的扩展词与停用词
Lucene 自带 StandardAnalyzer 对英文很友好，对中文会退化成单字切分。搜索“搜索引擎”时，它会把“搜”“索”“引”“擎”拆成四个单字，结果精度很差。资源里的 searchEngine_server 用的是 IKAnalyzer，它是基于词典的中文分词器，能把“搜索引擎”切成一个完整词。它的配置是 XML 文件加自定义词典：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"> <properties> <comment>IKAnalyzer 扩展配置</comment> <entry key="ext_dict">custom/ext.dic</entry> <entry key="ext_stopwords">custom/stopword.dic</entry> </properties>ext.dic 放互联网新词和领域词，比如“毕业设计”“前后端分离”“全文搜索引擎”，每行一个词，UTF-8 编码。stopword.dic 放“的、了、吗、呢”这类无意义词，让它们不进入索引，减少干扰。配置完成后，重启 searchEngine_server，分词器会自动加载这些词典。判断分词效果的最快方式是在 anysearch 里输入一个词组，看看能不能搜出完整匹配的结果。
这里有一个容易忽略的点：索引和查询必须使用同一个 Analyzer 实例，至少使用同一套词典。如果索引时用 IKAnalyzer，查询时用了 StandardAnalyzer，两个阶段切出来的 token 对不上，搜索结果会变成 0。这个坑太常见了，我后面避坑章节还会再展开。
4.3 MySQL 存量数据批量重建索引
数据量小的时候一次性全部读出没有问题，但网页数量一旦超过几千条，全表加载就很容易 OutOfMemoryError。常见做法是分页读取数据库，每处理 500 条 commit 一次：
int pageSize = 500; for (int start = 0; ; start += pageSize) { List<CrawlPage> pages = pageDao.queryByPage(start, pageSize); if (pages.isEmpty()) { break; } for (CrawlPage page : pages) { writer.addDocument(buildDoc(page)); } writer.commit(); System.out.println("已索引到第" + (start + pages.size()) + "条"); }这里的核心逻辑是增量提交。每次循环从数据库里取 500 条，构建成 Lucene Document 写入 IndexWriter，然后 commit 一次。这样即使程序中途崩溃，已经 commit 的索引还能继续使用，不用全部重来。queryByPage 的 SQL 在 MySQL 里建议写成SELECT * FROM crawl_page ORDER BY id LIMIT ? OFFSET ?，注意 LIMIT 和 OFFSET 的顺序，不同参数位置很容易写反。
重建索引前，记得把旧的索引目录清空。我第一次跑的时候没有清，索引里堆了旧网页和重新抓取的新网页，搜索结果里出现大量重复项。后来我习惯在 IndexServer 的启动参数里加一个 cleanIndex 开关，值为 true 时先执行 FileUtils.deleteDirectory，再开始建索引。
4.4 查询接口的封装与排序参数
searchEngine_server 对外提供的查询逻辑，通常不是直接操作 IndexSearcher，而是在外面包一层 SearchService。查询方法里要做四件事：构造 QueryParser、解析用户输入、设置分页和排序、把 TopDocs 转成结果对象。排序这块，默认是按 Lucene 的相关度评分降序，毕业设计里够用。如果想展示“按时间排序”，需要在建索引时额外写入时间字段，并重跑一次索引，否则搜索时会报字段未索引。
5. 避坑与常见问题：乱码、锁文件、抓不到数据、搜索无结果
下面几条是我在复现这类项目时踩过的高频问题，每一条都按“现象 → 原因 → 解决”来记。如果你照着跑一遍遇到同样的事，直接对号入座。
5.1 中文乱码：JSP、MySQL、Tomcat 三处都要统一 UTF-8
现象：页面上搜索“毕业设计”，结果标题和摘要变成问号，或者浏览器里显示一堆乱码，但数据库里的中文是正常的。
原因：中文从 JSP 表单提交到 Servlet，再到 MySQL，最后写回 Lucene 索引，中间任何一处编码不是 UTF-8 都会断。最常见的是 JSP 页面没用 UTF-8，或者 MySQL 连接串没带 characterEncoding。
解决：先把 Tomcat 的连接器加上 URIEncoding，然后检查 MySQL 连接串，最后确认 JSP 头声明：
<!-- Tomcat/conf/server.xml --> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" URIEncoding="UTF-8" />jdbc:mysql://localhost:3306/search_engine?useUnicode=true&characterEncoding=utf8<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>这三处分别解决 GET 请求参数编码、数据库读写编码、页面输出编码。改完以后要清 Tomcat 缓存并重启，不然还是旧的 class 在跑。这个排查顺序我后来几乎背下来了，遇到乱码先看请求，再查库，最后看页面。
5.2 索引目录被占用：IndexWriter 没 close 的锁文件问题
现象：第一次启动 searchEngine_server 正常，停掉进程后再启动，控制台报 LockObtainFailedException，或者提示无法获取索引目录的写锁。
原因：上次进程没有正常关闭 IndexWriter，Lucene 在索引目录里留下了 write.lock 文件。如果 JVM 是强制停止的，这个锁不会自动清理。
解决：先用任务管理器确认没有残留的 java 进程，然后删除索引目录下的锁文件：
rm -f D:/search_engine/index/write.lock对应的 Java 代码里也要养成习惯，把 writer.close() 放在 finally 或 try-with-resources 中：
try (IndexWriter writer = new IndexWriter(dir, config)) { // 写入索引 } catch (IOException e) { e.printStackTrace(); }try-with-resources 会保证 IndexWriter 正常释放锁。如果删除锁文件后仍然报错，说明可能有两个 JVM 实例同时打开了同一个索引目录，这时候要检查是不是 Tomcat 和 searchEngine_server 各自加载了一个 Lucene 副本。
5.3 爬虫抓回来 0 条：User-Agent 和忽略错误状态码缺一不可
现象：web_spider 启动后没有任何保存日志，数据库一张空表；或者抓到的全是验证码页面和 403 页面。
原因：目标站点对非浏览器请求做了拦截。Jsoup 默认的 User-Agent 是 Java 或空字符串，很多服务器直接拒绝。另外，有些网页返回 404 或 500 时，Jsoup 会抛 HttpStatusException，导致程序以为这个页面不可用，跳过了实际有内容的页面。
解决：先用命令试探目标站点是否欢迎你的 UA：
curl -I -A "Mozilla/5.0" https://example.com如果返回 200，再把 UA 写进 Jsoup 的 connect 链路上，加上 ignoreHttpErrors(true)。注意不要为了抓取去伪造各种反爬参数，课设场景里选择公开测试站点或站内页面就好。曾经我把目标设成一个反爬很严的新闻站，整天对着验证码发愁，调了一周什么数据都没抓到，后来换成本地启动的测试页面，半天就通了。
5.4 索引有数据却查不到：分词器不一致是罪魁祸首
现象：searchEngine_server 启动日志显示“索引完成：1000 docs”，anysearch 里输入英文词能出结果，输入中文“搜索引擎”却返回 0 条。
原因：索引时用的是 IKAnalyzer，查询时却用了 StandardAnalyzer，两个分词器切法完全不同。“搜索引擎”在 IK 下是一个词，在 Standard 下是“搜”“索”“引”“擎”四个字，查询词根本无法命中。另外，用户输入里如果带了冒号、加号、括号等 Lucene 查询语法符号，也会导致 QueryParser 解析异常。
解决：把查询端的 Analyzer 换成和索引端完全一样的实现，并对输入做转义：
QueryParser parser = new QueryParser("content", new IKAnalyzer()); Query query = parser.parse(QueryParser.escape(keyword));QueryParser.escape 会把特殊字符转成普通字符，避免用户输入“C++”时被解析成“C++”的语法表达式。查不到中文时，先在 anysearch 里输入单个词汇试，比如“毕业”，如果单字能查出来，说明分词器配置有问题；如果单字也查不出来，优先检查索引目录是不是空的。
5.5 Tomcat 启动失败：jar 包冲突和堆内存设置
现象：部署 searchEngine_web.war 后，Tomcat 启动到一半抛 NoSuchMethodError，或者直接 OutOfMemoryError，网页打不开。
原因：war 的 WEB-INF/lib 下可能有多个版本的 Lucene 或 Jsoup，Tomcat 加载时出现了类冲突。也有可能是默认 JVM 堆内存不够，Lucene 的索引加载和 JSP 编译同时进行时峰值内存超限。
解决：先看 war 解压目录，把重复 jar 清理到只剩一份，特别是 lucene-core、lucene-queryparser 这类核心依赖。然后在 Tomcat 的启动参数里固定内存大小：
# Tomcat/bin/catalina.bat 或 catalina.sh CATALINA_OPTS="-Xms256m -Xmx1024m -XX:MaxMetaspaceSize=256m"如果之前部署过同名 war，建议把 Tomcat 的 work 目录也清一遍，有时候残留的编译缓存会引发奇怪问题。遇到 NoSuchMethodError 时，不要急着改代码，先检查 classpath 里的 jar 版本是不是各自为政，这种“jar 地狱”改配置比改代码快得多。
6. 上线前验证：索引文档数、查询耗时和结果排序的检查清单
项目能跑起来只是第一步，能证明它跑得对才是拿高分的关键。我每次拿到搜索引擎课设，都会先做三个验证：索引文档数对比、查询耗时测量、排序字段检查。这三项已经超出了“能出页面”的层面，但写进论文和答辩演示里很有说服力。
第一个验证是看索引里的有效文档数。用 IndexReader 直接数：
Directory dir = FSDirectory.open(Paths.get("D:/search_engine/index")); IndexReader reader = DirectoryReader.open(dir); System.out.println("numDocs=" + reader.numDocs()); System.out.println("maxDoc=" + reader.maxDoc()); reader.close();numDocs 是当前可以搜索到的文档数，maxDoc 包含已经标记删除但还没合并的文档。两者如果差得很多，说明索引里堆积了大量重复旧数据，需要重建索引而不是继续追加。正常情况下，numDocs 应该等于 crawl_page 表里的记录数。
第二个验证是查询耗时。在 SearchService 里加一行时间戳，给出的建议是本地几万条数据，返回 10 条结果应该在 100 毫秒以内。如果明显超时，优先怀疑是不是没有走 Lucene 索引，而是每次都回查 MySQL。现场演示时，这个数字可以直接截图放进论文。
第三个验证是排序。默认排序是相关度，毕业设计里没问题。但如果你的搜索页面有“按时间筛选”按钮，索引里就要有可排序的数值字段，建索引时用 LongPoint 存时间戳，查询时用 SortField 指定时间倒序。没有对应字段的索引，运行时直接报错，这类问题要提前在测试数据里跑一遍。
从那以后，我每次拿到一套搜索引擎源码，都强制先跑一遍文档数对比和查询耗时，再改任何一行功能代码。这个习惯帮我避开了大量“页面白屏但索引其实没坏”的假象，也能快速定位问题到底出在抓取、建索引还是查询环节。资源里的四个模块和论文讲义是一次很好的练习机会，按这个顺序走完，你会对 java 爬虫、Lucene 全文搜索和 JSP 整个链路有真实的理解。希望帮到你。
本文还有配套的精品资源，点击获取
