ASP.NET Core中的URL重写是通过Rewrite中间件在请求处理前修改URL的技术，用于优化SEO、提升用户体验、实现HTTPS重定向及旧链接兼容。通过AddRedirect、AddRewrite等方法可配置重定向和内部重写规则，自定义IRule还可实现基于请求头等复杂逻辑，需注意中间件顺序、正则效率与重定向循环问题。
ASP.NET Core中的URL重写，简单来说，就是一种在服务器端修改传入请求URL的技术，在请求被ASP.NET Core应用程序处理之前，我们就可以对它进行“变脸”。它允许我们改变用户在浏览器地址栏看到的URL，或者在内部将一个URL映射到另一个URL，而用户可能对此毫无察觉。这对于维护网站的良好结构、优化搜索引擎（SEO）以及提供更友好的用户体验至关重要。
在ASP.NET Core中设置URL重写，我们主要通过内置的中间件来实现。这个中间件提供了一套灵活的API，让我们能够定义各种重写规则。
首先，确保你的项目引用了 NuGet包。通常，它在ASP.NET Core项目中是默认包含的，但如果遇到问题，可以手动添加。
接下来，你需要在应用的启动配置中（通常是的方法，或者在.NET 6+的中）注册并配置这个中间件。重写中间件应该在处理静态文件、认证、授权和路由等其他中间件之前被调用，因为它需要首先修改传入的URL。
以下是一个基本的配置示例：
在这个例子中：
- 是一个非常方便的方法，它会捕获所有非HTTPS请求，并以301（永久重定向）状态码将其重定向到HTTPS版本。这对于网站的安全性至关重要。
- 定义了一个从（可选地包含或不包含斜杠）到的永久重定向。状态码告诉浏览器和搜索引擎这个改变是永久的。
- 则是一个内部重写规则。当用户访问这样的URL时，服务器会在内部将其处理为，但用户在浏览器地址栏看到的仍然是。参数表示这是一个而不是。
你可以根据自己的需求添加更多的、甚至自定义规则。记住，这些规则是按照它们在中添加的顺序进行处理的，所以规则的顺序有时会非常关键。
说实话，我个人觉得URL重写在现代Web开发中几乎是不可或缺的。它不只是一个“锦上添花”的功能，而是解决了一系列实实在在的问题。
首先，从搜索引擎优化（SEO）的角度来看，简洁、语义化的URL对排名有着直接的影响。一个URL像肯定比更容易被搜索引擎理解和索引。URL重写能帮助我们把那些由底层框架或数据库结构生成的复杂、参数堆砌的URL，转换成对用户和搜索引擎都友好的形式。这就像给你的网站穿上了一件更体面、更易识别的外衣。
其次，它极大地提升了用户体验。试想一下，如果你想分享一个产品链接给朋友，是复制一个干净利落的短链接好，还是一个长串的、充满问号和等号的链接好？显然是前者。而且，用户更容易记住和手动输入一个结构化的URL。当网站进行改版或内容迁移时，旧的链接很容易失效，导致大量的404错误。通过URL重写，我们可以将这些旧链接优雅地重定向到新位置，避免用户遇到“死胡同”，这对于网站的信誉和用户留存至关重要。我以前就遇到过网站改版后大量旧链接失效，用户抱怨连连的情况，那时候URL重写简直是救命稻草。
再者，安全性也是一个不容忽视的方面。强制HTTPS就是最典型的应用。通过，我们可以确保所有流量都通过加密连接传输，这不仅保护了用户数据，也是现代网站的基本要求。
最后，它在技术维护和灵活性方面提供了巨大帮助。比如，你可以用它来处理A/B测试的流量分发，或者在不改变后端代码的情况下，为某些特定用户或请求头提供不同的内容。这给了开发者在不触及核心业务逻辑的情况下，调整网站行为的能力。
这是一个经常让人混淆的问题，但理解它们之间的差异和协作方式非常关键。在我看来，它们就像流水线上的两个不同但紧密合作的工位。
URL重写（URL Rewriting）发生在请求处理的早期阶段，它主要关注的是修改传入的URL本身。你可以把它想象成一个“门卫”或者“翻译官”。当一个HTTP请求到达服务器时，URL重写中间件会首先检查这个请求的URL，并根据预设的规则对其进行潜在的修改。这个修改可以是内部的（用户在浏览器地址栏看不到变化），也可以是外部的（通过301/302重定向，用户浏览器地址栏会更新）。它的核心目标是改变请求的路径、查询字符串甚至协议，以便后续的组件能接收到一个“处理过”的URL。
而URL路由（URL Routing）则发生在重写之后，它的任务是将（可能已经被重写过的）URL映射到应用程序中的特定处理程序。路由是ASP.NET Core的核心功能之一，它决定了哪个控制器动作、哪个Razor Page或哪个Endpoint应该来响应这个请求。你可以把路由看作一个“调度员”，它根据URL的结构，将请求分发到正确的代码逻辑。
它们之间的协同工作是这样的：
- 用户在浏览器中输入或点击一个URL，比如。
- 请求到达ASP.NET Core应用。
- URL重写中间件首先介入。如果有一个规则将重定向到，那么这个重定向就会发生。用户浏览器会收到301响应，然后自动发起对的新请求。
- 假设现在请求的URL是（或者如果重写是内部的，请求的URL被内部修改为）。
- URL路由中间件接着介入。它会分析当前的URL（例如），并根据你定义的路由规则（比如或），找到对应的控制器动作或Razor Page来处理这个请求。
- 最终，找到的控制器动作或Razor Page执行业务逻辑，并返回响应。
所以，重写是预处理，它改变了请求的“面貌”；路由是分发，它决定了请求的“去向”。它们各司其职，共同确保了请求能被正确、高效地处理。
在URL重写这个领域，虽然它功能强大，但如果不小心，也容易踩坑。我个人在处理一些复杂的重写规则时，就遇到过不少头疼的问题。
一个最常见的陷阱就是中间件的顺序问题。我在前面提过，重写中间件的放置位置至关重要。如果它被放在了静态文件中间件之后，那么对静态文件的重写规则可能就不会生效。同样，如果它在认证或授权中间件之后，那么这些中间件可能已经处理了原始的URL，而不是你期望的重写后的URL。这种顺序错误往往很难调试，因为表面上看起来一切正常，但就是达不到预期效果。解决办法就是：重写规则通常要尽可能地放在请求管道的前面。
正则表达式的复杂性和效率是另一个需要警惕的地方。虽然正则表达式提供了极大的灵活性，但编写不当的正则表达式可能会导致性能瓶颈，尤其是在高并发的场景下。一个过于宽泛或效率低下的正则，可能会对每个传入请求都进行大量的计算。我曾经写过一个正则，因为一个微小的疏忽，导致它在某些情况下匹配了不该匹配的URL，进而引发了意想不到的重定向循环。所以，测试你的正则表达式，并尽量让它们精确且高效，是基本功。
无限重定向循环也是一个非常危险的陷阱。这通常发生在重写规则相互冲突或逻辑不严谨时。例如，你可能有一个规则将重定向到，而另一个规则又将重定向回，这就会导致浏览器陷入无限循环，最终报错。调试这种问题需要耐心，通常需要仔细检查所有相关的重写规则，并确保它们不会形成闭环。
从性能考量的角度看，每一次重写操作都会增加一点点的处理开销。对于大多数应用来说，这点开销微不足道。但如果你的网站有数以万计的重写规则，或者你的正则表达式非常复杂，那么累积起来的开销就可能变得显著。此外，HTTP缓存也会受到重写的影响，尤其是永久重定向（301）。浏览器和CDN会长时间缓存301重定向，这意味着如果你改变了一个301规则，用户可能需要很长时间才能看到更新。对于临时重定向（302），缓存行为则不同，它通常不会被永久缓存。因此，选择正确的重定向状态码非常重要。
最后，调试重写规则有时会很棘手。ASP.NET Core的日志系统可以帮助你，但你可能需要添加自定义日志来追踪重写中间件的具体行为。我发现最好的办法是先在本地用少量、简单的规则进行测试，逐步增加复杂性，并利用像Regex101这样的在线工具来测试正则表达式。
当内置的或方法无法满足你的需求时，ASP.NET Core的重写中间件提供了更高级的扩展点：实现自定义的接口。这为我们打开了基于请求头、Cookie、查询参数甚至外部数据源等任意自定义逻辑进行重写的大门。
要实现自定义规则，你需要创建一个类，实现接口，并实现其方法。在这个方法中，你可以完全掌控请求的上下文，并决定是否进行重写或重定向。
这是一个基于请求头进行重写的例子：
然后，在（或）中注册这个自定义规则：
在这个中，我们：
- 在构造函数中传入了移动版路径（例如）和需要排除的路径（例如），避免重定向循环或不必要的重定向。
- 在方法中，我们首先检查当前请求是否已经位于移动版路径或排除路径，如果是则直接返回，不进行任何操作。
- 接着，我们通过来获取用户代理信息，判断是否为移动设备。
- 如果判断为移动设备，我们构建一个新的URL，将原始路径前加上，并保留查询字符串。
- 最后，通过设置重定向结果，并手动设置头和。这里使用302（临时重定向），因为用户可能希望在桌面设备上访问完整版网站。
这种自定义规则的强大之处在于，你可以访问中的，这意味着你可以检查几乎所有请求相关的属性：、、、，甚至是。你可以根据这些信息编写非常精细和复杂的逻辑，比如：
- 根据特定的Cookie值重定向到A/B测试页面。
- 根据请求的头重定向到不同的语言版本站点。
- 根据外部API的响应来决定是否重写或重定向。
这种灵活性使得URL重写不仅仅是路径映射，更成为了一个强大的请求预处理工具。当然，随着复杂度的增加，测试和维护的难度也会相应提高，所以务必做好充分的单元测试和集成测试。
以上就是ASP.NET Core中的URL重写是什么？如何设置？的详细内容，更多请关注php中文网其它相关文章！
