单页解析接口源码

⑴ 素材解析网站接口如何获取

1、进行简单设置，将ViewSource添加到Safari扩展菜单，在Safari打开任意一个网页后，点击底部的分享按钮，第二行的扩展菜单滑动至最右，选择更多，在活动页面，找到ViewSource并将开关打开，这样ViewSource就添加到Safari扩展菜单了。
2、找寻一些可用的在线解析。
3、查看网页源代码，获取解析接口。

⑵ Android socket源码解析(三)socket的connect源码解析

上一篇文章着重的聊了socket服务端的bind，listen，accpet的逻辑。本文来着重聊聊connect都做了什么？

如果遇到什么问题，可以来本文 https://www.jianshu.com/p/da6089fdcfe1 下讨论

当服务端一切都准备好了。客户端就会尝试的通过 connect 系统调用，尝试的和服务端建立远程连接。

首先校验当前socket中是否有正确的目标地址。然后获取IP地址和端口调用 connectToAddress 。

在这个方法中，能看到有一个 NetHooks 跟踪socket的调用，也能看到 BlockGuard 跟踪了socket的connect调用。因此可以hook这两个地方跟踪socket，不过很少用就是了。

核心方法是 socketConnect 方法，这个方法就是调用 IoBridge.connect 方法。同理也会调用到jni中。

能看到也是调用了 connect 系统调用。

文件：/ net / ipv4 / af_inet.c

在这个方法中做的事情如下：

注意 sk_prot 所指向的方法是， tcp_prot 中 connect 所指向的方法，也就是指 tcp_v4_connect .

文件：/ net / ipv4 / tcp_ipv4.c

本质上核心任务有三件:

想要能够理解下文内容，先要明白什么是路由表。

路由表分为两大类：

每个路由器都有一个路由表(RIB)和转发表 (fib表)，路由表用于决策路由，转发表决策转发分组。下文会接触到这两种表。

这两个表有什么区别呢？

网上虽然给了如下的定义：

但实际上在Linux 3.8.1中并没有明确的区分。整个路由相关的逻辑都是使用了fib转发表承担的。

先来看看几个和FIB转发表相关的核心结构体：

熟悉Linux命令朋友一定就能认出这里面大部分的字段都可以通过route命令查找到。

命令执行结果如下：

在这route命令结果的字段实际上都对应上了结构体中的字段含义：

知道路由表的的内容后。再来FIB转发表的内容。实际上从下面的源码其实可以得知，路由表的获取，实际上是先从fib转发表的路由字典树获取到后在同感加工获得路由表对象。

转发表的内容就更加简单

还记得在之前总结的ip地址的结构吗？

需要进行一次tcp的通信，意味着需要把ip报文准备好。因此需要决定源ip地址和目标IP地址。目标ip地址在之前通过netd查询到了，此时需要得到本地发送的源ip地址。

然而在实际情况下，往往是面对如下这么情况：公网一个对外的ip地址，而内网会被映射成多个不同内网的ip地址。而这个过程就是通过DDNS动态的在内存中进行更新。

因此 ip_route_connect 实际上就是选择一个缓存好的，通过DDNS设置好的内网ip地址并找到作为结果返回，将会在之后发送包的时候填入这些存在结果信息。而查询内网ip地址的过程，可以成为RTNetLink。

在Linux中有一个常用的命令 ifconfig 也可以实现类似增加一个内网ip地址的功能：

比如说为网卡eth0增加一个IPV6的地址。而这个过程实际上就是调用了devinet内核模块设定好的添加新ip地址方式，并在回调中把该ip地址刷新到内存中。

注意 devinet 和 RTNetLink 严格来说不是一个存在同一个模块。虽然都是使用 rtnl_register 注册方法到rtnl模块中：

文件：/ net / ipv4 / devinet.c

文件：/ net / ipv4 / route.c

实际上整个route模块，是跟着ipv4 内核模块一起初始化好的。能看到其中就根据不同的rtnl操作符号注册了对应不同的方法。

整个DDNS的工作流程大体如下：

当然，在tcp三次握手执行之前，需要得到当前的源地址，那么就需要通过rtnl进行查询内存中分配的ip。

