我正在尝试设置从/ api / user {/ id}到api / user.php {/ id}的重写，但是由于某些原因，它不起作用。我想这是一个内部重写循环，但我不知道如何解决它。
RewriteCond %{REQUEST_URI} ^\/?api\/user\/?([a-zA-Z0-9_\-\/]+)?
RewriteRule ^\/?api\/user\/?(.*)?$ api/user.php/$1 [L,QSA]
文件夹结构：
api/
api/user.php
当我更改重写规则以使其不是用户而是user2时，它可以正常工作。但是，这不是我所需要的，因此，如果您能帮助我找到一种解决方案来保持命名，那就好了。这是与用户2：
一起使用的RewriteCond %{REQUEST_URI} ^\/?api\/user2\/?([a-zA-Z0-9_\-\/]+)?
RewriteRule ^\/?api\/user2\/?(.*)?$ api/user.php/$1 [L,QSA]
这可能是您要寻找的：
RewriteEngine on
RewriteRule ^/?api/user(?:/([a-zA-Z0-9_\-\/]*))?$ /api/user.php/$1 [END]
它匹配/api/user和/api/user/，但不捕获任何内容。对于每个更长的请求URL，其余部分将与您指定的字符组匹配。
如果使用上述规则收到内部服务器错误（http状态为500），则很可能是您运行的Apache http服务器的版本非常旧。在这种情况下，您将在http服务器错误日志文件中看到对不支持的[END]标志的明确提示。您可以尝试升级或使用旧的[L]标志，在这种情况下它可能会起作用，尽管这在一定程度上取决于您的设置。
此实现将在http服务器主机配置或分布式配置文件（“ .htaccess”文件）中同样起作用。显然，重写模块需要加载到http服务器内部并在http主机中启用。如果使用分布式配置文件，则需要注意在主机配置中完全启用了它的解释，并且该解释位于主机的DOCUMENT_ROOT文件夹中。
和一般说明：您应该始终喜欢将此类规则放置在http服务器主机配置中，而不是使用分布式配置文件（“ .htaccess”）。这些分布式配置文件增加了复杂性，通常是导致意外行为，难以调试的原因，并且确实降低了http服务器的速度。仅当您无法访问真正的http服务器主机配置（阅读：真正便宜的服务提供商）或坚持编写自己的规则的应用程序（这显然是安全的噩梦）时，才提供它们作为最后的选择。