WordPress .htaccess：性能、安全性和SEO的完整技术指南

.htaccess（超文本访问）文件是一个目录级 Apache 配置文件，用于指示 Web 服务器如何处理您的 WordPress 站点请求——无需更改全局 httpd.conf。您在 .htaccess 中放置的每条指令都会递归应用于其所在目录及其下的所有子目录，使根级文件成为 WordPress 管理员在服务器之外可用的最强大的单一控制手段。

对于 WordPress 而言，.htaccess 是美化固定链接的引擎、抵御恶意流量的第一道防线，以及通过压缩和浏览器缓存实现的直接性能倍增器——所有这些都无需使用任何插件。

WordPress .htaccess 文件的实际作用

Apache 在每一个 HTTP 请求上都会处理 .htaccess。这意味着您编写的每条指令都会对延迟、安全状态和爬取行为产生可衡量的影响。当您保存固定链接结构时，WordPress 会自动向 .htaccess 写入一个最小化的重写块，但该块只是起点。该文件能够处理：

• URL 重写和重定向，通过 mod_rewrite
• 访问控制，通过 mod_authz_host 和 mod_access_compat
• HTTP 响应头注入，通过 mod_headers
• 输出压缩，通过 mod_deflate
• 浏览器缓存控制，通过 mod_expires
• 身份验证门控，通过 mod_auth_basic
• 自定义错误文档，通过 ErrorDocument 指令

了解哪个 Apache 模块支持每条指令至关重要——如果该模块未在您的服务器上加载，该指令将静默失败或抛出 500 错误。在部署高级规则之前，请务必向您的主机确认模块可用性。

.htaccess 文件的位置及访问方式

WordPress 安装的主 .htaccess 文件位于文档根目录——通常是 /public_html/、/var/www/html/，或您的主机分配的等效路径。这与包含 wp-config.php、wp-login.php 和 wp-content/ 文件夹的目录相同。

由于文件名以点开头，大多数操作系统和 FTP 客户端默认会将其隐藏。

在 FileZilla 中显示隐藏文件：

Server menu > Force showing hidden files

在 cPanel 文件管理器中显示隐藏文件：

Settings > Show Hidden Files (dotfiles)

在拥有 SSH 访问权限的 VPS 托管环境中，您可以直接确认文件是否存在并检查其权限：

ls -la /var/www/html/ | grep htaccess

该文件应由 Web 服务器用户（通常为 www-data 或 apache）拥有，并具有 644 权限。.htaccess 上的全局可写权限（666 或 777）是严重的安全漏洞——服务器上的任何进程都可能覆盖您的规则。

默认 WordPress .htaccess 块详解

当您在 WordPress 后台导航至设置 > 固定链接并保存时，WordPress 会写入以下块：

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

逐行解析：

RewriteEngine On — 为此目录上下文激活重写引擎。
RewriteBase / — 设置相对重写的基础 URL 路径。对于子目录安装，将其更改为 /subdirectory/。
RewriteRule ^index.php$ - [L] — 如果请求的字面路径是 index.php，则停止处理并直接提供服务。
RewriteCond %{REQUEST_FILENAME} !-f — 仅当请求路径不是现有文件时才继续。
RewriteCond %{REQUEST_FILENAME} !-d — 仅当请求路径不是现有目录时才继续。
RewriteRule . /index.php [L] — 将其他所有内容路由到 WordPress 的前端控制器。

关键规则：切勿手动编辑 # BEGIN WordPress 和 # END WordPress 标记之间的任何内容。WordPress 会自动重新生成该块并覆盖您的更改。请将所有自定义指令放置在 # BEGIN WordPress 注释上方或 # END WordPress 注释下方。
如何在 .htaccess 文件缺失时创建它
缺少 .htaccess 文件会导致除主页外的所有 WordPress URL 返回 404 错误，因为 Apache 没有指令将请求路由到 index.php。
方法一：通过后台重新生成
导航至设置 > 固定链接，不做任何修改直接点击保存更改。如果目录可写，WordPress 将尝试自动写入该文件。
方法二：通过 SSH 手动创建
nano /var/www/html/.htaccess
粘贴上述默认块，用 Ctrl+O 保存，并用 Ctrl+X 退出。然后设置正确的权限：
chmod 644 /var/www/html/.htaccess
chown www-data:www-data /var/www/html/.htaccess
方法三：通过 FTP 创建
在本地创建一个纯文本文件，命名为 .htaccess（不是 .htaccess.txt——扩展名必须省略），粘贴默认块，然后以 ASCII 传输模式将其上传到文档根目录。
URL 重定向：301、302 和重写规则
永久 301 重定向
301 重定向向搜索引擎发出信号，表明某个 URL 已永久移动。Google 通过 301 传递约 90–99% 的链接权重。当您重命名文章别名、从 HTTP 迁移到 HTTPS 或整合重复内容时，请使用它。
# Redirect a single old page to a new URL
Redirect 301 /old-page/ https://yourdomain.com/new-page/

