超过 1000 个 301 重定向会降低我的网站速度吗？
Will over 1000 301 redirects slow down my site?
我已经更新了我的站点链接以使用漂亮的 URL 而不是查询字符串。
Old URL: https://digimoncard.io/deck/?deckid=1241
New URL: https://digimoncard.io/deck/green-otk-1241
这两个 URL 都可以在没有 404 的情况下访问，但我计划像这样向我的 htaccess 添加 301 重定向：
RewriteEngine on
Redirect 301 https://digimoncard.io/deck/?deckid=1241 https://digimoncard.io/deck/green-otk-1241
我担心的部分问题是所需的重定向数量（正好是 1218）。由于必须在每次页面加载时查询其中的每一个，这是否会降低 site/server 的速度？
我的另一个解决方案是可能不理会它，让 google 索引新的 URL 和超时让查询字符串过时。
好吧，它可能会变慢，但不一定。如果您的 .htaccess 不包含 10k 或更多重定向，应该没问题。但在预防方面，您始终可以使用较小的文件并删除不必要的重定向并让 google 为 URL 编制索引。
您可以参考此link了解更多信息
https://www.matthewedgar.net/do-redirects-add-to-website-speed/#htaccessredirectsspeed
.htaccess 中的 1218 重定向指令不应导致 noticeable/significant 延迟，但是您的建议还有其他问题，这可以大大优化以避免任何额外开销...
...having to query each of these on every page load?
不仅仅是“每个页面加载”，而且可能 每个请求。所有静态资源（CSS、JS、图像等）都将触发同一组指令（除非它们远离应用程序服务器托管）。
RewriteEngine on
Redirect 301 https://digimoncard.io/deck/?deckid=1241 https://digimoncard.io/deck/green-otk-1241
这行不通。 mod_alias Redirect 指令只匹配 URL 路径，它不匹配查询字符串（或方案+主机名），所以上面的指令将简单地匹配失败并且什么都不做。 （RewriteEngine 也是 mod_rewrite 的一部分，而不是 mod_alias。）
为了匹配查询字符串，您需要使用 mod_rewrite 和额外的 条件 来检查 QUERY_STRING 服务器变量。例如：
RewriteCond %{QUERY_STRING} ^deckid=(1241)$
RewriteRule ^deck/$ /green-otk-%1 [R=301,L]
%1 反向引用包含 1241（从前面的 CondPattern 中捕获）——这只是避免了重复（可能会引入错误）。当然，除非您自动生成这些指令。
不要使用 .htaccess - 请改用您的应用程序逻辑
但是，理想情况下，您一开始就不会在 .htaccess 中进行这些重定向。在您的应用程序逻辑中执行这些操作要好得多（理想情况下，当您的站点确定结果会触发 404 时——尽管在您的情况下不会发生这种情况）。通过将这些指令放在 .htaccess 中，您将以牺牲正常站点流量为代价来确定“重定向”的优先级。通过实施这些重定向 later（在您的应用程序中），您可以优先考虑正常的网站流量。
因为我假设您正在使用前端控制器来路由您的 URL，所以这应该相对容易实现。 （您仅在收到与旧 URL 格式匹配的请求时才处理重定向逻辑。）
优化的 .htaccess 版本
但是，如果您决定走 .htaccess 路线，如果您所有的旧 URL 都遵循相同的格式，那么您可以极大地优化它...您可以在内部重写任何使用该格式的请求/deck/?deckid=<number> 到一个子目录（假设你所有的旧 URL 都使用这种格式）。然后，您在处理所有 1218 重定向的子目录中有另一个 .htaccess 文件。这样，您的主 .htaccess 文件中只有一个指令，每个请求都会处理该指令，并且仅在需要时才处理重定向逻辑（在子目录 .htaccess 文件中）。
这避免了在 .htaccess 主文件中包含 1000 多个重定向指令的开销。
子目录 .htaccess 文件中的指令也可以简化，因为我们可以重写将查询字符串移动到 URL 路径的请求，以避免额外的 条件 稍后。
例如，在根 .htaccess 文件的顶部：
RewriteEngine On
# Internally rewrite the request for (what looks like) an old URL
# ...to the "/redirect-old" subdirectory
RewriteCond %{QUERY_STRING} ^deckid=(\d+)$
RewriteRule ^deck/$ redirect-old/%1 [L]
/deck/?deckid=<number> 形式的所有 URL 都在内部重写为 /redirect-old/<number>...
然后，在 /redirect-old/.htaccess 中，您有 简化的 “重定向”指令，如下所示，与 rewritten URL:
# /redirect-old/.htaccess
RewriteEngine On
# Redirect old URLs
RewriteRule ^1241$ /deck/green-otk-[=13=] [R=301,L]
RewriteRule ^1234$ /deck/foo-[=13=] [R=301,L]
RewriteRule ^4321$ /deck/bar-[=13=] [R=301,L]
:
这些指令与重写的 URL 匹配，即。 /redirect-old/<number> 并相应地重定向。
在每种情况下，[=35=] 反向引用只是与 RewriteRule 匹配的 URL-路径（即 number） 模式。 （保存重复 - 如上所述。）
我已经更新了我的站点链接以使用漂亮的 URL 而不是查询字符串。
Old URL: https://digimoncard.io/deck/?deckid=1241
New URL: https://digimoncard.io/deck/green-otk-1241
这两个 URL 都可以在没有 404 的情况下访问，但我计划像这样向我的 htaccess 添加 301 重定向：
RewriteEngine on
Redirect 301 https://digimoncard.io/deck/?deckid=1241 https://digimoncard.io/deck/green-otk-1241
我担心的部分问题是所需的重定向数量（正好是 1218）。由于必须在每次页面加载时查询其中的每一个，这是否会降低 site/server 的速度？
我的另一个解决方案是可能不理会它，让 google 索引新的 URL 和超时让查询字符串过时。
好吧，它可能会变慢，但不一定。如果您的 .htaccess 不包含 10k 或更多重定向，应该没问题。但在预防方面，您始终可以使用较小的文件并删除不必要的重定向并让 google 为 URL 编制索引。
您可以参考此link了解更多信息
https://www.matthewedgar.net/do-redirects-add-to-website-speed/#htaccessredirectsspeed
.htaccess 中的 1218 重定向指令不应导致 noticeable/significant 延迟，但是您的建议还有其他问题，这可以大大优化以避免任何额外开销...
...having to query each of these on every page load?
不仅仅是“每个页面加载”，而且可能 每个请求。所有静态资源（CSS、JS、图像等）都将触发同一组指令（除非它们远离应用程序服务器托管）。
RewriteEngine on Redirect 301 https://digimoncard.io/deck/?deckid=1241 https://digimoncard.io/deck/green-otk-1241
这行不通。 mod_alias Redirect 指令只匹配 URL 路径，它不匹配查询字符串（或方案+主机名），所以上面的指令将简单地匹配失败并且什么都不做。 （RewriteEngine 也是 mod_rewrite 的一部分，而不是 mod_alias。）
为了匹配查询字符串，您需要使用 mod_rewrite 和额外的 条件 来检查 QUERY_STRING 服务器变量。例如：
RewriteCond %{QUERY_STRING} ^deckid=(1241)$
RewriteRule ^deck/$ /green-otk-%1 [R=301,L]
%1 反向引用包含 1241（从前面的 CondPattern 中捕获）——这只是避免了重复（可能会引入错误）。当然，除非您自动生成这些指令。
不要使用 .htaccess - 请改用您的应用程序逻辑
但是，理想情况下，您一开始就不会在 .htaccess 中进行这些重定向。在您的应用程序逻辑中执行这些操作要好得多（理想情况下，当您的站点确定结果会触发 404 时——尽管在您的情况下不会发生这种情况）。通过将这些指令放在 .htaccess 中，您将以牺牲正常站点流量为代价来确定“重定向”的优先级。通过实施这些重定向 later（在您的应用程序中），您可以优先考虑正常的网站流量。
因为我假设您正在使用前端控制器来路由您的 URL，所以这应该相对容易实现。 （您仅在收到与旧 URL 格式匹配的请求时才处理重定向逻辑。）
优化的 .htaccess 版本
但是，如果您决定走 .htaccess 路线，如果您所有的旧 URL 都遵循相同的格式，那么您可以极大地优化它...您可以在内部重写任何使用该格式的请求/deck/?deckid=<number> 到一个子目录（假设你所有的旧 URL 都使用这种格式）。然后，您在处理所有 1218 重定向的子目录中有另一个 .htaccess 文件。这样，您的主 .htaccess 文件中只有一个指令，每个请求都会处理该指令，并且仅在需要时才处理重定向逻辑（在子目录 .htaccess 文件中）。
这避免了在 .htaccess 主文件中包含 1000 多个重定向指令的开销。
子目录 .htaccess 文件中的指令也可以简化，因为我们可以重写将查询字符串移动到 URL 路径的请求，以避免额外的 条件 稍后。
例如，在根 .htaccess 文件的顶部：
RewriteEngine On
# Internally rewrite the request for (what looks like) an old URL
# ...to the "/redirect-old" subdirectory
RewriteCond %{QUERY_STRING} ^deckid=(\d+)$
RewriteRule ^deck/$ redirect-old/%1 [L]
/deck/?deckid=<number> 形式的所有 URL 都在内部重写为 /redirect-old/<number>...
然后，在 /redirect-old/.htaccess 中，您有 简化的 “重定向”指令，如下所示，与 rewritten URL:
# /redirect-old/.htaccess
RewriteEngine On
# Redirect old URLs
RewriteRule ^1241$ /deck/green-otk-[=13=] [R=301,L]
RewriteRule ^1234$ /deck/foo-[=13=] [R=301,L]
RewriteRule ^4321$ /deck/bar-[=13=] [R=301,L]
:
这些指令与重写的 URL 匹配，即。 /redirect-old/<number> 并相应地重定向。
在每种情况下，[=35=] 反向引用只是与 RewriteRule 匹配的 URL-路径（即 number） 模式。 （保存重复 - 如上所述。）