真的很困惑，因为形式和语法看起来都很好。
REQUEST_URI 的 RewriteCond 与显式路径和文件名不匹配。隔离时，REQUEST_FILENAME 的 RewriteCond 匹配得很好。我已经使用 phpinfo() 验证了 REQUEST_URI 包含前导斜杠，并且也进行了不带前导斜杠的测试。
这里的目标是知道请求是针对此文件的，如果它不存在，则抛出 410。
RewriteCond %{REQUEST_URI} ^/dir1/dir2/dir3/v_9991_0726dd5b5e8dd67a214c0c243436d131_all\.css$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ - [R=410,L]
我不想省略第一个 Cond，因为我只想对与此类似的少数文件执行此操作。
UPDATE I
试图获得明确的测试。测试设置：
- testmee.txt 不存在
- 请求是针对根目录中的 testmee.txt
- 通过重定向到 google 验证 request_uri 是否匹配
- 仅使用第一个 Cond 时无法得到 410
- （仅使用第一个 Cond 时，服务器提供 404，而不是 410）
- （使用两个条件，服务器提供 404，而不是 410）
- 仅使用第二个 Cond 时可以获得 410
RewriteCond %{REQUEST_URI} ^/testmee\.txt$
#RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ - [R=410,L]
versus
#RewriteCond %{REQUEST_URI} ^/testmee\.txt$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ - [R=410,L]
更新二
怀特先生的回复：
呃，同样的症状。可能不得不忍受 googlebot 命中 404，而不是过时的 css/js 所需的 410。从长远来看，可能没什么大不了的。
感谢您的 request_uri 测试重定向。在这些测试中一切都正常工作。页面名称等按预期返回，在 var= 重写 URL 中。
此时，我认为一定是对与文件类型扩展名相关的 404 进行了一些内部处理。请参阅下面的线索。我有 Prestashop 购物车软件，它一定会在文件类型上强制执行 404。
这将重定向到谷歌（以确认模式匹配）：
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^testmee\.txt$ http://www.google.com/ [L]
(L flag is needed or else other Rules further down will interfere.)
这将继续返回 404 而不是 410：
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^testmee\.txt$ - [NC,R=410]
作为控制测试，这将返回 410：
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*$ - [NC,R=410]
如果在上述失败的测试中文件类型为 css，则我的自定义 404 控制器不会被调用。我只得到一个简单的 404 响应，没有包含我所有网站模板的自定义 404。
例如：
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^testmee\.css$ - [NC,R=410]
恐怕我已经浪费了你的一些时间。我很抱歉。我从来没有想过Prestashop的代码会根据文件类型强制404，但我看不到任何其他解释。我可以深入研究它，也许可以在控制器中找到正在执行此操作的位置。不过还是得休息一下
