Nginx 架构决定其不解析 .htaccess，所谓“支持”仅为手动 include 的错误模拟；必须人工将 RewriteCond/RewriteRule 翻译为 location + try_files 或 rewrite 规则，并确保路径、fastcgi_param 等配置准确。
phpEnv 默认不读取 .htaccess，强行 include 会报错或失效，这不是配置问题，而是 Nginx 架构决定的 —— 它压根不解析 .htaccess，所谓“支持”只是手动 include 的模拟，且极易出错。
为什么 phpEnv 的 Nginx 不能直接用 .htaccess
Nginx 没有 mod_rewrite 模块的概念，也不扫描目录下是否存在 .htaccess。你看到的“支持”方案（比如 include /path/.htaccess;）本质是把 Apache 规则文本硬塞进 Nginx 配置里，但：
• RewriteCond 和 RewriteRule 语法不兼容，Nginx 会直接拒绝加载配置
• IfModule、Options、RewriteBase 等指令在 Nginx 中无对应实现，一写就 nginx: [emerg] unknown directive
• phpEnv 的 Nginx 配置通常由控制面板自动生成，手动修改后重启可能被覆盖
正确迁移 .htaccess 到 phpEnv 的 Nginx 配置
必须人工翻译规则，不能复制粘贴。核心原则：用 location + try_files 或 rewrite 替代 Apache 的 RewriteCond+RewriteRule：
• 所有 !-f + !-d 组合 → 改用 try_files $uri $uri/ /index.php?$args;
• 排除敏感路径（如 app/、vendor/）→ 单独写 location ~ ^/(app|vendor|config)/ { return 403; }
• 匹配具体路径如 ^article/([0-9]+)\.html$ → 改成 location ~ ^/article/(\d+)\.html$ { rewrite ^/article/(\d+)\.html$ /index.php?id= last; }
• [QSA,L] 中的 QSA 对应 Nginx 的 $args 或 $query_string，L 对应 last（仅在 rewrite 中需显式写）
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
phpEnv 中修改 Nginx 配置的实际位置
phpEnv 的站点配置文件不在 /usr/local/nginx/conf/ 这类通用路径，而是在：
• Windows 下：通常是 phpEnv\nginx\vhosts\your-site.conf
• Linux/macOS 下（若用 Docker 版）：挂载到容器内的 /etc/nginx/conf.d/your-site.conf
修改前务必确认：
• 该文件是否被 phpEnv 的 GUI 界面管理（改了会被重写）
• 是否已启用 rewrite 模块（默认已编译，无需额外操作）
• 修改后必须执行 phpenv nginx reload 或通过界面点击「重载配置」，restart 可能中断 PHP-FPM 连接
立即学习“PHP免费学习笔记（深入）”；
常见翻车点：伪静态生效但页面空白或 500
这几乎全是入口文件路径或 FastCGI 参数导致的：
• try_files 后的 /index.php?$args 中的 /index.php 必须是相对于 root 的绝对路径，不是网站根目录下的相对路径
• 若项目入口在子目录（如 http://localhost/blog/），root 应设为 /path/to/blog，而不是整个 www 目录
• location = /index.php 块中缺失 fastcgi_pass 或 fastcgi_param SCRIPT_FILENAME，会导致 PHP 文件不执行，只输出源码或 500
• 使用 rewrite ... last 时，目标 URI 必须以 / 开头（如 /index.php?id=123），否则 Nginx 会当成内部重定向失败
