会，Apache的.htaccess重写规则可能劫持vendor/autoload.php请求，导致Class not found；需在规则顶部显式排除vendor/等路径并加[L]终止匹配。
Apache下.htaccess会干扰Composer自动加载吗？
会，而且很常见——尤其当你把项目放在子目录、或用了重写规则时。.htaccess里的RewriteRule可能把vendor/autoload.php的请求劫走，或者让index.php无法正确加载自动加载器。
根本原因不是Composer本身有问题，而是Apache在处理PHP文件前，先按.htaccess规则匹配路径。一旦规则里有.*、!-f、!-d这类泛匹配，就容易误伤vendor/下的真实PHP文件。
- 典型错误现象：
Class not found，但vendor/autoload.php明明存在且可读 - 用
curl -I /vendor/autoload.php返回403或404，说明Apache根本没让它进PHP解析流程 - 检查
error_log，常看到File does not exist: /path/to/vendor/autoload.php——其实是被重写规则跳过了
.htaccess中必须排除vendor/和composer.json等路径
别指望“默认放行”，Apache不会自动识别Composer目录。你得显式告诉它：这些路径不参与重写、不拦截、不验证权限。
最简有效写法（放在.htaccess顶部）：
Accessibility Review
下载
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
<IfModule mod_rewrite.c> RewriteEngine On # 排除 vendor 目录及其子文件，直接放行 RewriteRule ^vendor(/|$) - [L] # 排除 composer.json/composer.lock，防止被重写成HTML页面 RewriteRule ^(composer\.(json|lock)|phpunit\.xml) - [L,R=404] </IfModule>
-
^vendor(/|$)比^vendor/更安全，覆盖vendor和vendor/xxx两种情况 -
[L]必须加，否则后续规则仍可能生效 - 如果项目根目录外还有其他敏感文件（如
.env），也建议一并RewriteRule拦截或拒访
为什么require 'vendor/autoload.php'在index.php里有时不生效？
不是require写错了，而是Apache没把index.php当PHP执行——比如AddHandler没配对，或.htaccess里写了deny from all又没开例外。
- 确认
index.php能输出phpinfo()，否则先查PHP是否启用 - 检查
httpd.conf或虚拟主机配置里是否有AllowOverride None——这会让.htaccess完全失效，导致重写和路径排除都无效 - 如果用
SetHandler application/x-httpd-php，确保它没被<FilesMatch>块覆盖 - Composer自动加载依赖
opcache.enable和include_path，但Apache配置错误会卡在第一步：连autoload.php都读不到
开发环境和生产环境的.htaccess要分开维护
本地用XAMPP/MAMP时，.htaccess常带调试规则（比如强制HTTPS、重定向www），上线到Apache服务器后，这些规则可能和Nginx反代、CDN或负载均衡冲突。
- 不要把
localhost专用的RewriteCond %{HTTP_HOST} !^localhost直接扔到生产环境 - 生产环境应禁用
DirectoryIndex index.php以外的索引文件，避免暴露vendor/目录结构 - 如果启用了
mod_security，某些规则会拦截composer install生成的autoload_classmap.php中的长数组字面量，表现为500错误但无日志——这时得临时关掉SecRuleEngine排查
真正麻烦的从来不是写几行RewriteRule，而是你改了.htaccess之后，忘了它同时影响了静态资源路由、API入口、以及Composer加载链的每一环。