# Redirect an entire old directory
Redirect 301 /old-category/ https://yourdomain.com/new-category/
临时 302 重定向
仅当目标确实是临时性的时才使用 302——例如，在 A/B 测试或维护窗口期间。搜索引擎不会通过 302 传递链接权重。
Redirect 302 /sale/ https://yourdomain.com/promo-page/
使用 mod_rewrite 强制 HTTPS
这是任何生产环境 WordPress 站点最重要的规则之一。将其放置在 WordPress 块上方，可确保所有 HTTP 流量在 WordPress 处理请求之前就被永久重定向到 HTTPS：
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
如果您的站点位于终止 SSL 的负载均衡器或 CDN 后面（云基础设施中常见），请改用 X-Forwarded-Proto：
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
将其与有效的 SSL 证书配合使用，对于安全性和 Google 排名信号而言都是不可或缺的。
从非目录 URL 中移除尾部斜杠
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{THE_REQUEST} s(.+?)/+s
RewriteRule ^(.+)/$ /$1 [R=301,L]
</IfModule>
从分类 URL 中移除”category”
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^category/(.+)$ https://yourdomain.com/$1 [R=301,L]
</IfModule>
警告：此规则需要配合 WP No Category Base 等插件来同时更新 WordPress 的内部路由，否则将产生重定向循环。
通过 .htaccess 进行安全加固
保护 wp-config.php
wp-config.php 包含您的数据库凭据、身份验证密钥和盐值。必须无条件阻止浏览器直接访问：
<Files wp-config.php>
    Order Allow,Deny
    Deny from all
</Files>
保护 .htaccess 文件本身
防止 .htaccess 文件通过浏览器请求被读取：
<Files .htaccess>
    Order Allow,Deny
    Deny from all
</Files>
禁用目录浏览
如果目录中不包含 index.php 或 index.html，Apache 默认会列出其内容——将您的文件结构暴露给攻击者：
Options -Indexes
阻止 XML-RPC 滥用
xmlrpc.php 是暴力破解放大攻击的常见目标。如果您不使用 Jetpack、远程发布或 pingback，请完全阻止它：
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>
将 wp-login.php 限制为特定 IP 地址
在拥有静态 IP 的 带 cPanel 的 VPS 或任何专用环境中，这是可用的最高影响力安全措施之一：
<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.10
    Allow from 198.51.100.25
</Files>
将 IP 地址替换为您实际的静态 IP。如果您从多个位置工作或使用动态 IP，请考虑使用具有固定出口节点的 VPN。
阻止恶意用户代理
爬虫、漏洞扫描器和评论垃圾机器人通常会使用可识别的用户代理字符串标识自身：
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (ahrefsbot|semrushbot|mj12bot|dotbot|nikto|sqlmap) [NC]
RewriteRule .* - [F,L]
</IfModule>
注意：阻止 Ahrefs 和 SEMrush 等合法 SEO 爬虫将使您无法在这些工具中查看自己的反向链接数据。请根据您的使用场景评估此权衡。
按 IP 地址阻止访问
<Limit GET POST HEAD>
    Order Allow,Deny
    Allow from all
    Deny from 192.0.2.50
    Deny from 198.51.100.0/24
