为了解释我面临的问题，我有2条路线：cmd.StartInfo.FileName = "net";
cmd.StartInfo.Arguments = "share " + txt_shareName + "=" + path;
和ApplicationRoute。在尝试使用SomeRoute执行某些操作之前，我需要等待ApplicationRoute解析。
我在调试中看到的调用顺序：
SomeRoute我想要的是什么：
ApplicationRoute.model // which returns a promise
SomeRoute.model
SomeRoute.setupController
ApplicationRoute.setupController
可能有一个我在某个地方遗失的细节...
更新
我认为ApplicationRoute.model // which returns a promise
ApplicationRoute.setupController
SomeRoute.model
SomeRoute.setupController
能够在其他路线之前能够使用它来初始化其他路由器的原因。
ApplicationRoute.setupController答案 0 :(得分：1)
要继续转换，层次结构中的所有模型都必须解析。应该是这样的;我们不想开始做应用程序逻辑 - 其中包括可能在setupController中在层次结构的任何级别完成的事情 - 而必要的模型仍处于待决状态且转换尚未完成最终确定甚至可能会中止。
因此，如果我们同意模型以自上而下的顺序解决，这是有道理的 - 毕竟，子路由的model挂钩可能想要引用this.modelFor('parent') - 为什么setupController从下往上以相反的顺序调用？我猜这可能有很好的理由，包括渲染生命周期，但从一个重要的意义上说它并不重要：正确设置父路径的控制器并不是先决条件。要建立子路由的控制器。父路由的控制器甚至不能直接从子路由的控制器访问，除非您注入它。有关此主题的更多信息，请参阅http://discuss.emberjs.com/t/why-is-setupcontroller-called-after-the-model-hook-of-nested-routes/2655/9。
顺便说一句，你使用表达式＆＃34;一个路由解析＆＃34;，并且似乎暗示调用setupController是该解析过程的一部分，但是引用更为正确＆＃34;路线的模型解析＆＃34;，并且不包括setupController的调用，这是之后发生的事情路线链中的所有模型都已解决，最终确定了转型。
在您的问题更新中显示的特定情况下，请考虑将setupController逻辑放在afterModel挂钩中。从逻辑上讲，您在setupController中所做的不是设置控制器;它操纵和处理模型，因此属于其中一个模型钩子。