Composer 不会主动破坏环境，但误用命令、共享 vendor 目录或忽略约束求解会导致环境不一致、类加载失败；每个项目须有独立根目录和 composer.json，禁用全局 COMPOSER_VENDOR_DIR，私有模块冲突需在对应路径下执行 composer why-not，锁文件失效时应运行 composer update --lock 修复，classmap-authoritative 要求显式声明 autoload 路径且需重生成 classmap。
Composer 本身不会“破坏”环境，但当你忽略它的约束求解机制、误用命令或共享 vendor 目录时，它会忠实地执行你给的指令——而这个结果，往往就是环境不一致、类加载失败、线上报错。
composer install 覆盖其他项目 vendor 的真实原因
这不是 Composer 故意搞破坏，而是它只认当前目录下的 composer.json 和 composer.lock，并默认把所有包装进同级 vendor/。一旦你在父目录（比如 /var/www/）运行 composer install，或者多个项目共用一个 COMPOSER_VENDOR_DIR 环境变量，它们就会往同一个物理路径写入。
后果是：项目 A 的 autoload.php 生成时映射了 v2.9.3 的 monolog/monolog，而项目 B 运行时却加载了这个文件——哪怕它本该用 v3.0.0。方法不存在、类名错位、Class not found 全都由此而来。
- 每个项目必须有独立根目录，且含自己的
composer.json - 禁用
COMPOSER_VENDOR_DIR全局配置，它会让多项目写入同一位置 - 不要用软链接把不同项目的
vendor/指向同一处——autoload 映射是静态生成的，不是运行时动态解析的
为什么 composer why-not 在主项目里查不到私有模块的冲突源
因为 composer why-not 只查当前目录下 composer.json 声明的约束，以及已安装包的元信息。如果你的私有 SDK 是通过 path 类型仓库本地加载的（如 "repositories": [{"type": "path", "url": "./packages/private-sdk"}]），那它的版本约束只存在于 ./packages/private-sdk/composer.json 里，主项目根本“看不到”。
典型现象：主项目报 don't install guzzlehttp/guzzle:^7.5，但在主项目目录跑 composer why-not guzzlehttp/guzzle:^7.5 却返回 “no matching packages”。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须
cd ./packages/private-sdk，再执行composer why-not guzzlehttp/guzzle:^7.5 - 如果输出
your-private-sdk dev-main requires guzzlehttp/guzzle "7.4.5"，说明问题就在私有模块自己钉死了版本 - 私有模块的
require字段禁用精确版本（如"7.4.5"），改用语义化范围（如"^7.2 || ^8.0"），前提是代码真能兼容
生产环境报 “Your requirements could not be resolved” 怎么紧急修复
这不是网络或权限问题，而是 composer.lock 已失效：可能被手动删过、Git 合并时损坏、CI 构建用了 --ignore-platform-reqs 导致锁文件不合法。此时任何 composer install 或 composer update 都可能让环境进一步失控。
唯一安全操作是 composer update --lock：它只读取当前 composer.json，重新生成合法 composer.lock，完全不动 vendor/ 目录。
- 先确认线上
composer.json是最新且无语法错误的（比如从 Git tag 检出） - 执行
composer update --lock，预期输出应为Lock file operations: 0 installs, 0 updates, 0 removals - 若出现大量
Updating xxx，说明composer.json还没对齐，得先拉代码再试 - 生成新 lock 后立刻提交，否则下次部署又回到原点
classmap-authoritative 开启后 Class not found 的真正原因
启用 --classmap-authoritative 后报 Class not found，不是 autoloader 没生效，而是那个类根本没被收录进 vendor/composer/autoload_classmap.php。Composer 只会把 composer.json 中 autoload 或 autoload-dev 显式声明的路径下的类扫进去。
常见漏收场景：
-
"App": "app/"写成"App": "app"（末尾少反斜杠，路径拼错） - 新加的类放在未声明的目录，比如
app/Support/Helper.php，但 autoload 里只写了"App": "app/" - 用了
"files"类型加载全局函数，这类文件不会进 classmap，但启用--classmap-authoritative后仍可工作——别误以为所有 autoload 都走 classmap -
--no-dev下autoload-dev规则全失效，测试类路径不会被扫描
最易被忽略的一点：classmap 是构建时快照，不是运行时扫描。改了代码不重跑 composer dump-autoload，新类永远进不了 classmap —— 尤其在 CI 部署流程里，这步常被跳过。
