必须通过proc_open启动独立进程、新建临时vendor目录并配合--no-scripts--no-plugins三者协同实现隔离，缺一不可。
如何安全运行第三方 post-install-cmd 脚本
不能在当前进程里直接执行，因为 post-install-cmd 会共享全部 PHP 运行时状态：已加载类、autoload 单例、$_ENV、getcwd()，甚至能覆盖 vendor/autoload.php 或写入 web 可访问路径。哪怕禁用 exec，它仍可通过 file_put_contents、eval()、opcache_reset() 等方式逃逸。
真正可行的隔离方式只有三者同时生效：
- 用
proc_open()启动全新子进程（不是shell_exec） - 为待测包新建临时目录（如
./sandbox-123/），内含精简composer.json和独立vendor/ - 执行时必须带
--no-scripts --no-plugins --optimize-autoloader，且顺序不能颠倒——composer install --no-scripts是无效参数写法
为什么 vendor/bin 软链不等于沙箱
vendor/bin 是 Composer 源码级硬编码的符号链接目标，不是靠配置生效。它的“安全性”其实来自项目边界约束，而非路径校验：Composer 创建软链时完全不检查目标路径是否属于当前 vendor/ 子树。如果某个恶意包在 composer.json 中声明 "bin": ["/tmp/malware"]，composer install 仍会照常创建指向该路径的链接。
真正起作用的是三重约束：
-
vendor/目录设为只读（生产环境） -
composer.lock提交 Git 并经人工审核 - CI 流水线中禁用
composer update
一旦脱离这些前提，vendor/bin 就只是个表层符号链接，没有实质防护能力。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
用 -vvv --no-cache 定位内存爆炸点
composer install -vvv --no-cache 是唯一能暴露真实崩溃位置的组合。-vvv 会打印底层堆栈，比如 in phar:///src/RuleWatchGraph.php on line 52 —— 这就是 SAT 求解器内存耗尽的铁证；而 --no-cache 能排除本地缓存干扰，确认是解析卡死还是源不可达。
常见线索包括：
- 日志末尾密集出现
Reading /path/to/vendor/some/package/composer.json→ autoload 映射有风险（如 psr-4 错配到整个vendor/） - 卡在
Resolving dependencies后无输出，最后一行停在RuleSetGenerator→ SAT 阶段内存溢出 - 加
--no-plugins --no-scripts后不再崩 → 问题出在某个post-install-cmd（如 phpstan 自动扫描）
Docker 构建中如何避免沙箱失效
多阶段构建本身不是沙箱，但能配合隔离策略落地。关键动作不是“怎么写 RUN”，而是“谁有权修改 vendor/”。实操上必须做到：
- 第一阶段用非 root 用户执行
composer install --no-dev --no-scripts --no-plugins -
COPY --from=composer只复制vendor/目录，不复制composer.json或composer.lock到最终镜像 - 禁止在第二阶段执行任何
composer命令——生产镜像里不该存在composer.phar - 私有包认证必须通过
DOCKER_BUILDKIT=1+secret挂载，绝不能硬编码 token 或写进auth.json
最易被忽略的点：Docker 构建缓存会掩盖 vendor/ 权限变更。如果某次构建后 vendor/ 被意外写入，后续缓存层会继承该状态——必须在每轮构建前显式 chown -R app:app vendor/ 并设为只读。
