这一行：
[self dismissViewControllerAnimated:YES completion:nil];
不是向自己发送消息，它实际上是向其呈现的 VC 发送消息，要求它进行解雇。当你呈现一个 VC 时，你在呈现的 VC 和被呈现的 VC 之间创建了一种关系。所以你不应该在呈现的时候破坏正在呈现的 VC（呈现的 VC 不能发回驳回消息……）。由于您没有真正考虑到它，因此您使应用程序处于混乱状态。请参阅我的答案Dismissing a Presented View Controller
我建议在其中更清楚地编写此方法：
[self.presentingViewController dismissViewControllerAnimated:YES completion:nil];
在您的情况下，您需要确保所有控制都在mainVC . 您应该使用委托将正确的消息从 ViewController1 发送回 MainViewController，以便 mainVC 可以关闭 VC1，然后呈现 VC2。
在VC2 VC1 中，在 @interface 上方的 .h 文件中添加协议：
@protocol ViewController1Protocol <NSObject>
- (void)dismissAndPresentVC2;
@end
并在@interface 部分的同一文件中向下声明一个属性来保存委托指针：
@property (nonatomic,weak) id <ViewController1Protocol> delegate;
在 VC1 .m 文件中，关闭按钮方法应该调用委托方法
- (IBAction)buttonPressedFromVC1:(UIButton *)sender {
[self.delegate dissmissAndPresentVC2]
}
现在在 mainVC 中，在创建 VC1 时将其设置为 VC1 的委托：
- (IBAction)present1:(id)sender {
ViewController1* vc = [[ViewController1 alloc] initWithNibName:@"ViewController1" bundle:nil];
vc.delegate = self;
[self present:vc];
}
并实现委托方法：
- (void)dismissAndPresent2 {
[self dismissViewControllerAnimated:NO completion:^{
[self present2:nil];
}];
}
present2:VC2Pressed:可以是与您的按钮 IBAction 方法相同的方法。请注意，它是从完成块调用的，以确保在 VC1 完全关闭之前不显示 VC2。
您现在正在从 VC1->VCMain->VC2 移动，因此您可能只希望对其中一个过渡进行动画处理。
更新
在您的评论中，您对实现看似简单的事情所需的复杂性表示惊讶。我向你保证，这种委托模式对于大部分 Objective-C 和 Cocoa 来说都是如此重要，而且这个例子是你能得到的最简单的例子，你真的应该努力适应它。
在 Apple 的View Controller Programming Guide中，他们这样说：
关闭呈现的视图控制器
当需要关闭呈现的视图控制器时，首选方法是让呈现的视图控制器关闭它。换句话说，只要有可能，呈现视图控制器的同一个视图控制器也应该负责解除它。尽管有几种技术可以通知呈现视图控制器其呈现的视图控制器应该被解除，但首选技术是委托。有关详细信息，请参阅“使用委托与其他控制器通信”。</p>
如果您真的仔细考虑了您想要实现的目标，以及您将如何实现它，您将意识到发送您的 MainViewController 来完成所有工作是唯一合乎逻辑的出路，因为您不想使用 NavigationController。如果您确实使用了 NavController，那么实际上您是在“委托”（即使没有明确地）给 navController 来完成所有工作。需要有一些对象来集中跟踪您的 VC 导航发生的事情，并且无论您做什么，您都需要某种与之通信的方法。
在实践中，Apple 的建议有点极端......在正常情况下，您不需要创建专门的委托和方法，您可以依赖[self presentingViewController] dismissViewControllerAnimated:它 - 在像您这样的情况下，您希望您的解雇对远程产生其他影响你需要照顾的对象。
这是您可以想象的无需所有代表麻烦的工作...
- (IBAction)dismiss:(id)sender {
[[self presentingViewController] dismissViewControllerAnimated:YES
completion:^{
[self.presentingViewController performSelector:@selector(presentVC2:)
withObject:nil];
}];
}
在要求呈现控制器解雇我们之后，我们有一个完成块，它调用 presentingViewController 中的一个方法来调用 VC2。不需要委托。（区块的一大卖点是它们在这些情况下减少了对代表的需求）。然而，在这种情况下，有一些事情会阻碍......
- 在 VC1 中，您不知道mainVC 实现了该方法
present2- 您最终可能会遇到难以调试的错误或崩溃。代表可以帮助您避免这种情况。
- 一旦 VC1 被解散，它就不会真正执行完成块......或者是吗？self.presentingViewController 还有什么意义吗？你不知道（我也不知道）……有了代表，你就没有这种不确定性。
- 当我尝试运行此方法时，它只是挂起，没有警告或错误。
所以请...花时间学习代表团！
更新2
在您的评论中，您已经设法通过在 VC2 的关闭按钮处理程序中使用它来使其工作：
[self.view.window.rootViewController dismissViewControllerAnimated:YES completion:nil];
这当然要简单得多，但它会给您带来许多问题。
紧密耦合
您将 viewController 结构硬连接在一起。例如，如果你要在 mainVC 之前插入一个新的 viewController，你需要的行为就会中断（你会导航到前一个）。在 VC1 中，您还必须 #import VC2。因此，您有很多相互依赖关系，这破坏了 OOP/MVC 目标。
使用委托，VC1 和 VC2 都不需要知道任何关于 mainVC 或其前身的信息，因此我们保持一切松散耦合和模块化。
内存
VC1 并没有消失，你仍然持有两个指向它的指针：
- mainVC的
presentedViewController属性
- VC2的
presentingViewController属性
您可以通过记录进行测试，也可以通过 VC2 执行此操作
[self dismissViewControllerAnimated:YES completion:nil];
它仍然有效，仍然可以让您回到 VC1。
在我看来，这就像内存泄漏。
这方面的线索是你在这里得到的警告：
[self presentViewController:vc2 animated:YES completion:nil];
[self dismissViewControllerAnimated:YES completion:nil];
// Attempt to dismiss from view controller <VC1: 0x715e460>
// while a presentation or dismiss is in progress!
当您试图关闭VC2 是呈现的 VC 的呈现 VC时，逻辑就会崩溃。第二条消息并没有真正被执行——好吧，也许发生了一些事情，但你仍然有两个指向你认为已经摆脱的对象的指针。（编辑 - 我已经检查过了，还不错，当你回到 mainVC 时，两个对象都会消失）
这是一种相当冗长的说法——请使用代表。如果有帮助，我在这里对模式进行了另一个简要描述：
在构造函数中传递控制器总是不好的做法吗？
更新 3
如果你真的想避免委托，这可能是最好的出路：
在 VC1 中：
[self presentViewController:VC2
animated:YES
completion:nil];
但是不要忽视任何事情......正如我们所确定的那样，无论如何它并没有真正发生。
在 VC2 中：
[self.presentingViewController.presentingViewController
dismissViewControllerAnimated:YES
completion:nil];
正如我们（知道）我们没有关闭 VC1，我们可以通过VC1回到MainVC。MainVC 关闭 VC1。因为 VC1 已经消失了，所以 VC2 也随之出现，所以你回到 MainVC 时处于一个干净的状态。
它仍然是高度耦合的，因为 VC1 需要了解 VC2，而 VC2 需要知道它是通过 MainVC->VC1 到达的，但它是最好的，没有一点明确的委托。