本文详解如何通过 apache 的 mod_rewrite 模块，利用 .htaccess 文件将站点根目录（/）及所有形如 `/en2`、`/en100` 的非 `/en1` 语言子路径，统一、安全地 302 重定向至标准入口 `/en1`，避免 404 错误与循环跳转。
在实际 Web 部署中，常需将多个相似语义但非标准的 URL 统一导向唯一权威入口——例如强制所有 example.com/、example.com/en2、example.com/en99 等请求，全部重定向至 example.com/en1（该路径对应真实存在的 index.php 入口）。单纯依赖 PHP 层判断（如 strpos($_SERVER['REQUEST_URI'], "en1") === false）存在严重缺陷：它仅在 PHP 脚本被成功加载后才执行，而 /en2 等路径若未配置路由或物理文件，Apache 会直接返回 404，根本无法触发 PHP 逻辑；同理，RedirectMatch 和简单 RewriteRule 组合因缺乏条件判断与精确锚点匹配，易导致规则冲突或重定向失效。
正确方案应完全交由 Apache 在请求处理早期阶段（即内容分发前）完成重定向，确保零 PHP 依赖、高可靠性与低延迟。以下是推荐的 .htaccess 配置：
RewriteEngine On
# 规则1：将根路径 / 重定向至 https://example.com/en1（含协议+域名，避免相对路径歧义）
RewriteRule ^$ https://example.com/en1 [R=302,L]
# 规则2：匹配所有以 "en" 开头、后接一个或多个数字的路径（如 /en2、/en100），但排除 /en1 本身
RewriteCond %{REQUEST_URI} !^/en1$ # 注意：此处必须用 ^/en1$ 精确匹配完整路径
RewriteRule ^en[0-9]+/?$ https://example.com/en1 [R=302,L]✅ 关键说明：
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
- ^$ 表示空路径（即根 URI /）；^en[0-9]+/?$ 中 ^ 和 $ 确保完整匹配，/? 允许末尾可选斜杠，[0-9]+ 匹配至少一位数字；
- RewriteCond %{REQUEST_URI} !^/en1$ 是核心防护：防止 /en1 自身被错误重定向，避免无限循环；
- [R=302,L] 使用临时重定向（302），便于开发调试；上线后可改为 R=301 启用永久重定向（注意浏览器缓存）；
- 务必使用绝对 URL（含 https://example.com）：若写为 en1 或 /en1，Apache 可能生成相对重定向，导致协议丢失或跨域问题；
- 确保服务器已启用 mod_rewrite，且 .htaccess 允许 RewriteEngine（检查 AllowOverride All 或 AllowOverride FileInfo）。
⚠️ 常见陷阱与验证建议：
- ❌ 错误写法：RewriteRule en1 index.php —— 这是内部重写（rewrite），非外部重定向（redirect），且无条件匹配会导致所有含 en1 的路径（如 /en123）也被误处理；
- ❌ 忽略 L 标志：若遗漏 L（Last），后续规则仍会继续执行，引发不可预期行为；
- ✅ 验证方式：使用 curl -I http://example.com/en2 检查响应头是否含 HTTP/1.1 302 Found 和 Location: https://example.com/en1；
- ✅ 生产环境部署前，先在测试子域验证，并清除浏览器缓存（尤其使用过 301 时）。
综上，基于 RewriteCond + RewriteRule 的组合是解决此类多路径归一化重定向最健壮、高效的方式。它不依赖后端脚本，全程由 Web 服务器处理，兼具安全性、可维护性与兼容性。
