Composer没有htaccess-protect配置项，也不生成或管理.htaccess文件；正确防护vendor目录需将public/设为Web根目录，而非依赖Composer配置。
Composer 没有 htaccess-protect 配置项，也不支持通过任何命令启用该功能——这是个常见误解，根源在于混淆了 Composer 职责与 Web 服务器配置边界。
为什么 htaccess-protect 在 composer.json 里无效
这个键名在官方 composer.json Schema、源码和文档中均不存在。它不是 Composer 的配置字段，也不会被 composer install 或 composer dump-autoload 解析或处理。
- 可能是某些过时插件（如已废弃的
fxp/composer-asset-plugin）遗留的误导性文档 - 也可能是把 Laravel / CodeIgniter 的部署脚本行为错误归因到 Composer 上
-
.htaccess是 Apache 特有机制，Nginx、Caddy、IIS 完全不识别，Composer 不可能跨服务器做这种适配
vendor 目录暴露的真实原因和修复方式
能通过浏览器直接访问 https://yoursite.com/vendor/autoload.php，说明 Web 根目录设错了，而不是“没开保护开关”。
- ✅ 正确结构：Web 服务器根目录指向
public/（或web/），vendor/和composer.json在其上级目录，天然不可达 - ❌ 错误结构：整个项目根目录（含
vendor/）被设为DocumentRoot，此时任何防护都是补救，非根本解法 - 若必须共存（极少见），才需手动加 Apache 规则：
RewriteRule ^vendor/ - [F,L]，且确认mod_rewrite已启用、AllowOverride All已配置
composer audit 才是 Composer 原生的安全能力
Composer 真正内置且可信赖的安全功能是依赖漏洞扫描，不是目录访问控制。
- 运行
composer audit可检查已安装包是否存在已知 CVE 或 GHSA 漏洞 - CI/CD 中建议加
--strict参数，使有漏洞时返回非零退出码，阻断发布流程 - 忽略特定漏洞可用
--ignore CVE-2021-1234，但应记录理由，而非默认跳过 -
config.audit.ignore可写入composer.json，但仅用于临时压制，不能替代升级
最易被忽略的一点：很多自动化部署（尤其是 GitHub Actions 或一键镜像）会把整个仓库克隆到 /var/www/html，却忘了把 Web 根目录切到 /var/www/html/public——这才是 90% 的 vendor 暴露案例的根源，和 composer.json 写什么都无关。
