典型错误是Failed to extract vendor/symfony/console: unable to open archive或Content-Length mismatch，表明ZIP包被截断或校验失败，触发底层解压器panic，导致autoload.php加载失败、类找不到或autoload_classmap.php读取崩溃。
Vendor包损坏的典型错误现象
生产环境突然报错，日志里出现 Failed to extract vendor/symfony/console: unable to open archive 或 Content-Length mismatch，甚至 PHP 进程直接 segfault —— 这不是代码问题，是 Composer 下载的 ZIP 包被截断或校验失败后残留的“半截包”在运行时触发了底层解压器 panic。它不总报错，但一旦发生，autoload.php 可能加载失败、类找不到、或 vendor/composer/autoload_classmap.php 读取时崩溃。
别删 vendor/，先确认损坏来源
盲目 rm -rf vendor/ 在生产环境风险极高：它会清空 autoloader 缓存结构，下次 install 耗时翻倍；若同时存在未提交修改（比如 patch 过的私有包），还会丢失现场状态。
- 先运行
composer install --dry-run --verbose：看卡在哪一个包的extract步骤，输出里会明确显示Extracting archive后跟失败路径 - 再查缓存是否真坏：进
~/.composer/cache/files/，按包名找对应 ZIP 文件，用unzip -t <file>手动测试完整性 - 检查
composer.lock中该包的"dist": {"sha256": "..."}，和 vendor/ 下实际文件算出的 SHA256 是否一致（可用sha256sum vendor/package/*粗略比对）
生产环境安全修复三步法
目标是零停机、不改 lock、不重算依赖树。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只删损坏包的缓存 ZIP：
rm -f ~/.composer/cache/files/vendor/package-name/*（Linux/macOS），Windows 用del /s /q %COMPOSER_HOME%\cache\files\vendor\package-name - 强制跳过缓存重拉：
composer install --no-cache --no-scripts --no-dev（加--no-scripts防 post-install-cmd 意外触发） - 验证 autoload 结构：
php -d display_errors=1 -d error_reporting=-1 vendor/autoload.php—— 若无输出即成功；若有 fatal，则说明 vendor/composer/ 目录结构已损，需补composer dump-autoload
镜像源与缓存协同失效的隐藏坑
换过镜像（比如从阿里云切到腾讯云）但问题依旧？大概率是旧镜像的 packages.json 快照还躺在缓存里，Composer 仍按过期索引找包。
必须同步清理两处：composer clear-cache 清 ZIP，再手动删 ~/.composer/cache/repo/ 下所有 packagist.org 相关目录（或整个 repo/），否则 composer install 仍会尝试从已下线的 dist URL 下载。
最易被忽略的是：PHP 进程用户（如 www-data）和执行 composer 的用户权限不一致，导致部分 vendor/ 子目录属主为 root，而 Web 服务无法读取 —— 这种“损坏”根本不会报 ZIP 错误，而是静默 class not found，得靠 ls -l vendor/ 查属主。