文件：/ include / net / route.h

这个方法核心就是 __ip_route_output_key .当目的地址或者源地址有其一为空，则会调用 __ip_route_output_key 填充ip地址。目的地址为空说明可能是在回环链路中通信，如果源地址为空，那个说明可能往目的地址通信需要填充本地被DDNS分配好的内网地址。

在这个方法中核心还是调用了 flowi4_init_output 进行flowi4结构体的初始化。

文件：/ include / net / flow.h

能看到这个过程把数据中的源地址，目的地址，源地址端口和目的地址端口，协议类型等数据给记录下来，之后内网ip地址的查询与更新就会频繁的和这个结构体进行交互。

能看到实际上 flowi4 是一个用于承载数据的临时结构体，包含了本次路由操作需要的数据。

执行的事务如下：

想要弄清楚ip路由表的核心逻辑，必须明白路由表的几个核心的数据结构。当然网上搜索到的和本文很可能大为不同。本文是基于LInux 内核3.1.8.之后的设计几乎都沿用这一套。

而内核将路由表进行大规模的重新设计，很大一部分的原因是网络环境日益庞大且复杂。需要全新的方式进行优化管理系统中的路由表。

下面是fib_table 路由表所涉及的数据结构：

依次从最外层的结构体介绍：

能看到路由表的存储实际上通过字典树的数据结构压缩实现的。但是和常见的字典树有点区别，这种特殊的字典树称为LC-trie 快速路由查找算法。

这一篇文章对于快速路由查找算法的理解写的很不错: https://blog.csdn.net/dog250/article/details/6596046

首先理解字典树：字典树简单的来说，就是把一串数据化为二进制格式，根据左0，右1的方式构成的。

如图下所示：

这个过程用图来展示，就是沿着字典树路径不断向下读，比如依次读取abd节点就能得到00这个数字。依次读取abeh就能得到010这个数字。

说到底这种方式只是存储数据的一种方式。而使用数的好处就能很轻易的找到公共前缀，在字典树中找到公共最大子树，也就找到了公共前缀。

而LC-trie 则是在这之上做了压缩优化处理，想要理解这个算法，必须要明白在 tnode 中存在两个十分核心的数据：

这负责什么事情呢？下面就简单说说整个lc-trie的算法就能明白了。

当然先来看看方法 __ip_dev_find 是如何查找

文件：/ net / ipv4 / fib_trie.c

整个方法就是通过 tkey_extract_bits 生成tnode中对应的叶子节点所在index，从而通过 tnode_get_child_rcu 拿到tnode节点中index所对应的数组中获取叶下一级别的tnode或者叶子结点。

其中查找index最为核心方法如上，这个过程，先通过key左移动pos个位，再向右边移动（32 - bits）算法找到对应index。

在这里能对路由压缩算法有一定的理解即可，本文重点不在这里。当从路由树中找到了结果就返回 fib_result 结构体。

查询的结果最为核心的就是 fib_table 路由表，存储了真正的路由转发信息

文件：/ net / ipv4 / route.c

这个方法做的事情很简单，本质上就是想要找到这个路由的下一跳是哪里？

在这里面有一个核心的结构体名为 fib_nh_exception 。这个是指fib表中去往目的地址情况下最理想的下一跳的地址。

而这个结构体在上一个方法通过 find_exception 获得.遍历从 fib_result 获取到 fib_nh 结构体中的 nh_exceptions 链表。从这链表中找到一模一样的目的地址并返回得到的。

文件：/ net / ipv4 / tcp_output.c

⑶ OkHttp源码解析 （三）——代理和路由

初看OkHttp源码，由于对Address、Route、Proxy、ProxySelector、RouteSelector等理解不够，读源码非常吃力，看了几遍依然对于寻找复用连接、创建连接、连接服务器、连接代理服务器、创建隧道连接等逻辑似懂非懂，本篇决定梳理一遍相关的概念及基本原理。

● HTTP/1.1(HTTPS)
● HTTP/2
● SPDY

