因为脚本工作目录不一定是项目根目录，直接 require 'vendor/autoload.php' 会因路径错误失败；应使用 dir . '/../../vendor/autoload.php' 动态定位并判断文件存在后再加载。
Composer脚本里为什么require 'vendor/autoload.php'会失败
因为 Composer 脚本（如 post-install-cmd）运行时，当前工作目录不一定是项目根目录，而 vendor/autoload.php 是相对路径加载的。脚本可能在子目录、CI 工作区或临时路径下执行，require 'vendor/autoload.php' 直接写死会报 failed to open stream: No such file or directory。
- 永远用
__DIR__或getcwd()动态定位：优先用__DIR__ . '/../../vendor/autoload.php'（假设脚本在scripts/下） - 更健壮的方式是调用 Composer 自带的 autoloader 查找逻辑：
if (file_exists($autoload = __DIR__ . '/../../vendor/autoload.php')) { require $autoload; } - 不要依赖
getcwd()—— 它可能被 shell 环境或 CI 工具篡改，尤其在多阶段构建中不可靠
在 composer.json 的 scripts 里怎么安全引入 autoload
直接在 JSON 中写 PHP 代码不可行，所以必须把逻辑抽到独立 PHP 文件中，再通过 php scripts/my-script.php 调用。关键在于这个 PHP 文件开头的加载方式。
- 推荐结构：
scripts/deploy.php开头三行固定写法：#!/usr/bin/env php <?php require __DIR__ . '/../vendor/autoload.php';
- 如果脚本位置不确定（比如被 symlink 或移动过），用
dirname((new ReflectionClass('Composer\Autoload\ClassLoader'))->getFileName()) . '/../../../autoload.php'反向定位 —— 但太重，仅限极端场景 - 避免在脚本里重复调用
ComposerAutoloaderInit类，它已由 autoload.php 执行过，二次 require 会触发 fatal error
为什么用 include_once 而不是 require 不可靠
include_once 在 Composer 脚本上下文中容易静默失败：它不抛出致命错误，但后续类找不到时才报 Class not found，排查成本高。
- 一律用
require+ 显式存在性判断，失败时主动die("Autoloader not found at " . $path) - 某些共享 host 或旧版 PHP（如 7.2）对
__DIR__解析有缓存 bug，可加clearstatcache(true, $path)前置校验 - 若项目启用
optimize-autoloader，autoload.php 内部结构不变，不影响脚本加载逻辑 —— 这点可以放心
CI/CD 中执行 Composer 脚本时 autoload 加载失败的典型表现
GitHub Actions、GitLab CI 经常出现 Class 'Symfony\Component\Console\Application' not found，根本原因不是没装包，而是脚本没加载 autoloader，或者加载了但用了错误路径。
- 检查 CI 日志是否真执行了
composer install—— 有些 pipeline 跳过了，导致 vendor 为空 - Docker 构建中，如果
COPY . /app后没运行composer install，autoload.php根本不存在 - GitLab CI 的
before_script若覆盖了COMPOSER_HOME，可能让 autoload.php 生成到非预期位置，需显式指定--no-interaction --working-dir=/app
+x 权限时，php scripts/deploy.php 会被 shell 当作普通文件执行，报 Permission denied，而不是 PHP 错误 —— 这时候 autoload 根本没机会运行。
