应本地构建后上传：运行 composer install --no-dev --optimize-autoloader，确保PHP版本与主机一致，检查文件权限、autoload路径及用 test-autoloader.php 验证。
共享主机上无法运行 composer install 怎么办？
大多数共享主机（如 cPanel、SiteGround、Bluehost）默认禁用 shell 访问，或限制 exec()、proc_open() 等 PHP 函数，导致直接在服务器上运行 composer install 报错：command not found 或 proc_open() has been disabled。这不是 Composer 本身的问题，而是主机安全策略的限制——你不能指望它像 VPS 那样自由执行命令。
解决方案只有一条路：本地构建好完整可运行的代码包，再上传。关键不是“怎么在服务器装 Composer”，而是“怎么绕过服务器执行 Composer”。
本地 composer install --no-dev --optimize-autoloader 必须加这俩参数
你在本地开发机跑 composer install 时，默认会装 require-dev 里的包（如 PHPUnit、phpstan），并生成未优化的 autoloader。这些在生产环境不仅没用，还可能引发权限、路径或兼容性问题（比如共享主机 PHP 版本较低，而某个 dev 包依赖高版本语法）。
-
--no-dev：跳过所有require-dev依赖，减小体积、避免冲突 -
--optimize-autoloader（简写-o）：生成classmap映射，提升加载速度，且不依赖opcache.file_cache等共享主机常关闭的配置 - 额外建议加
--apcu-autoloader（如果主机启用了 APCu）——但先用phpinfo()确认，否则会报Class 'ApcuClassLoader' not found
vendor/ 上传后出现 Class not found 的常见原因
即使 vendor 目录完整上传，仍报错，大概率是 autoloader 没生效或路径错位。共享主机常有以下陷阱：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 文件权限问题：
vendor/和vendor/autoload.php必须可读（644），目录必须可执行（755）；某些主机对0755目录仍拒绝遍历，可尝试0775 - PHP 版本不匹配：本地用 PHP 8.2 装的包，上传到仅支持 PHP 7.4 的主机 → 运行时报
syntax error, unexpected token；务必在本地用目标主机同版本 PHP 运行composer install -
autoload.php路径写死：检查你的入口文件（如index.php）是否用require __DIR__.'/vendor/autoload.php';—— 如果项目不在根目录，或通过子目录访问，相对路径极易出错；推荐改用require_once dirname(__DIR__).'/vendor/autoload.php';或绝对路径（配合$_SERVER['DOCUMENT_ROOT']）
如何验证 vendor/ 是否真的可用？
别等上线后才发现问题。上传后，立即在服务器建一个临时测试脚本（比如 test-autoloader.php）：
<?php
require_once 'vendor/autoload.php';
var_dump(class_exists('Monolog\Logger')); // 替换为你项目实际用到的一个类
?>
如果返回 bool(true)，说明 autoloader 工作正常；如果报错，优先检查上述三点：权限、PHP 版本、路径。很多用户卡在这里反复重传 vendor/，其实问题根本不在文件本身，而在运行环境与加载逻辑。
真正麻烦的从来不是“怎么传”，而是“传完之后谁来保证它真能跑”——尤其当主机不给你 php -v 或 ls -la 权限时，每一步都得靠这种最小化验证兜底。
