vendor目录不能chmod 777，因其混有autoload.php、PHP类文件及vendor/bin下的可执行脚本（如phpunit），设为777会使全局可写，易被攻击者利用代码执行漏洞覆盖关键文件或注入恶意类；CI平台与安全扫描工具会直接拒绝构建或标记高危；Git提交时亦报ownership changed干扰diff；且不解决根本问题——属主仍为root，下次composer update仍失败。
vendor目录为什么不能chmod 777
因为vendor/里混着autoload.php、PHP类文件、vendor/bin/下的可执行脚本（比如phpunit），设成777等于把写权限交给所有人。一旦应用存在任意代码执行漏洞，攻击者就能覆盖vendor/composer/autoload_static.php或注入恶意类——这不是假设，真实入侵链里常见。
CI平台和安全扫描工具（如SonarQube）看到chmod -R 777 vendor/会直接拒绝构建；Git提交时还会报ownership changed干扰diff；更关键的是，它不解决根本问题：属主仍是root，下次composer update照样失败。
- 别递归
chown -R整个vendor/（可能破坏Phar包或符号链接） - 稳妥做法分两步：
rm -rf vendor/ composer.lock，再用当前用户重装composer install - 若
composer.lock不能删（如CI部署），至少先修正目录本身：sudo chown $USER:$USER vendor/ && chmod u+w vendor/
沙箱必须分进程，不能靠autoload隔离
PHP没有类加载器隔离机制，composer/autoload.php是静态映射文件，一旦include进来，它注册的PSR-4映射就全局生效。同一进程里加载两套vendor/，大概率触发Fatal error: Cannot redeclare class或Class not found。
replace、provide、conflict只影响安装阶段解析，不改变运行时行为；COMPOSER_VENDOR_DIR改的是写入位置，不是加载隔离。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 真正可行的是分进程+独立
vendor/：每个沙箱对应一个子目录（如./sandboxes/v1/），内含独立的composer.json、vendor/和入口脚本 - 主进程用
proc_open()或shell_exec()启动子进程，传参并捕获stdout/stderr，例如：php ./sandboxes/v1/bin/run.php --input=xxx - 子进程启动前清空
get_defined_constants()中可能污染的常量（如APP_ENV），避免配置泄漏
autoload_dev.php是沙箱里的隐藏雷区
哪怕你用了--no-dev安装，只要composer.lock里还存着dev包记录，或者vendor/composer/autoload_dev.php文件没删干净，沙箱进程就可能加载到测试类或调试工具，引发线上环境报错。
构建沙箱时必须执行：composer install --no-dev --optimize-autoloader --no-scripts，再手动确认vendor/composer/autoload_dev.php不存在。
- 检查
composer.json的autoload-dev字段是否为空，否则dump-autoload仍会写入映射路径 - 不要在沙箱内
require主项目代码——它可能隐式依赖主vendor/，应只暴露明确接口（如JSON输入/输出） - 沙箱入口脚本开头加
unset($GLOBALS['argv'], $GLOBALS['argc']);，防止参数污染
vendor目录不能移走或软链共享
vendor是Composer硬编码路径，不是配置项。"config": {"vendor-dir": "libs"}会引发一连串隐性断裂：IDE（如PHPStorm）默认只索引vendor/，改路径后跳转、补全失效；静态分析工具（PHPStan、Psalm）默认扫描vendor/，不加额外配置就报“未找到依赖类型”；CI脚本、Dockerfile大多写死vendor/autoload.php，改了就得全局搜改。
vendor/bin/下的命令（如phpunit）内部硬编码了相对路径，移走后执行直接报错；vendor/monolog/monolog这种双层路径由Packagist包的name字段硬编码生成，大小写不一致会导致路径错位、类找不到。
- 多个PHP项目共用一个
vendor目录？不能。每个项目必须有自己独立的vendor/和composer.json - 看到
require_once(): Failed opening required 'vendor/autoload.php'，第一反应不是改路径，而是查当前工作目录是否正确 - 上线、CI/CD、换机器拉代码时，必须用
composer install，而非composer update——后者会忽略composer.lock，导致版本漂移
