.htaccess 伪静态是什么：URL 重写规则、WordPress 固定链接与 404 排查

定义：.htaccess 伪静态的含义

伪静态是指把带查询参数的动态地址（例如 /index.php?p=123）重写为 /sample-post/ 这类静态外观的地址，而服务器内部依然执行 PHP 脚本；固定链接出现 404 时，判断问题是否出在这一层，需要先弄清它如何生效。在 Apache 环境里，这一层映射通常写在 .htaccess（超文本访问文件，按目录生效的 Apache 分布式配置片段）中，由 mod_rewrite（URL 重写模块）逐条匹配完成。

本词条从定义与原理出发，说明重写规则在什么时机被触发，并给出固定链接返回 404 时如何逐层定位的排查路径；相关基础术语可参见 概念与原理词条目录。

工作原理：重写规则如何被触发

一次访问进入 Apache 后，服务器先按请求路径定位到文档根下的目录，再读取该目录及其父目录中允许生效的 .htaccess，随后 mod_rewrite 按书写顺序逐条比对 RewriteCond（条件）与 RewriteRule（规则）。命中后地址被内部改写，浏览器地址栏保持不变，最终由 index.php 接收请求。整个过程发生在服务器内部，客户端只看到一次 200 响应。

WordPress 单站点默认写入的规则如下（写入时由 BEGIN 与 END 两条注释包裹，便于自动更新），可直接粘贴到站点根目录的 .htaccess：

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

两条 RewriteCond 决定了整段规则的行为边界：!-f 表示请求路径在磁盘上不是真实文件，!-d 表示也不是真实目录。只有两条同时成立才把请求交给 index.php，因此 /wp-content/uploads/ 下的图片与 /wp-admin/ 下的静态资源不会被改写逻辑吞掉。缺少其中任意一条，媒体库与后台样式会立刻大面积异常。

固定链接结构本身由 WordPress 的重写类解析，后台“设置 → 固定链接”保存的是一份规则数组；.htaccess 只负责把“磁盘上并不存在的路径”送进 index.php。两处不一致时的典型表现是：后台文章列表正常，前台文章页却整站 404。

生效前提：四个必要条件

1. AllowOverride 允许读取：虚拟主机（多个站点共享同一台服务器资源的托管方式）通常由主机商开启该权限；自建环境需要在目录配置段设置 AllowOverride FileInfo 或 All，否则 .htaccess 会被静默忽略，且不报错。
2. mod_rewrite 已加载：执行 httpd -M 或 apachectl -M，确认输出中存在 rewrite_module；缺失时所有重写规则都不会执行。
3. 目录允许符号链接跟随：mod_rewrite 要求所在目录上下文包含 Options FollowSymLinks 或 SymLinksIfOwnerMatch，缺失时通常返回 403 或 500。
4. 文件可被 Web 用户读取：权限设为 644，属主与站点目录一致；通过 FTP 上传覆盖后出现的属主错误是常见诱因。

四条中任意一条不满足，前台都会呈现“除首页外全部 404”，而后台仍可登录。这种不对称正是把问题误判成规则写错的主要原因。

典型应用场景

伪静态并非只为地址好看。最常见的一类用途是把 /?p=123 形式的参数地址改写为可读的 /sample-post/，让外部引用与站内链接长期稳定，也便于统计工具按路径归集数据。第二类用途出现在站点改版或迁移时，通过 301 重定向把旧地址逐条指向新地址，避免外部链接失效带来的流量损失。

第三类用途是统一主域形态，把带与不带 www 的地址收敛到一个规范地址，减少重复内容，具体取舍可参考 为什么建议网站主域采用 www 前缀 一文的分析。第四类用途是静态资源层的行为控制，例如为图片追加缓存头、限制特定目录的直接访问。运营多个站点的场景下，还可以按域名区分规则块，把不同站点的重写逻辑集中在同一份配置里维护，减少逐站登录面板的次数。

固定链接 404 的排查顺序

按从外到内的顺序检查，可以把绝大多数 404 收敛到具体一层，避免在东改西改中丢失初始状态：

1. 先确认现象范围：执行 curl -I https://example.com/sample-post/ 查看状态码。只有文章页 404、首页与后台正常，基本可判定为重写未生效，而不是文章或数据库问题。
2. 检查 .htaccess 是否存在且规则完整：文件缺失，或只剩 # BEGIN WordPress 注释块时，保存一次“设置 → 固定链接”即可让 WordPress 重新写入；提示目录不可写时，需手工创建文件并赋予 644 权限。
3. 核对 AllowOverride 与模块加载：查看 Apache 错误日志，出现 Invalid command 'RewriteEngine' 说明模块未加载，出现 Options not allowed here 说明目录权限不足，两种情况都不会给出前台报错。
4. 刷新重写缓存：有 WP-CLI 时执行 wp rewrite flush --hard；无命令行权限时再次保存固定链接页面即可触发规则重建。
5. 确认服务器类型：若站点实际运行在 Nginx 上，.htaccess 完全不参与解析，需要改写服务器段规则，见下一节对比。

排查过程建议保留每一步的结果，尤其是 curl -I 的状态码变化。状态码从 404 变为 301 或 200，说明规则已经命中；一直是 404 且日志无重写记录，则应回到第二、三步确认文件与权限。

对比：Apache .htaccess 与 Nginx 伪静态

两种环境的重写能力接近，但配置位置与生效机制完全不同，混用会让排查方向从一开始就偏掉。

Nginx 的等价写法只有一行：location / { try_files $uri $uri/ /index.php?$args; }。站点从 Apache 迁到 Nginx 后固定链接立刻 404，原因就在这里：原 .htaccess 被原样保留，却没有任何进程读取它。反向代理或容器化部署同样需要注意，重写必须发生在实际处理请求的那一层。

常见误区

• 把 .htaccess 当作通用配置文件：它只对 Apache 及其兼容实现生效。迁移到 Nginx 后必须先补服务器段规则再测试，可结合 主机控制面板 提供的伪静态模板逐项核对。
• 自定义规则写在 WordPress 主规则之后：主规则末行带 [L] 标记，命中即停止后续匹配，写在它后面的重定向永远不会执行，需要前置。
• 把 500 当成 404 处理：500 多为语法错误或模块缺失，404 才是规则未命中，两者排查方向相反，先看状态码再动手。
• 忽略控制面板的覆盖行为：部分面板在切换 PHP 版本或保存伪静态模板时会重写该文件，手工改动随之丢失，操作前应先导出备份。

参考资料与延伸阅读

以下资料用于核对指令语义与固定链接机制，站内条目可作为延伸阅读。WordPress 后台固定链接结构的具体设置流程，可参阅 WordPress 分类词条 下的相关文章。

• Apache HTTP Server 官方文档 · mod_rewrite 模块说明（RewriteCond、RewriteRule 与 [L] 标记定义）
• WordPress 官方文档 · 固定链接设置（固定链接结构与配置文件写入条件）
• 站内条目 · 用美国虚拟主机打造 WordPress 博客的完整指南
• 站内条目 · WordPress 定时发布失败的排查思路

维护与版本管理

变更前先导出原文件并纳入版本管理，变更后用 curl 逐条验证状态码，再回看错误日志是否出现新的告警。运行在 Nginx 或面板托管的容器环境中，应把等效规则写入服务器配置，而不是等待 .htaccess 生效；跨环境迁移前建议先在测试站点复现固定链接，确认重写链路完整后再切换域名解析。总结其本质：伪静态只是服务器内部的一次地址改写，只要模块加载、目录权限、规则顺序三者对齐，前台 404 很少反复出现。