Greasy Fork

【作者提醒】申请添加支持网站前，请先确认不是【动态加载内容】的网站（鼠标指向页码，浏览器左下角显示链接即代表不是），这类网站无法制作规则。

准确说是绝大部分动态加载内容的网站都无法添加支持，但有一些点击页码后网页的 URL 也跟着变化的（有明确页码信息）可能有办法添加支持，但这类网站太少，我目前写的 600+ 规则中，支持的动态加载内容网站也就只有 20+ 个罢了，其他的全都是静态加载内容的网站。。。

就像我脚本介绍页里说的：

客观的讲翻页类脚本迟早要被时代所抛弃，从这几年的发展来看，未来越来越多网站会改为动态加载内容，这意味着越来越多网站都将无法添加支持...

特别是一些大公司的网站，这些年都陆陆续续的更新网站前端技术使用上动态加载内容了，这是大趋势，不过对于中小型网站，往往都不着急更新网站前端技术，而这类网站毕竟占大多数，因此我这个脚本，还是能苟活好些年的（当然前提是我天天更新的兴趣动力能持续那么久 ~

望理解。

另外，顺便科普一下为什么动态加载内容无法添加支持，有兴趣的可以看看。

静态加载内容的网站：
访问网页时，网站是将完整网页内容一股脑的发给你了，因此你打开网页后看到的就是完整网页内容，这样脚本才能在后台访问下一页获取主体内容。

动态加载内容的网站：
访问网页时，网站先把网页大体框架发给你，然后再运行网页中的 JS 代码来获取网页主体内容，再去将获取到的内容数据格式化为网页元素并插入网页，最后根据需要对这些元素绑定各种事件（鼠标点击事件什么的，比如页码的点击事件是获取下一页的数据内容，然后重复前面的处理步骤）。
对于这种网站，你会发现点击页码后，网页内容变了，但却没有跳转网页，URL 可能也没有变化。

对于动态加载内容的网站，连个下一页的 URL 都没有的话，脚本压根不知道后台访问什么。。。

想要对动态加载内容的网站添加支持，需要逆向分析网页，了解网页是如何获取网页内容数据（一般是 JSON 格式）、如何格式化的、如何插入网页的、如何绑定各种事件的等等，这一套下来简单的话可能需要连续折腾五、六个小时，复杂点那就几天起步了，然后才能去研究能不能脚本模拟实现（毕竟脚本不是万能的，如果不行的话，那么前面的就白研究了），而且最重要的是如果网站有些许变动，那么可能前面费劲做的事情都前功尽弃了。。。

如果这类网站自身去实现无缝翻页效果，难度是 1 的话（因为都是代码现成的，稍微改改就行了），那么我用油猴脚本去实现的难度就是 10。

因此，这也是为什么我目前添加支持的动态加载内容网站这么少，且还都是简单的那种（比如漫画网站，因为只是一些图片，不需要操心那么多，但这也最少需要做一、两个小时，当然这是值得技术简单的盗版漫画网站，如果是正版的有防爬机制就很难了），就是因为做起来太麻烦、太费劲、太消耗精力了。。。

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

定期手动置顶~

现在不都流行什么信息流让用户不断上瘾无限加载，为啥还要有翻页？

@虚度 不清楚，我不是这个行业的人员，我也不明白，既然这些网站都已经升级技术到 "动态加载内容" 了，为啥还要搞页码，让用户手动翻页。。。

原来如此，一下豁然开朗了。
我说yyds点fans，pageElement，还有nextLink，我已经换着各种XPath，确定XPath不可能全错吧，脚本运行时就是识别提取不到XPath内容，原来全是动态生成的页面，页面上的页码和下一页的链接都没有，之前一直没注意到这地方。
作者如果业余时间有兴趣研究的话，能不能逆向分析一下这个网站，自动翻页是怎么样的，虽然这个网站资源下载是付费的，但是页面列表内容的推送质量很高，推送也很新，网站内容展示的也很不错，资源也挺容易在其他地方找到。