好吧，代码量还是由项目决定，只要十行有些夸张了。不过用来做小规模定向抓取的话，比如简单地爬爬图片、抓抓数据，确实是十几行代码。
简单，开箱即用
- 简单粗暴的 download 方法，想下就下
- 某个 url 意外抓取失败？retry 方法直接重试
- 无视乱码问题，自动编码正文为 utf8（选项）
- 熟悉的 jQ 选择器，提取正文数据的必备神器
- 用 pipe 储存抓取的数据，谁用谁舒畅
灵活，稳健扩展
当我们要开发一个灵活、稳健的爬虫，我们需要……
- 如果希望爬虫更稳定，需要写一套出错后的重试机制吧？
- 如果定向爬取的网页结构复杂，一个爬虫实例需要处理好几个网页结构，是不是需要再加一套完善的爬取计划管理？
- 如果需要对抓取的数据进行大量的储存操作，是不是需要操作并管理好文件流，最好封装为 pipeline？
- 如果需要防止访问重复链接，是不是需要再搭一个url池？
- 如果要做分布式，是不是要把队列搬到redis，并管理起来？
- 如果……
这些就是 nodespider 设计的初衷——提供简单、开箱即用的api方法，完成基础设计并提供扩展的接口，减少开发过程的重复工作。希望nodespider 能成为一个nodejs的爬虫开发框架，更希望对大家有些帮助
未来还可能支持
- phantomJs-plan 和 chromeless-plan，模拟 js 环境……
- redis-queue，可以完成简易版的分布式抓取
- mysql-pipe，直接保存抓取的数据到数据库
- ……
更多请看： nodespider 文档 喜欢的话，不要吝啬你的star嘿嘿 github
例子
// 例子：抓取本页面，并console.log输出帖子与评论内容
const { Spider } = require("../build/index");
const s = new Spider();
s.plan("myPlan", (err, current) => {
if (err) return s.retry(current);
const $ = current.$;
console.log($(".topic_content").text()); // 打印帖子
$(".reply_item").each(function () {
let text = $(this).text().replace(/\s+/g, " ");
console.log(text); // 打印每个评论
});
})
s.queue("myPlan", "https://cnodejs.org/topic/59cd08505704b6f30c5678fe");
@ianchn 哈哈，如果只是简单的定向爬取，确实request + cheerio就够了。但如果希望爬虫更稳定，总是要写一套出错后的重试机制对吧？如果定向爬取的网页结构复杂，一个爬虫实例需要处理好几个网页结构，是不是要再加一套完善的爬取计划管理？如果需要对抓取的数据进行大量的储存操作，是不是要操作并管理好文件流？如果需要防止访问重复链接，是不是要再搭一个url池？如果要做分布式，是不是要把队列搬到redis，并管理起来？这些 nodespider 已经写好了，希望对你有一些帮助
没有批评的意思，然后说一些浅显的见解，不要打我。 一般小爬虫手写就可以了，为什么非得用你这个框架呢，而且如果要实际应用到生产环境中，可能很多情况应用都比较大，数据量也会比较大，觉得这类爬虫框架应该是以自己可构建稳定健壮的大型应用为卖点，而不仅仅是简单开箱即用 另外
简单，开箱即用
简单粗暴的 download 方法，想下就下
某个 url 意外抓取失败？retry 方法直接重试
无视乱码问题，自动编码正文为 utf8（选项）
熟悉的 jQ 选择器，提取正文数据的必备神器
用 pipe 储存抓取的数据，谁用谁舒畅
以上几点作为应用的介绍还是有些欠妥，可以改为自己应用的独立特性来代替依赖的特性
@vanishcode 关于应用介绍和宣传卖点，我认同你的看法，不过我暂时不知道该怎么改，如果你有建议我非常欢迎。
至于开箱即用和稳定健壮，说实话我两个都想要，这是设计理念的问题，也是我重构近一百多个版本不断寻找两者平衡的原因。虽然我暂时不认为能够开发稳健的大型应用（大型？真的还用nodejs？），像谷歌搜索爬虫级别更是不可能，但这些都是 nodespider 未来努力的方向，我相信开源的力量。
以前用这个包写60行代码，爬过150万条前途无忧的招聘信息，这种小数据量非常顺利，大的就真没试过了。如果大家试过了可以说说效果
