我有点不确定什么时候适合用来Html.RenderAction()渲染我的视图，什么时候不适合。我的理解是，因为它不是 ASP.NET MVC 的“官方”组件，所以使用它是不好的做法，它的初衷是用于任何特定控制器上下文中不存在的可重用小部件。
问题是，当我需要一个存在于与我当前为其渲染视图的控制器不同的控制器下的组件时，RenderAction 非常有用。我认为这是一种非常整洁且自包含的方式来呈现依赖于当前视图中不可用数据的组件。我的视图不需要提供模型，就像我使用的一样RenderPartial()
这是不好的做法吗？有没有更好的办法？
万一它解决了你的问题也没关系。
我认为这是一种非常整洁且自包含的方式来呈现依赖于当前视图中不可用数据的组件。我的视图不需要提供模型，就像我使用 RenderPartial()
它实际上是。例如，您可以创建一些小视图作为小部件并将它们注入您需要的任何地方。然而，处理来自这些小部件的用户输入可能会变得更加复杂，但这是另一个问题。
我能想到的另一种合法方案是使用 HTML 电子邮件模板。这是一种情况，您显然不需要将呈现的输出直接返回到浏览器，而是将其插入电子邮件正文。
我使用Html.RenderAction()您给出的原因，这样您就不必一遍又一遍地为需要显示用户信息的每个视图提供相同的数据（例如）。您可以争辩说它违反了 mvc 模式，因为视图现在知道控制器。但我认为这种情况下的优势超过了这一点，您的应用程序将更加干燥。
我只是将它用于我需要在许多不同地方重用的所有内容（例如，我在母版页的每个页面上显示的用户数据）并且我不想将该信息显式发送到每个视图。如果我没记错的话，我认为他们也将它包含在 asp.net mvc 2 中，所以它现在是框架的一部分。
根据父视图模型的结果，我找到了在场景中使用 Html.RenderAction 的充分理由。例如，父视图的模型有一个必须显示在表格中的 List 属性。但是，为了防止父视图中出现条件 IF/ELSE，我调用了 Html.RenderAction()。该操作在列表中进行并检查计数。如果计数为零，则返回“无结果”视图；否则，它会返回一个视图，该视图以自己的模型形式处理 List 中的项目。通过防止在视图中插入逻辑，这更清晰。我还可以在我的应用程序的其他区域重用“无结果”视图。