</Limit>
CIDR 表示法（例如 /24）允许您阻止整个子网，这在处理来自单一 IP 范围的协调攻击时非常有用。
防止图片盗链
盗链会消耗您的带宽而对您毫无益处。阻止外部站点直接嵌入您的图片：
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www.)?yourdomain.com/ [NC]
RewriteRule .(jpg|jpeg|png|gif|webp|svg)$ - [F,NC]
</IfModule>
通过 .htaccess 添加安全响应头
HTTP 安全响应头是一个经常被忽视的防御层，.htaccess 无需任何插件即可注入：
<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-XSS-Protection "1; mode=block"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>
对于内容安全策略（CSP），响应头的值必须根据您站点的具体资源来源进行定制——通用的 CSP 会破坏内联脚本和第三方嵌入内容。
性能优化
使用 mod_deflate 启用 Gzip 压缩
Gzip 压缩可将 HTML、CSS 和 JavaScript 响应的大小减少 60–80%，直接改善首字节时间（TTFB）和 Core Web Vitals 分数：
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/json
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE image/svg+xml

    # Remove browser bugs for older clients
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    BrowserMatch bMSIE !no-gzip !gzip-only-text/html
    Header append Vary User-Agent
</IfModule>
不要压缩已压缩的格式：image/jpeg、image/png、image/gif、image/webp、application/zip、application/pdf。尝试压缩它们会浪费 CPU 周期，实际上还可能增加响应大小。
使用 mod_expires 进行浏览器缓存
浏览器缓存指示回访用户的浏览器从本地缓存提供静态资源，而不是从您的服务器重新下载：
<IfModule mod_expires.c>
    ExpiresActive On

    # Images
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType image/x-icon "access plus 1 year"

    # Fonts
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType font/woff "access plus 1 year"
    ExpiresByType application/font-woff "access plus 1 year"

    # CSS and JavaScript
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"

    # HTML and XML (short cache — content changes frequently)
    ExpiresByType text/html "access plus 1 hour"
    ExpiresByType application/xml "access plus 1 hour"
    ExpiresByType application/rss+xml "access plus 1 hour"

    # Default fallback
    ExpiresDefault "access plus 1 month"
</IfModule>
缓存清除注意事项：CSS 和 JS 的长缓存有效期意味着浏览器在缓存过期之前不会获取更新。请使用带版本号的文件名或查询字符串（例如 style.css?ver=2.1）——WordPress 的 wp_enqueue_style() 通过 $ver 参数自动处理此问题。
用于精细控制的 Cache-Control 响应头
mod_expires 设置 Expires 响应头。为符合现代 HTTP/1.1 和 HTTP/2 规范，还需显式设置 Cache-Control：
<IfModule mod_headers.c>
    <FilesMatch ".(ico|jpg|jpeg|png|gif|webp|css|js|woff2|woff)$">
        Header set Cache-Control "max-age=31536000, public, immutable"
    </FilesMatch>
    <FilesMatch ".(html|php)$">
        Header set Cache-Control "max-age=3600, must-revalidate"
    </FilesMatch>
</IfModule>
immutable 指令告知支持的浏览器（Firefox、Chrome）在资源有效期内不重新验证该资源，从而完全消除条件 GET 请求。
启用 Keep-Alive
持久连接可减少同一页面上多个资源的 TCP 握手开销：
<IfModule mod_headers.c>
    Header set Connection keep-alive
</IfModule>
对比：.htaccess 与基于插件的配置




功能
.htaccess 指令
WordPress 插件等效方案
性能影响




URL 重写
mod_rewrite 规则
Yoast SEO、Redirection
.htaccess 更快（无 PHP 开销）


Gzip 压缩
mod_deflate
WP Super Cache、W3 Total Cache
.htaccess 更快（Apache 层级）


浏览器缓存
mod_expires
WP Rocket、LiteSpeed Cache
.htaccess 更快（Apache 层级）


IP 封锁
Deny from
Wordfence、iThemes Security
.htaccess 更快（PHP 前执行）


安全响应头
mod_headers
HTTP Headers 插件
.htaccess 更快（Apache 层级）


wp-login.php 保护
<Files> 块
Limit Login Attempts Reloaded
.htaccess 更快（PHP 前执行）


内容安全策略
mod_headers
CSP 插件
相当——两者均注入响应头


数据库驱动的重定向
不适用
Redirection 插件
大型重定向集合时插件更优


图形界面管理
不适用
All In One WP Security
非技术用户时插件更优