一个http请求的流程（直连）：
1、输入url及参数；
2、如果是url是域名则解析ip地址，可能对应多个ip，如果没有指定端口，则用默认端口，http请求用80；
3、创建socket，根据ip和端口连接服务器（socket内部会完成3次TCP握手）；
4、socket成功连接后，发送http报文数据。

一个https请求的流程（直连）：
1、输入url及参数；
2、如果是url是域名则解析ip地址，可能对应多个ip，如果没有指定端口，则用默认端口，https请求用443；
3、创建socket，根据ip和端口连接服务器（socket内部会完成3次TCP握手）；
4、socket成功连接后进行TLS握手，可通过java标准款提供的SSLSocket完成；
5、握手成功后，发送https报文数据。

1、分类
● HTTP代理：普通代理、隧道代理
● SOCKS代理：SOCKS4、SOCKS5

2、HTTP代理分类及说明
普通代理
HTTP/1.1 协议的第一部分。其代理过程为：
● client 请求 proxy
● proxy 解析请求获取 origin server 地址
● proxy 向 origin server 转发请求
● proxy 接收 origin server 的响应
● proxy 向 client 转发响应
其中proxy获取目的服务器地址的标准方法是解析 request line 里的 request-URL。因为proxy需要解析报文，因此普通代理无法适用于https，因为报文都是加密的。

隧道代理
通过 Web 代理服务器用隧道方式传输基于 TCP 的协议。
请求包括两个阶段，一是连接（隧道）建立阶段，二是数据通信（请求响应）阶段，数据通信是基于 TCP packet ，代理服务器不会对请求及响应的报文作任何的处理，都是原封不动的转发，因此可以代理 HTTPS请求和响应。
代理过程为：
● client 向 proxy 发送 CONNET 请求（包含了 origin server 的地址）
● proxy 与 origin server 建立 TCP 连接
● proxy 向 client 发送响应
● client 向 proxy 发送请求，proxy 原封不动向 origin server 转发请求，请求数据不做任何封装，为原生 TCP packet.

3、SOCKS代理分类及说明
● SOCKS4：只支持TCP协议（即传输控制协议）
● SOCKS5: 既支持TCP协议又支持UDP协议（即用户数据包协议），还支持各种身份验证机制、服务器端域名解析等。
SOCK4能做到的SOCKS5都可得到，但反过来却不行，比如我们常用的聊天工具QQ在使用代理时就要求用SOCKS5代理，因为它需要使用UDP协议来传输数据。

有了上面的基础知识，下面分析结合源码分析OkHttp路由相关的逻辑。OkHttp用Address来描述与目标服务器建立连接的配置信息，但请求输入的可能是域名，一个域名可能对于多个ip，真正建立连接是其中一个ip，另外，如果设置了代理，客户端是与代理服务器建立直接连接，而不是目标服务器，代理又可能是域名，可能对应多个ip。因此，这里用Route来描述最终选择的路由，即客户端与哪个ip建立连接，是代理还是直连。下面对比下Address及Route的属性，及路由选择器RouteSelector。

描述与目标服务器建立连接所需要的配置信息，包括目标主机名、端口、dns，SocketFactory，如果是https请求，包括TLS相关的SSLSocketFactory 、HostnameVerifier 、CertificatePinner，代理服务器信息Proxy 、ProxySelector 。

Route提供了真正连接服务器所需要的动态信息，明确需要连接的服务器IP地址及代理服务器，一个Address可能会有很多个路由Route供选择（一个DNS对应对个IP）。

Address和Route都是数据对象，没有提供操作方法，OkHttp另外定义了RouteSelector来完成选择的路由的操作。

1、读取代理配置信息：resetNextProxy()

读取代理配置：
● 如果有指定代理（不读取系统配置，在OkHttpClient实例中指定），则只用1个该指定代理；
● 如果没有指定，则读取系统配置的，可能有多个。

2、获取需要尝试的socket地址（目标服务器或者代理服务器）：resetNextInetSocketAddress()

