最开始使用一个for循环用requests请求15个url链接
用了线程池提交多任务还有必要在单个任务里用异步协程吗？
个人理解：用线程池和用异步协程冲突吗？两个效果好像差不多，
感觉异步协程的应用相对于同步操作而言的，而线程池可以提交很多任务，由多线程去完成。可以不可以把请求url链接这种阻塞状态的操作用异步操作，而把爬取数据的任务（里面包含了请求url）抽象为一个个单元提交给线程池，从而极大提高效率。
但是转念一想，线程池就是多线程去拿任务，而且有先后类似异步的操作（我想总不可能是几十个线程同时一起请求各自拿到任务里面的url吧！），如果不是同时那就跟异步协程的效果是一样的，那么请求url操作用异步协程会不会多余？
感觉不是同时的，因为在测试中，提交的任务完成的有先有后，T(为啥LS这个词不能用？！)讲异步协程是以单线程多任务为例的，那么我线程池把线程开多一点，理想状态一个线程拿一个任务（包含请求url），那么异步协程效率是提升不了多少的（而且写的麻烦），一定程度上来讲两者一样的（所以T是以单线程多任务为例的）。不知道理解的正不正确
我认为没必要，两者之间选一即可。线程较重，协程较轻。如果用线程池，那么任务通过线程池上传后，就独占此线程直至任务结束；如果用协程，那就必定有一个线程作为 looper，并在 looper 线程上切换任务，如果任务进入 await 阶段，这个线程可以腾出手来接管其他的协程。
那什么时候适合用协程呢？我认为就是当任务量非常大，并发数非常高且 I/O 任务居多时，协程的真正优势才体现出来。线程的切换也是有开销的，然而协程的切换开销更小；此外，如果任务经常长时间阻塞（例如发送网络请求），光靠线程池的话，池中的线程也会有被用完的场景，而协程就没有这一点的缺陷。