关键架构洞察：.htaccess 规则在 Apache 模块层级执行，在 PHP 被调用之前。这意味着被阻止的请求几乎不消耗任何服务器资源。基于插件的阻止必须引导 WordPress、加载插件，然后才能拒绝请求——每次被阻止的访问消耗的内存和 CPU 是前者的 10–50 倍。在遭受机器人攻击的高流量站点上，这一差异决定了站点是保持在线还是崩溃。
保护敏感目录
锁定 wp-includes 目录
wp-includes 目录不应直接向浏览器提供 PHP 文件：
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-includes/[^/]+.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
限制对 Uploads 目录的访问
wp-content/uploads/ 目录应提供媒体文件，但绝不执行 PHP。通过存在漏洞的插件上传并从该目录执行的 PHP 文件是典型的 Webshell 攻击向量：
<Directory "/var/www/html/wp-content/uploads">
    <FilesMatch ".php$">
        Order Deny,Allow
        Deny from all
    </FilesMatch>
</Directory>
如果您使用共享虚拟主机且无法在 .htaccess 中使用 <Directory> 块，请在 wp-content/uploads/ 内创建一个单独的 .htaccess 文件，内容如下：
<FilesMatch ".php$">
    Order Deny,Allow
    Deny from all
</FilesMatch>
自定义错误页面
用品牌化、用户友好的替代页面取代 Apache 的默认错误页面：
ErrorDocument 400 /400.html
ErrorDocument 401 /401.html
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html
对于 WordPress，404 页面通常由 index.php 路由到主题的 404.php 模板处理——但为 500 错误准备静态回退页面很有价值，因为 500 意味着 PHP 本身可能已损坏。
WordPress 多站点 .htaccess 配置
WordPress 多站点需要根据您使用子目录还是子域名网络结构来使用不同的重写块。
基于子目录的多站点：
# BEGIN WordPress Multisite
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]

# Uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# Add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress Multisite
基于子域名的多站点需要在域名注册商层面进行通配符 DNS 配置——仅更改 .htaccess 是不够的。如果您自行管理 DNS，这需要通过您的域名注册服务商的 DNS 面板，使用通配符 A 记录（*.yourdomain.com）来处理。
高级技术：速率限制与请求过滤
阻止查询字符串中的常见攻击模式
<IfModule mod_rewrite.c>
RewriteEngine On

# Block SQL injection attempts
RewriteCond %{QUERY_STRING} (union.*select|select.*from|insert.*into|drop.*table) [NC]
RewriteRule .* - [F,L]

# Block script injection
RewriteCond %{QUERY_STRING} (<script|javascript:|vbscript:) [NC]
RewriteRule .* - [F,L]

# Block base64 encoded payloads in query strings
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [NC]
RewriteRule .* - [F,L]
</IfModule>
重要说明：这些正则表达式模式是有用的第一层防护，但不能替代 Web 应用防火墙（WAF）。复杂的攻击者会使用编码变体来绕过简单的字符串匹配。请将这些规则视为噪音过滤器，而非全面的防御手段。
限制请求方法
WordPress 只需要 GET、POST 和 HEAD。阻止所有其他 HTTP 方法：
<LimitExcept GET POST HEAD>
    Order Deny,Allow
    Deny from all
</LimitExcept>
最佳实践与操作规范
每次编辑前：

将当前 .htaccess 下载到本地计算机作为带日期的备份（例如 htaccess-backup-2025-01-15.txt）。
如有可用的暂存环境，请先在其中测试更改。
每次只做一项逻辑更改——切勿在单次编辑会话中批量添加多个不相关的指令。

每次编辑后：

重新加载 Apache 以在浏览器测试前确认语法有效：

apachectl configtest

如果 configtest 通过，则优雅地重新加载：

systemctl reload apache2

测试您更改的具体功能，然后使用 curl -I https://yourdomain.com 等工具进行全站检查以验证响应头。

无服务器访问权限时的语法验证：
apachectl -t -f /path/to/.htaccess
在您控制 Apache 配置的独立服务器上，考虑将性能关键型指令从 .htaccess 迁移到虚拟主机配置中（<VirtualHost> 块，位于 httpd.conf 或特定站点的配置文件中）。当 AllowOverride 启用时，Apache 在每次请求时都会读取 .htaccess——将指令迁移到主配置文件可完全消除该每次请求的开销。
常见 .htaccess 错误排查
500 内部服务器错误
最常见的原因是 .htaccess 中存在语法错误。Apache 的错误日志将包含确切的行号：
tail -n 50 /var/log/apache2/error.log
常见语法错误：

缺少闭合 </IfModule> 标签
使用 Windows 风格的行尾（CRLF）而非 Unix 风格（LF）——请以不带 BOM 的 UTF-8 编码、LF 行尾保存文件
引用了未加载的模块（例如 mod_rewrite 已禁用）