结合Address的host和代理，解析要尝试的套接字地址（ip+端口）列表：
● 直连或者SOCK代理， 则用目标服务器的主机名和端口，如果是HTTP代理，则用代理服务器的主机名和端口；
● 如果是SOCK代理，根据目标服务器主机名和端口号创建未解析的套接字地址，列表只有1个地址；
● 如果是直连或HTTP代理，先DNS解析，得到InetAddress列表（没有端口），再创建InetSocketAddress列表（带上端口），InetSocketAddress与InetAddress的区别是前者带端口信息。

3、获取路由列表：next()

选择路由的流程解析：
● 遍历每个代理对象，可能多个，直连的代理对象为Proxy.DIRECT（实际是没有中间代理的）；
● 对每个代理获取套接字地址列表；
● 遍历地址列表，创建Route，判断Route如果在路由黑名单中，则添加到失败路由列表，不在黑名单中则添加到待返回的Route列表；
● 如果最后待返回的Route列表为空，即可能所有路由都在黑名单中，实在没有新路由了，则将失败的路由集合返回；
● 传入Route列表创建Selection对象，对象比较简单，就是一个目标路由集合，及读取方法。

为了避免不必要的尝试，OkHttp会把连接失败的路由加入到黑名单中，由RouteDatabase管理，该类比较简单，就是一个失败路由集合。

1、创建Address
Address的创建在RetryAndFollowUpInteceptor里，每次请求会声明一个新的Address及StreamAllocation对象，而StreamAllocation使用Address创建RouteSelector对象，在连接时RouteSelector确定请求的路由。

每个Requst都会构造一个Address对象，构造好了Address对象只是有了与服务器连接的配置信息，但没有确定最终服务器的ip，也没有确定连接的路由。

2、创建RouteSelector
在StreamAllocation声明的同时会声明路由选择器RouteSelector，为一次请求寻找路由。

3、选择可用的路由Route

下面在测试过程跟踪实例对象来理解，分别测试直连和HTTP代理HTTP2请求路由的选择过程：
● 直连请求流程
● HTTP代理HTTPS流程
请求url： https://www.jianshu.com/p/63ba15d8877a

1、构造address对象

2、读取代理配置：resetNextProxy

3、解析目标服务器套接字地址：resetNextInetSocketAddress

4、选择Route创建RealConnection

5、确定协议

测试方法：
● 在PC端打开Charles，设置端口，如何设置代理，网上有教程，比较简单；
● 手机打开WIFI，选择连接的WIFI修改网络，在高级选项中设置中指定了代理服务器，ip为PC的ip，端口是Charles刚设置的端口；
● OkHttpClient不指定代理，发起请求。

1、构造address对象

2、读取代理配置：resetNextProxy

3、解析目标服务器套接字地址：resetNextInetSocketAddress

4、选择Route创建RealConnection

5、创建隧道
由于是代理https请求，需要用到隧道代理。

从图可以看出，建立隧道其实是发送CONNECT请求，header包括字段Proxy-Connection，目标主机名，请求内容类似：

6、确定协议，SSL握手

1、代理可分为HTTP代理和SOCK代理；
2、HTTP代理又分为普通代理和隧道代理；普通代理适合明文传输，即http请求；隧道代理仅转发TCP包，适合加密传输，即https/http2;
3、SOCK代理又分为SOCK4和SOCK5，区别是后者支持UDP传输，适合代理聊天工具如QQ；
4、没有设置代理（OkHttpClient没有指定同时系统也没有设置），客户端直接与目标服务器建立TCP连接；
5、设置了代理，代理http请求时，客户端与代理服务器建立TCP连接，如果代理服务器是域名，则解释代理服务器域名，而目标服务器的域名由代理服务器解析；
6、设置了代理，代理https/http2请求时，客户端与代理服务器建立TCP连接，发送CONNECT请求与代理服务器建立隧道，并进行SSL握手，代理服务器不解析数据，仅转发TCP数据包。

如何正确使用 HTTP proxy
OkHttp3中的代理与路由
HTTP 代理原理及实现（一）

⑷ 哪位高手知道网页源代码解析技术

恩恩,源代码其实一点用都不顶的,如果是下载个FLASH文件或者音乐视频什么的调用还好使,要是连接数据库就不行了,基本全都隐藏了

