首先说明需求点：依次发起请求op1、op2、op3，要求op1成功后再发起op2，若失败，则后续op2、op3不执行，回调失败结果；同理，若op1成功后，发起op2请求失败，则op3不执行，回调失败结果。
最终参考代码：Demo
先看一段网络常见示例：
网上常见示例
从结果上看，满足请求的顺序执行，但是实际使用后，情况变得不一样了：
实际使用结果
从结果日志上看，op2并未等待op1请求结束后再发起，这就导致了无法根据op1的请求结果来判断op2是否能够发起，这就无法实现文章开始提到的效果。
修改方案：使用信号量来控制线程的执行：
信号量实现方案
信号量请求结果
从请求结果看，这个已经满足了使用需求，但是这并没有结束，出现的主线程死锁。
主线程死锁
从结果可以看到，因为requestAction的回调是在主线程中执行的，而此时主线程又在等待回调后的信号量以继续执行，从而形成了死锁，更有甚者，如果UI上存在动画或者loading的，此时也会卡死。
那么这种情况下改如何处理？
解决方法：
避免将dispatch_semaphore_wait() 放置于主线程中，而是放置到对应的子线程中进行，最终修改后的代码：
Final
总结：原本不是复杂的场景，但是因为加入了线程的操作而容易出现错误，这个方案只是在遇到这个小问题的记录，如果您有更好的办法能够实现这个场景，欢迎您留言！
