Controller未触发排查：Post请求正常但断点未命中的原因

Alright, let's dig into why your POST action breakpoints aren't hitting even though you're sure the request is correct. Based on your code and common ASP.NET MVC pitfalls, here are the most likely causes to investigate:

1. Model Binding Mismatch (The Most Likely Culprit) #

Looking at your Razor views, you're using AdminViewModel as the model. When you render fields like @Html.TextBoxFor(m => m.Client.client_id), the generated HTML input will have a name attribute of Client.client_id (not just client_id).

But your controller actions accept a Client parameter directly (e.g., public ActionResult Delete(Client client)). ASP.NET MVC's model binder looks for request values named client_id, Days, etc.—not nested under Client.. Since it can't find those values, either:

• The action isn't matched at all (hence no breakpoint hit), or
• The Client parameter is instantiated with default values (like client_id = 0), which might make your logic fail silently.

Fixes:

• Update your action parameters to accept AdminViewModel instead, then access model.Client:

  [HttpPost]
  public ActionResult Delete(AdminViewModel model)
  {
      int clientId = model.Client.client_id;
      // Rest of your logic...
  }
  

• Or use the [Bind(Prefix = "Client")] attribute to tell the model binder to look for nested values:

  [HttpPost]
  public ActionResult Delete([Bind(Prefix = "Client")]Client client)
  {
      // Your existing logic should work now
  }
  

• Alternatively, override the name attribute in your Razor helpers to match the Client model's properties directly:

  @Html.TextBoxFor(m => m.Client.client_id, new { @Name = "client_id", @Value = client.client_id, @class = "hidden" })
  

2. Missing Anti-Forgery Validation (If Enabled Globally) #

If you've registered [ValidateAntiForgeryToken] as a global filter (in Global.asax or FilterConfig.cs), your POST requests will be rejected unless your forms include the anti-forgery token. None of your forms have @Html.AntiForgeryToken(), which would block the request before it reaches your action method.

Fix: Add @Html.AntiForgeryToken() inside each of your Html.BeginForm blocks, and decorate your POST actions with [ValidateAntiForgeryToken] (or remove the global filter if you don't need it).

3. Routing Configuration Conflicts #

Double-check your route configuration (in RouteConfig.cs). If you have a custom route that matches your POST requests before they reach the default {controller}/{action} route, it might direct the request to a different action (or none at all).

For example, a route like this could intercept requests meant for your delete/update actions:

routes.MapRoute(
    name: "Custom",
    url: "Clients/{id}",
    defaults: new { controller = "Clients", action = "Index" }
);

Fix: Ensure your default route is defined first, or adjust custom routes to avoid conflicting with your POST actions.

4. Authentication/Authorization (Breakpoints Should Still Hit) #

While your code checks Request.IsAuthenticated and User.IsInRole("Superuser"), failing these conditions would trigger a redirect—but your breakpoint should still hit the action method first. If it's not hitting at all, this isn't the root cause, but it's worth verifying you're logged in as a Superuser during testing.

5. Unreachable Code in ManualActiveAdd #

Your ManualActiveAdd action has an extra return View(); at the end that's unreachable (all prior code paths return a redirect or result). This won't cause a breakpoint issue, but removing it will clean up your code.

内容的提问来源于stack exchange，提问作者africantraplord