⑸ Spring Tx源码解析(二)

   上一篇 我们介绍了 spring-tx 中的底层抽象，本篇我们一起来看看围绕这些抽象概念 spring-tx 是如何打造出声明式事务的吧。笼统的说， spring-tx-5.2.6.RELEASE 的实现主要分为两个部分：

这两部分彼此独立又相互成就，并且每个部分都有着大量的源码支撑，本篇我们先来分析 spring-tx 中的AOP部分吧。

   EnableTransactionManagement 注解想必大家都很熟悉了，它是启用 Spring 中注释驱动的事务管理功能的关键。

EnableTransactionManagement 注解的主要作用是向容器中导入 ，至于注解中定义的几个属性在 Spring AOP源码解析 中有过详细分析，这里就不再赘述了。

由于我们并没有使用 AspectJ ，因此导入容器的自然是 这个配置类。

  这个配置类的核心是向容器中导入一个类型为 的Bean。这是一个 PointcutAdvisor ，它的 Pointcut 是 ， Advice 是 TransactionInterceptor 。

   利用 TransactionAttributeSource 解析 @Transactional 注解的能力来选取标注了 @Transactional 注解的方法，而 TransactionInterceptor 则根据应用提出的需求（来自对 @Transactional 注解的解析）将方法增强为事务方法，因此 可以识别出那些标注了 @Transactional 注解的方法，为它们应用上事务相关功能。

   TransactionInterceptor 能对方法进行增强，但是它却不知道该如何增强，比如是为方法新开一个独立事务还是沿用已有的事务？什么情况下需要回滚，什么情况下不需要？必须有一个‘人’告诉它该如何增强，这个‘人’便是 TransactionAttributeSource 。

   @Transactional 注解定义了事务的基础信息，它表达了应用程序期望的事务形态。 TransactionAttributeSource 的主要作用就是解析 @Transactional 注解，提取其属性，包装成 TransactionAttribute ，这样 TransactionInterceptor 的增强便有了依据。

前面我们已经见过， spring-tx 使用 来做具体的解析工作，其父类 定义了解析 TransactionAttribute 的优先级，核心方法是 computeTransactionAttribute(...) 。

默认只解析 public 修饰的方法，这也是导致 @Transactional 注解失效的一个原因，除此之外它还实现了父类中定义的两个模板方法：

同时为了支持 EJB 中定义的 javax.ejb.TransactionAttribute 和 JTA 中定义的 javax.transaction.Transactional 注解， 选择将实际的提取工作代理给 TransactionAnnotationParser 。Spring 提供的 @Transactional 注解由 进行解析。

的源码还是很简单的，它使用 AnnotatedElementUtils 工具类定义的 find 语义来获取 @Transactional 注解信息。 RuleBasedTransactionAttribute 中 rollbackOn(...) 的实现还是挺有意思的，其它的都平平无奇。

RollbackRuleAttribute 是用来确定在发生特定类型的异常（或其子类）时是否应该回滚，而 NoRollbackRuleAttribute 继承自 RollbackRuleAttribute ，但表达的是相反的含义。 RollbackRuleAttribute 持有某个异常的名称，通过 getDepth(Throwable ex) 算法来计算指定的 Throwable 和持有的异常在继承链上的距离。

  程序猿只有在拿到需求以后才能开工， TransactionInterceptor 也一样，有了 TransactionAttributeSource 之后就可以有依据的增强了。观察类图， TransactionInterceptor 实现了 MethodInterceptor 接口，那么自然要实现接口中的方法：

可以看到， TransactionInterceptor 本身是没有实现任何逻辑的，它更像一个适配器。这样分层以后， TransactionAspectSupport 理论上就可以支持任意类型的 Advice 而不只是 MethodInterceptor 。实现上 TransactionAspectSupport 确实也考虑了这一点，我们马上就会看到。

invokeWithinTransaction(...) 的流程还是非常清晰的：

第一步前文已经分析过了，我们来看第二步。

TransactionInfo 是一个非常简单的类，我们就不费什么笔墨去分析它了。接着看第三步，这一步涉及到两个不同的操作——提交或回滚。

