Composer没有htaccess-protect等vendor保护配置项，vendor目录安全取决于Web服务器根目录设为public/及对应服务器规则（如Apache的RewriteRule或Nginx的location deny），而非composer config命令。
composer config 不能设置 vendor 目录的“保护开关”
Composer 没有 htaccess-protect、vendor-protect 或任何类似名称的配置项，composer config 命令也完全不提供 vendor 安全防护能力。所谓“全局 vendor 保护机制”，不是靠一条命令就能开启的功能——它根本不存在于 Composer 的设计中。
常见错误现象包括：在 composer.json 里写 "config": {"htaccess-protect": true}，执行 composer install 后毫无反应；或误以为 composer config --global 能统一拦截所有项目的 vendor 访问。
-
composer config只能设置如bin-dir、process-timeout、allow-plugins等运行时参数，vendor-dir是唯一例外，但它只控制安装路径，不涉及访问控制 - Web 层面的 vendor 暴露问题（如能直接访问
https://site.com/vendor/autoload.php）永远是部署结构或服务器配置问题，和composer config输出无关 - 试图用
composer config --global设置某种“全局防护规则”，结果既不会生成.htaccess，也不会修改 Nginx 配置，更不会影响$_SERVER['DOCUMENT_ROOT']
真正起作用的是 Web 服务器配置 + 目录结构
vendor 目录是否可被 Web 访问，只取决于两件事：Web 服务器根目录（DocumentRoot / root）指向哪，以及该路径下是否存在允许访问 vendor 的显式规则。
例如 Apache 下，即使你删光所有 .htaccess 文件，只要 DocumentRoot 指向项目根目录，/vendor/ 就天然可访问；反之，若 DocumentRoot 指向 public/，vendor 就根本不在 URL 地址空间内，无需任何“保护”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- ✅ 正确做法：把 Web 根目录设为
public/或web/，确保vendor/在其上级目录（如../vendor/） - ✅ Apache 补充防护（仅限启用
mod_rewrite且AllowOverride All的环境）：RewriteRule ^vendor/ - [F,L] - ✅ Nginx 补充防护：
location ~* ^/vendor/ { return 403; } - ❌ 错误做法：依赖
composer install自动生成防护文件，或幻想某条composer config命令能重写服务器配置
为什么“项目级全局保护”这个说法本身矛盾
“项目级”和“全局”在 Composer 配置体系里是互斥概念：composer.json 中的 config 是纯项目级，--global 是用户级（影响所有项目），但两者都只管 Composer 自身行为，不管 Web 服务暴露面。
你无法通过 composer.json 让 Laravel 项目自动给 Nginx 写 location 块，也不能让 Symfony 项目在部署时自动改 Apache 的 DocumentRoot——这些属于运维职责，不是 Composer 的能力边界。
- 项目级配置（
composer.json）只对当前项目composer install生效，比如"vendor-dir": "lib/vendor"，但它不改变 Web 可达性 - 全局配置（
composer config --global）可以设镜像源、token、bin-dir，但对 vendor 是否暴露零影响 - 真正需要“全局生效”的防护（如所有项目都禁访 vendor），得统一管理 Web 服务器配置，或统一部署结构（全部用
public/作根目录）
最容易被忽略的部署环节
90% 的 vendor 暴露问题，不是因为没配 .htaccess，而是 CI/CD 脚本或一键部署工具把整个 Git 仓库克隆到 /var/www/html/，却忘了把 Web 服务器的根目录从 /var/www/html 切到 /var/www/html/public。
此时无论你在 composer.json 里写多少配置、跑多少 composer config 命令，vendor 都会直接挂在 https://example.com/vendor/ 下。检查方式极其简单：
- 访问
https://yoursite.com/vendor/composer/installed.json，能返回 JSON 就说明已暴露 - 运行
php -r "echo \$_SERVER['DOCUMENT_ROOT'];"，对比实际项目路径 - 确认 Web 服务器进程（如
nginx -t或apachectl -S）加载的配置中root/DocumentRoot值