重定向循环
重定向循环（ERR_TOO_MANY_REDIRECTS）通常发生在以下情况：

您的 HTTPS 重定向规则未能正确检测到连接已是安全的
您在 .htaccess 和 WordPress 设置（设置 > 常规 URL）中存在冲突的重定向规则
CDN 或代理正在剥离 HTTPS 服务器变量

诊断方法：
curl -I -L http://yourdomain.com 2>&1 | grep -E "HTTP|Location"
重写规则不生效
如果 mod_rewrite 规则似乎没有任何效果：

确认 mod_rewrite 已启用：apache2ctl -M | grep rewrite

添加 IP 限制后页面返回 403 禁止访问

如果您因在 IP 限制规则中将自己的 IP 地址输入有误而将自己锁定在外，请通过托管控制面板的文件管理器（在文件系统层级操作，绕过 Apache）访问该文件，并更正或删除该规则。

决策矩阵：何时使用 .htaccess 与替代方案

技术要点核查清单

• 将所有自定义指令放置在 # BEGIN WordPress / # END WordPress 标记外部——上方或下方，切勿置于内部。
• 在部署前，验证每个 <IfModule> 包装器对应的模块确实已在您的服务器上加载。
• 始终将 .htaccess 文件权限设置为 644——切勿设置为 666 或 777。
• 使用明确的拒绝规则保护 wp-config.php、.htaccess 本身、xmlrpc.php 和 wp-includes/*.php。
• 使用 mod_deflate 进行压缩，并将 mod_expires 与 Cache-Control: immutable 配合用于静态资源——仅这两项更改就能显著提升 Core Web Vitals 分数。
• 在 .htaccess 层级强制 HTTPS，而不仅仅在 WordPress 设置中，以便在 PHP 加载之前拦截请求。
• 在 VPS 或独立服务器环境中，将稳定的指令从 .htaccess 迁移到虚拟主机配置，以消除每次请求的文件解析开销。
• 每次编辑会话前使用带日期的文件名备份 .htaccess，并在每次更改后使用 apachectl configtest 验证语法。
• 在 wp-content/uploads/ 内创建单独的 .htaccess，阻止 PHP 执行——这一条规则可关闭一个关键的 Webshell 攻击向量。
• 将 .htaccess 安全规则视为降噪层，而非完整的 WAF——在生产环境中，应将其与 ModSecurity 或基于 CDN 的 WAF 等服务器级工具配合使用。

常见问题解答

编辑 .htaccess 是否需要重启 Apache？

不需要。当 AllowOverride 启用时，Apache 在每次 HTTP 请求时都会读取 .htaccess，因此更改无需重启服务器即可立即生效。但强烈建议在编辑前后运行 apachectl configtest，以便在语法错误导致生产环境出现 500 错误之前将其捕获。

.htaccess 规则是否适用于 Nginx 服务器？

不适用。.htaccess 是 Apache 特有的机制。Nginx 根本不读取 .htaccess 文件。等效规则必须写在主配置文件的 Nginx server {} 或 location {} 块中。许多托管 WordPress 主机使用 Nginx 并在服务器配置层面处理重写规则，这使得 .htaccess 在这些平台上无关紧要。

使用 .htaccess 的性能代价是什么？

当 AllowOverride 启用时，Apache 在每次请求时都会检查从文档根目录到请求文件的每个目录中是否存在 .htaccess 文件。对于目录结构较深的站点，这可能意味着每次请求需要 4–6 次文件系统读取。在高流量站点上，将指令迁移到虚拟主机配置并设置 AllowOverride None 可完全消除此开销。

.htaccess 规则是否会与 WordPress 固定链接设置冲突？

会。最常见的冲突发生在自定义 RewriteRule 干扰 WordPress 前端控制器模式时。始终将自定义重写规则放置在 # BEGIN WordPress 块上方，以便优先评估，并在添加任何新的重写逻辑后测试所有固定链接结构。

如何调试未按预期工作的 .htaccess 规则？

在虚拟主机配置中使用 LogLevel alert rewrite:trace3 临时启用 Apache 的 mod_rewrite 日志记录，然后重现请求并检查 /var/log/apache2/error.log。跟踪输出会精确显示哪些条件被评估、哪些规则匹配，以及最终重写后的 URL 是什么。调试完成后请立即禁用跟踪日志记录——它会生成极其详细的输出并影响性能。