@composer是Composer内置别名，强制调用当前运行的composer进程以保证版本、插件和配置一致；它不读项目内composer.phar或系统PATH，必须在scripts中以数组形式使用（如["@composer","update"]），不可拼接字符串，且参数透传无条件追加。
为什么@composer不是调用当前项目里的 composer.phar
@composer 是 Composer 内置的“命令别名”，它不指向你项目目录下的 composer.phar，也不读取当前 shell 的 $PATH；它强制调用 Composer 自身进程（即正在运行的那个 composer 可执行文件）——这保证了版本一致、插件可用、配置生效。常见误判是：在 CI 环境里手动下载了旧版 composer.phar 并 alias 成 composer，结果 @composer install 仍走系统全局安装的 2.5.x，行为不一致。
@composer 在 scripts 中怎么写才安全
必须作为数组第一个元素，不能拼在字符串里：
- ✅ 安全写法：
"update-deps": ["@composer", "update", "--with-dependencies"] - ❌ 危险写法：
"update-deps": "@composer update --with-dependencies"（会被当 shell 字符串执行，@composer失效，退化为裸composer命令） - ⚠️ 注意：数组形式下，参数不能含空格或特殊字符；如需动态路径，改用 PHP 脚本封装
什么时候不该用@composer
以下场景直接调用 composer 更合适，或应避免嵌套：
- 脚本本身已是 PHP callable（如
"build": "My\Build::run"），再用@composer启动新进程属于冗余开销 - CI 流水线中明确要求锁定 Composer 版本（如
composer:2.4.4Docker 镜像），此时@composer会绕过镜像约束，用容器内默认版本 - 需要捕获子进程退出码做分支判断时，
@composer的错误传播不如原生命令直观（例如@composer install || echo "fail"在数组格式中无法直接表达）
传参给@composer命令的边界问题
@composer 本身不解析 -- 后参数；它的参数透传规则和普通数组脚本一致：
- 定义：
"ci-install": ["@composer", "install", "--no-interaction"] - 调用：
composer ci-install -- --prefer-dist→ 实际执行的是composer install --no-interaction --prefer-dist - ⚠️ 关键限制：无法把
--之后的参数“部分透传”；所有--后内容都会追加到数组末尾，没有条件过滤机制 - 若需动态参数组装（比如根据环境加
--with-all-dependencies），必须改用 PHP 脚本 +proc_open()控制
复杂点在于：你以为在复用 Composer 进程，其实是在复用它的加载上下文（包括插件、事件监听器、全局 config）。一旦脚本里混用 @composer 和 shell 调用，或在不同生命周期钩子里反复触发，容易出现 autoload 冲突、事件重复注册、临时目录残留等问题。这些不会报错，但会让 post-autoload-dump 类钩子行为不可预测。