至此， TransactionInterceptor 于我们而言已经没有任何秘密了。

  本篇我们一起分析了 spring-tx 是如何通过 spring-aop 的拦截器将普通方法增强为事务方法的，下篇就该说道说道 PlatformTransactionManager 抽象下的事务管理细节啦，我们下篇再见~~

⑹ 如何用python解析网页并获得网页真实的源码

可以去了解下python如何调用webkit的引擎，你说的那种不是用js加密，只是用js动态加载页面内容。必须用webkit之类的浏览器引擎去渲染。

⑺ 求一个单页网站源码！要纯静态的！越简单越好，

纯静态、简单得不能再简单，请Ctrl+C：

<html>
<title>单页网站源码</title>
<body>这是一个单页网站源码</body>
</html>

⑻ mina 源码解析（1）

mina是一款网络应用框架， 它是基于java nio 的 通讯框架， 提供抽象的事件驱动异步的api。

mina 基本架构:

大致上分为三层IoSerivce, Filter, Handler

首先我们来看一下Filter

前面说过， mina 是基于事件驱动的， 所以我们先来看一下mina定义了那些事件：
IoEventType 类中定义了如下枚举变量：

这些事件对于用户使用者来说无需关心。
以上IoEventType仅是事件的类型（事件的属性）， mina对于事件是通过IoEvent对象进行封装的。
来看一下IoEvent 都有哪些方法：

我们看到IoEvent 实现了Runnable，也就是说这个对象会交给多线程去执行run方法。
在run方法中我们看到执行的是fire(), 也就是具体的任务了。

下面来看一下fire中做的事情， 首先看以下IoEvent 中 具体做了哪些事情， 再看一下其子类IoFilterEvent又做了哪些事情。 后面我会讲IoFilterEvent 的作用是什么， 在哪里用到。

其实做的事情就是触发（调用） session下filterchain的对应事件类型的方法。

IoFilterEvent 是IoEvent 的子类， 从名字就可以看出来， 其与IoFilter 有一定的关系， 所以IoFilterEvent是由IoFilter 产生的事件。
而IoFilter 产生的事件有什么特性呢？

在此插入IoFilter与IoFilterChain 的介绍。

IoFilter 是 拦截处理事件的过滤器， 如同servlet的filter。 它可以用于很多目的:
日志记录， 性能测量， 认证等等。

而filterchain 即代表一串IoFilter的链子， 其有多个IoFilter 组成。 事实上，在IoFilterChain 中，封装了一层Entry, 每个Entry中封装了当前的IoFilter和下一个IoFilter的引用。 可以看到Entry的接口如下

NextFilter 顾名思义， 即下一个IoFilter, 为什么需要有这么一个接口呢？

事实上， 我们可以想象， nextFilter 是用来 触发 下一个Iofilter的，其并不是IoFilter， 在IoFilter中， 我们可以看到这样的调用

说完了IoFilter, IoFilterChain, 那与IoFilterEvent有什么关系呢？
因为是IoFilter产生的事件， 当触发这个事件时， 由于链式的特征， 该事件将触发当前IoFilter 以后的Filter, 所以我们看到， IoFilter fire()的实现其实就是调用下一个filter的对应的事件方法：

也可以这样理解， 一个事件的产生， 产生地就是头， 事件从当前头向链后传播。
IoEvent 做的是从chain 的开头往后传播， IoFilterEvent是由当前IoFilter产生往后传播。

说完了IoFilter， 来探讨一下如何将IoFilter组装成IoFilterChain:

其实里面的结构就是链表。
来看看chain中add的内容：

⑼ Feign源码解析二

本文会基于Feign源码，看看Feign到底是怎么实现远程调用

上文中，我们的 user-service 服务需要调用远程的 order-service 服务完成一定的业务逻辑，而基本实现是order-service提供一个spi的jar包给user-service依赖，并且在user-service的启动类上添加了一个注解

这个注解就是@EnableFeignClients，接下来我们就从这个注解入手，一步一步解开Feign的神秘面纱

