早年折腾 Nutch：一次「想自己做搜索」的学习复盘
很多年前，我在 Ubuntu 上搭过 Apache Nutch。原稿停留在装 JDK、改环境变量、下了个 jar，末尾写着「未完待续」——典型的技术博客半成品：环境配到一半，兴趣被下一件事抢走。
今天不把它续成过时教程，而是当成一次学习复盘：那时为什么想碰搜索引擎，踩过什么坑，对现在做产品（站内搜索、内容站、工具站）还有什么用。
当时为什么碰 Nutch
做站点久了，就会对「搜索」过敏又着迷。用户来你网站，第一反应常常是找框：有没有我想要的源码、文章、商品？百度能带来流量，但站内体验是另一回事。Nutch 作为开源爬虫 + 搜索生态里的老将，吸引力很直接——能不能自己抓、自己建索引、自己出结果。
技术路线大致是：Java 环境 → Nutch 爬取 → 落到 Solr/Elasticsearch 一类引擎检索。听起来完整，实际一个人玩，光环境就能劝退。
还记得的技术要点（精简版）
这些步骤今天未必照抄，但逻辑仍在：
- 先把运行时钉死。
当时常见是装 Oracle JDK 8，配置 JAVA_HOME、PATH，用 update-alternatives 确认默认 java。搜索中间件对版本敏感，环境漂移会浪费整天。
- 分清「爬虫」和「检索」。
Nutch 擅长抓取与链接跟踪；真正好用的查询体验，往往要接 Solr/ES，并处理好分词、字段权重、更新策略。很多人以为装好 Nutch 就有谷歌，其实只完成了供应链前半段。
- 种子、爬取深度、去重、礼貌延迟，全是产品问题。
不是参数调优游戏。你要抓什么、多久更新、如何避免把目标站打挂，直接决定索引质量与法律/道德边界。
- 运维成本被严重低估。
磁盘、失败重试、死链、编码、重复页面……一人维护全网级爬虫不现实；哪怕只爬自己的站点，也要有任务调度和监控。
原稿里那段 export JAVA_HOME=... 之类的配置，今天看来像考古。但「先让环境可复现」这件事，做任何后端产品都仍成立。
这次折腾真正留下的启发
1. 用户要的是「找到」，不是「你有搜索引擎」
自己搭 Nutch 很酷，但对内容站来说，成功标准是：关键词能否命中、结果是否按意图排序、更新是否及时。引擎品牌不重要。后来做站点产品，我更愿意问：站内搜索有没有覆盖标题/标签/正文？有没有空结果兜底？有没有热门词？
2. 约束会倒逼架构选择
全网搜索是平台级问题；站内搜索是产品功能。一人公司应该选后者。数据在自己库里，用数据库全文检索、Meilisearch、Typesense，或云检索，往往比自建爬虫栈更划算。
3. 「未完待续」提醒我：学习要闭环
技术学习最怕只停在装环境。更有价值的闭环是：索引 100 篇自己的文章 → 做个搜索框 → 看失败 case → 再决定要不要上更重的方案。闭环产出的是判断，不只是笔记。
4. 对今日产品的具体映射
- 内容站 / 博客：优先保证可发现性（导航、标签、内链、站内搜索），再谈复杂推荐。
- 建站工具：给用户的是「快上线 + 可被找到」，搜索是体验的一部分，不是炫技模块。
- 聚合类产品：核心是数据清洗与更新频率；爬虫策略要服务业务，而不是反过来。
如果重来一次，我会怎么学
- 先用最小方案实现「可搜」；
- 记录 20 个真实查询与烂结果；
- 再决定是否引入独立搜索服务；
- 把部署写成可重复脚本，而不是博客里一串手工命令。
Nutch 那次没有变成上线系统，但不算浪费。它让我明白：搜索是产品能力，基础设施只是手段。独立开发者缺的不是更酷的中间件，而是更清楚的用户任务——他们到底在找什么，你怎样用最小成本帮他们找到。
暂无评论