其中:
get_header负责随机产生请求头部。get_proxy负责获取代理。
将此前多个写方法，封装为csvWriter类。其中:
__init__可以根据检索或获取转发关系，生成不同的csv头部字段，并调用create_csv。create_csv负责产生文件并写入头部。write_csv负责将爬取到的数据，不断追加入文件。get_idList负责获取将要爬取转发关系的下一组微博的id列表。merge_csv负责处理整合多个csv文件并去重。
其中：
word_get_query。负责生成相应日志。get_Topic。解析页面返回的每条微博的text，获取话题。get_Text。解析页面返回微博，对text进行格式处理。get_Page。获取该检索词相关的微博页数，利于之后爬取。get_query_info。基于检索词发送请求，解析检索页面。
其中：
word_repost_relationship。多进程爬取时，用于生成日志和中间文件以及相应的断点处理。get_repost_relationship。爬取转发关系的主逻辑函数。进行多层爬取，每层需要：- 读取将要爬取的微博id列表
- 对于其中每个id，调用
get_repost_info - 处理该层得到的下一组要爬取微博id的写入。
get_origin_info。获取原博的相关信息，辅助get_repost_info。get_repost_info。基于每条相关微博id发送请求，解析该微博页面获取转发信息。checkLevel。用于处理转发关系紊乱问题。
根据输入的检索词，到微博话题页面检索所有相关话题，将得到的话题列表写入话题文件。
为之后断点续存问题作准备。
负责根据进程名生成每个进程对应的目录。
负责获取用户设置：
- 日志存储路径
log_dir - 检索词相关微博存储路径
hot__dir。 - 转发关系信息存储路径
repost_dir。 - 检索词列表
searchlist。可以列表形式传入，若为文件则设为文件名，将会进行相应的读取操作。 - 爬取转发关系时开启的进程数
process_num。 - 是否进行话题扩充
expand_topic。布尔型。 - 话题存储路径
topic_dir。此处话题指根据检索词扩充获得的话题，以csv文件存储。
- 对 searchList 中每一个词
- 获取微博检索页面中所有相关微博
- 对每条相关微博获取多层转发关系（多进程）
- 对 searchList 中每一个词进行话题扩充。用 EPOCH 记录迭代次数。将每一轮迭代得到的扩充话题输出到用EPOCH 次数标记的文件，下一轮迭代的searchList从此文件中读出。
- 根据用户名获取所有微博，并对每条微博获取多层转发关系。可用于之后研究特定大V的热门微博转发情况。
在爬取微博的直接转发关系时，原博的转发会混入间接转发的内容：
而按照当前的爬取逻辑，爬虫会将这些间接转发的内容当做直接转发的微博处理。
- 问题：同一条微博，同时属于多个转发层级
对于显示紊乱的微博，其在整一条转发链的每级爬取都会出现。
以A为原创微博为例，转发链为"A <-B <-C <-D <-E"。
若E为紊乱微博，则在爬取A、B、C、D时都会出现该紊乱微博，则爬虫会将E分别处理为第1、2、3、4层转发，即其与B（直接转发A）、C、D同层，最后才将其记录为D的直接转发。
注：整条转发链上的其它微博也会重复记录（即以上例子中C、D两条微博也是紊乱微博，会被多次记录）
-
体现1：爬取A、B、C直接转发时，对应字段会反复出现这条微博
[例子]
其转发数据显示如下（实际上应取最后一层）：
-
体现2：将爬取紊乱微博的转发关系时，level各不相同。实际上，仅最高level为正确的层数。
对于“无为李爷”发布于7月19日的微博：
爬取到“三观不正向前冲”为一级转发，但浏览其微博发现其是间接转发：
这似乎是典型的转发紊乱问题，则在爬取数据中应当存在“帝吧小帅帅”的转发微博，但却没有找到相关数据，而在“无为李爷”微博的评论区域却发现了这条内容：
可见，对于转发紊乱问题的判断，不能仅仅通过转发微博内容中所含“//@”个数来判断层级，而仍是需要根据最高爬取层级来进行判断。