该注解类上的注释大概的意思就是：
扫描那些被声明为 Feign Clients (只要有 org.springframework.cloud.openfeign.FeignClient 注解修饰的接口都是Feign Clients接口)的接口

下面我们继续追踪源码，看看到底什么地方用到了这个注解
利用IDEA的查找调用链快捷键，可以发现在.class类型的文件中只有一个文件用到了这个注解

OK，下面主要就是看这个类做了什么

通过UML图我们发现该类分别实现了 ImportBeanDefinitionRegistrar ， ResourceLoaderAware 以及 EnvironmentAware 接口
这三个接口均是spring-framework框架的spring-context模块下的接口，都是和spring上下文相关，具体作用下文会分析

总结下来就是利用这两个重要属性，一个获取应用配置属性，一个可以加载classpath下的文件，那么FeignClientsRegistrar持有这两个东西之后要做什么呢？

上面将bean配置类包装成 FeignClientSpecification ，注入到容器。该对象非常重要，包含FeignClient需要的 重试策略 ， 超时策略 ， 日志 等配置，如果某个FeignClient服务没有设置独立的配置类，则读取默认的配置，可以将这里注册的bean理解为整个应用中所有feign的默认配置

由于 FeignClientsRegistrar 实现了 ImportBeanDefinitionRegistrar 接口，这里简单提下这个接口的作用
我们知道在spring框架中，我们如果想注册一个bean的话主要由两种方式：自动注册/手动注册

知道了 ImportBeanDefinitionRegistrar 接口的作用，下面就来看下 FeignClientsRegistrar 类是何时被加载实例化的

通过IDEA工具搜索引用链，发现该类是在注解@EnableFeignClients上被import进来的，文章开始的图片中有

这里提下@Import注解的作用

该注解仅有一个属性value，使用该注解表明导入一个或者多个@Configuration类，其作用和.xml文件中的<import>等效，其允许导入@Configuration类，ImportSelector接口/ImportBeanDefinitionRegistrar接口的实现，也同样可以导入一个普通的组件类

注意，如果是XML或非@Configuration的bean定义资源需要被导入的话，需要使用@ImportResource注解代替

这里我们导入的FeignClientsRegistrar类正是一个ImportBeanDefinitionRegistrar接口的实现

FeignClientsRegistrar重写了该接口的 registerBeanDefinitions 方法，该方法有两个参数注解元数据 metadata 和bean定义注册表 registry

该方法会由spring负责调用，继而注册所有标注为@FeignClient注解的bean定义

下面看registerBeanDefinitions方法中的第二个方法，在该方法中完成了所有@FeignClient注解接口的扫描工作，以及注册到spring中，注意这里注册bean的类型为 FeignClientFactoryBean ，下面细说

总结一下该方法，就是扫描@EnableFeignClients注解上指定的basePackage或clients值，获取所有@FeignClient注解标识的接口，然后将这些接口一一调用以下 两个重要方法 完成 注册configuration配置bean 和注册 FeignClient bean

断点位置相当重要

BeanDefinitionBuilder definition = BeanDefinitionBuilder.genericBeanDefinition(FeignClientFactoryBean.class);

这里是利用了spring的代理工厂来生成代理类，即这里将所有的 feignClient的描述信息 BeanDefinition 设定为 FeignClientFactoryBean 类型，该类继承自FactoryBean，因此这是一个代理类，FactoryBean是一个工厂bean，用作创建代理bean，所以得出结论，feign将所有的 feignClient bean定义的类型包装成 FeignClientFactoryBean

最终其实就是存入了BeanFactory的beanDefinitionMap中

那么代理类什么时候会触发生成呢？ 在spring 刷新容器时 ，会根据beanDefinition去实例化bean，如果beanDefinition的beanClass类型为代理bean，则会调用其 T getObject() throws Exception; 方法生成代理bean，而我们实际利用注入进来的FeignClient接口就是这些一个个代理类

这里有一个需要注意的点，也是开发中会遇到的一个 启动报错点
如果我们同时定义了两个不同名称的接口 （同一个包下/或依赖方指定全部扫描我们提供的 @FeignClient ），且这两个 @FeignClient 接口注解的 value/name/serviceId 值一样的话，依赖方拿到我们的提供的spi依赖，启动类上 @EnableFeignClients 注解扫描能同时扫描到这两个接口，就会 启动报错

