Composer 不操作 .htaccess，报错源于插件、脚本或部署工具（如 Plesk、自定义 scripts）试图写入该文件；应通过 -v 模式定位触发命令，检查并修复报错路径所属目录（如 public/）的属主和写权限，或禁用相关自动化功能。
Composer 本身不会生成或写入 .htaccess 文件——报这个错，说明你正在运行的不是标准 Composer 命令，而是某个插件、脚本或部署工具（比如 Plesk 的 Composer 集成、自定义 post-install-cmd 脚本）在试图操作该文件时失败了。
为什么 Composer 会报 .htaccess Permission denied？
标准 composer install 或 composer update 完全不碰 .htaccess。一旦看到类似 file_put_contents(/path/to/public/.htaccess): Permission denied，基本可锁定为以下三类情况：
- 你在
composer.json的scripts里写了自定义命令（如post-install-cmd），调用了cp、touch或 PHP 的file_put_contents()写.htaccess - Plesk、cPanel 或某些 CI/CD 部署脚本在
composer install后自动尝试生成/覆盖.htaccess - 你手动执行了类似
php bin/console assets:install（Symfony）或php artisan storage:link（Laravel），而这些命令内部逻辑意外触发了对.htaccess的写操作（极少见，但某些旧版封装脚本有此 bug）
检查真实触发者：先定位是哪个命令在写
别急着改权限——先确认谁在动这个文件：
- 运行
composer install -v（verbose 模式），看报错前最后一行执行的是什么脚本或命令 - 搜
composer.json里的"scripts"字段，重点看post-install-cmd、post-update-cmd、pre-autoload-dump等钩子 - 如果用的是 Plesk，在「扩展 > Composer」设置页里关掉「自动更新」或「自动重写 .htaccess」选项再试一次
- 临时重命名
public/.htaccess为public/.htaccess.bak，再跑composer install—— 如果不再报错，说明确实是某脚本在尝试创建它
修复 .htaccess 写入失败：只修目标路径，不碰全局
假设确认是部署脚本或自定义命令要写 public/.htaccess，那问题就是当前用户对 public/ 目录无写权限。修复要点很窄：
- 检查归属：
ls -ld public/—— 若 owner 不是当前用户（比如显示root root），执行sudo chown $USER:$USER public/ - 检查权限：
ls -l public/ | head -1—— 若目录权限不含w（如显示dr-xr-xr-x），执行chmod u+w public/ - 不要递归改
public/下所有文件：chmod -R u+w public/可能导致 Web 服务器误读敏感文件（如public/index.php被设为可执行） - 如果
public/在 WSL 的/mnt/c/或 Docker bind mount 下，chown和chmod无效 —— 必须把项目移到~/projects/这类原生 Linux 路径再操作
更稳妥的做法：绕过自动生成，手动提供 .htaccess
很多所谓“自动生成 .htaccess”的功能既不可靠又没必要。直接手动维护更可控：
- 从 Symfony 官方文档或 Laravel 文档复制一份标准
.htaccess内容，保存到public/.htaccess - 设为只读防止被覆盖：
chmod u-w public/.htaccess - 删掉
composer.json中所有试图操作.htaccess的scripts行 - 如果是 Plesk 环境，彻底禁用其 Composer 插件，改用 SSH 手动执行
composer install
真正容易被忽略的是：报错信息里写的 .htaccess 路径，往往不是你直觉认为的那个文件——它可能是某个插件在临时目录里生成的副本，或是 Plesk 尝试写入的系统级模板路径（比如 /var/www/vhosts/example.com/httpdocs/.htaccess）。必须用 ls -ld 实际检查报错路径的归属，而不是默认去修项目根目录下的那个。
