.htaccess 语法检查工具
粘贴 .htaccess 文件内容，即可立即发现常见错误：区块标签未闭合、指令名称拼写错误、RewriteRule 参数不足、以及缺少对应规则的孤立 RewriteCond。
使用提示
- 本工具是基于逐行规则的启发式静态检查，并非真正的 Apache 解析器。部署前请务必在真实服务器或预发布环境中测试。
- 如果你能访问 Apache 服务器的命令行，
apachectl configtest是最权威的语法检查方式。本工具适合在无法使用该命令的共享主机环境中做初步检查。 - "未识别指令"的警告只是基于固定白名单的低置信度推测。如果你使用了较冷门模块的指令，出现该警告也不一定代表写法有误。
- 连续书写多行 RewriteCond 是常见写法（相当于 AND 条件的叠加）。本工具只会在连续 RewriteCond 的最后一行之后没有 RewriteRule 时才发出警告。
- 上线到生产环境前，建议分批小幅应用改动并逐步验证，而不是一次性替换整份文件。
常见问题
最常见的原因是 Apache 主配置中该目录被设置为
AllowOverride None，导致 .htaccess 被完全忽略。请让服务器管理员确认已启用 AllowOverride All（或至少你所需要的具体项，例如 AuthConfig、FileInfo）。同时也请检查是否存在浏览器或 CDN 缓存导致看到的是旧内容。基本形式是
RewriteRule 匹配模式 替换目标 [标志]。匹配模式是一个正则表达式，用于匹配请求的 URL 路径（不含开头的斜杠），替换目标可以通过 $1、$2 等引用匹配模式中的括号分组。标志写在方括号内并用逗号分隔，例如 [L]（停止处理后续规则）或 [R=301]（永久重定向）。一个常见原因是重写后的 URL 再次匹配了同一条 RewriteRule 的模式，导致 Apache 反复重写。标准做法是加上类似
%{REQUEST_FILENAME} !-f 的 RewriteCond（仅当路径尚未对应一个已存在的文件时才生效），这样目标一旦真实存在，规则就不会再继续触发。在大多数共享主机环境下，该目录下的所有页面都会开始返回"500 Internal Server Error"。如果你能查看服务器的错误日志，那是定位具体出错行和原因最快的方法。
不能保证。本工具只是基于逐行正则的启发式静态检查，并不能完全还原真实 Apache 解析器的行为。所需模块（如 mod_rewrite）是否已加载、某条指令在当前上下文中是否被允许，都取决于具体的服务器环境，因此在正式依赖结果之前，请务必在预发布环境或真实服务器上进行验证。
闲话 ― 为什么叫做".htaccess"
".htaccess" 这个名字是"hypertext access"（超文本访问）的缩写，其历史可以追溯到 1995 年前后 NCSA httpd 及早期 Apache 版本。最初它被引入是为了让目录的所有者能够为自己管辖的空间设置密码保护（Basic 认证），而无需触碰只有服务器管理员才能编辑的全局配置文件（httpd.conf）。
".htaccess" 之所以强大，是因为只要 Apache 管理员通过 AllowOverride 指令允许，用户通过 FTP 或文件管理器上传文件后配置即刻生效，无需重启服务器。这让共享主机上通常无法访问主配置文件的用户，也能够按目录精细控制重定向、缓存策略和访问限制。
不过这种便利也是有代价的。Apache 官方文档明确建议：只要有权限访问服务器主配置文件，就应该把指令写在那里而不是 .htaccess 中。原因很简单——Apache 在处理每一次请求时，都要沿着目录树向上查找并重新读取所有的 .htaccess 文件，这带来的性能开销远比写在主配置文件中要大。
一处细微的语法错误也可能造成不小的麻烦：在许多共享主机环境下，无效的 .htaccess 会导致该目录下所有页面变成一片空白的"500 Internal Server Error"，定位具体原因往往要耗费不少时间。除了仔细通读代码，借助这类静态检查工具也能在上线前提前发现粗心导致的错误。