原因就是Feign会为每个@FeignClient注解标识的接口都注册一个以serviceId/name/value为key，FeignClientSpecification类型的bean定义为value去spring注册bean定义，又默认不允许覆盖bean定义，所以报错

官方提示给出的解决方法要么改个@FeignClient注解的serviceId，name，value属性值，要么就开启spring允许bean定义覆写

至此我们知道利用在springboot的启动类上添加的@EnableFeignClients注解，该注解中import进来了一个手动注册bean的 FeignClientsRegistrar注册器 ，该注册器会由spring加载其 registerBeanDefinitions方法 ，由此来扫描所有@EnableFeignClients注解定义的basePackages包路径下的所有标注为@FeignClient注解的接口，并将其注册到spring的bean定义Map中，并实例化bean

下一篇博文中，我会分析为什么我们在调用（@Resource）这些由@FeignClient注解的bean的方法时会发起 远程调用

⑽ 求个蓝奏云直连解析接口，或者是源码。

接口和源码我都有。

源码我不知道有没有用，因为没php环境，不过以前测试过是可以用的！

1，接口地址：放个图片你们自己看。

2，源码地址 ：就是上面这个接口的源码

<?php

functionMloocCurl($url,$method,$ifurl,$post_data){
$UserAgent='Mozilla/5.0(WindowsNT6.1;WOW64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/63.0.3239.132Safari/537.36';#设置ua
$curl=curl_init();
curl_setopt($curl,CURLOPT_URL,$url);
curl_setopt($curl,CURLOPT_USERAGENT,$UserAgent);
curl_setopt($curl,CURLOPT_SSL_VERIFYPEER,false);
curl_setopt($curl,CURLOPT_SSL_VERIFYHOST,false);
curl_setopt($curl,CURLOPT_RETURNTRANSFER,1);
if($method=="post"){
curl_setopt($curl,CURLOPT_REFERER,$ifurl);
curl_setopt($curl,CURLOPT_POST,1);
curl_setopt($curl,CURLOPT_POSTFIELDS,$post_data);
}
$response=curl_exec($curl);
curl_close($curl);
return$response;
}
if(!empty($_GET['url'])){
$url=$_GET['url'];
#第一步
$ruleMatchDetailInList="~ifr2"sname="[sS]*?"ssrc="/(.*?)"~";
preg_match($ruleMatchDetailInList,MloocCurl($url,null,null,null),$link);
$ifurl="https://www.lanzous.com/".$link[1];
#第二步
$ruleMatchDetailInList="~=s'(.*?)';[Ss]*?=s'(.*?)'[Ss]*?=s'(.*?)'[Ss]*?=s'(.*?)'~";
preg_match($ruleMatchDetailInList,MloocCurl($ifurl,null,null,null),$segment);
#第三步
#post提交的数据
$post_data=array(
"action"=>$segment[1],
"file_id"=>$segment[2],
"t"=>$segment[3],
"k"=>$segment[4]
);
$obj=json_decode(MloocCurl("https://www.lanzous.com/ajaxm.php","post",$ifurl,$post_data));#json解析
if($obj->dom==""){#判断链接是否正确
echo"链接有误！";
}else{
$downUrl=$obj->dom."/file/".$obj->url."/&type=down/";
if(!empty($_GET['type'])){
$type=$_GET['type'];
if($type=="down"){
header('Location:'.$downUrl);#直接下载
}else{
header('Location:'.$downUrl);#直接下载
}
}else{
header('Location:'.$downUrl);#直接下载
}
}
}else{
$result_url=str_replace("index.php","","//".$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']."");
echo"蓝奏云直连下载";
echo"<br/>";
/*echo"直接下载："."<ahref='".$result_url."&type=down'target='_blank'>".$result_url."&type=down</a>";
echo"<br/>";
echo"输出直链："."<ahref='".$result_url."'target='_blank'>".$result_url."</a>";*/
}
?>