composer 无法实现动画场景切换，它仅管理php依赖；所谓“多环境渲染”是误将solidworks composer、three.js等功能归因于php的composer命令。
Composer 本身无法实现动画过程中的场景切换——它不是动画工具，也不管理场景、渲染或时间轴。所谓“Composer 多环境渲染”“场景切换动画”，实际是把 SOLIDWORKS Composer、SimLab Composer 或前端 three.js 工具链的功能，错误归因到了 PHP 的 composer 命令上。
为什么 composer install 不会切换场景，也不会触发渲染
执行 composer install 只做三件事：读取 composer.json 和 composer.lock、下载包、生成 vendor/autoload.php。它不解析 .gltf、不加载 SceneTransition 类、不调用 render() 方法，更不会在时间轴上插入关键帧。
- 看到控制台报错 “Class not found: GraphView” 或 “Uncaught ReferenceError: ht is not defined”，说明你混入了图扑 HT 或其他前端 3D 库的代码，但没走
npm install流程，却指望 Composer 自动加载 JS 模块 -
composer update后页面白屏，大概率是前端构建产物（如/public/scenes/assembly.js）被破坏，而 Composer 根本不参与 JS 打包 - 任何名为
composer-scene-switch的包，只要类型是library而非composer-plugin，就只是普通 PHP 代码，无法干预场景逻辑
真正能做场景切换的工具链长什么样
多场景动画必须由具备时间轴、相机控制、资源加载能力的工具承担。Composer 在其中只负责后端依赖管理，且必须与前端解耦：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 前端场景层：用
npm管理three.js、@ht-graph3d/core，通过import('./scenes/battery-replace.js')动态加载不同场景模块 - 后端 API 层：放在
/api子目录，用 Composer 管理slim/slim、league/flysystem，仅提供元数据接口（如GET /scenes/config返回 JSON 描述） - 静态资源路由：Nginx 直接映射
/scenes/*到/public/scenes/，完全绕过 PHP，避免 Composer 干预文件分发 - 场景定义文件（如
battery-replace.json）可抽成独立 Git 包，用 Composer 的path类型仓库引入，但仅用于共享配置，不执行任何动画逻辑
如果硬要在 composer.json 里写“场景切换脚本”，要注意什么
你可以把 composer.json 当作一个命令调度入口，但必须清楚：Composer 不执行、不解释、不保证这些脚本和“场景”有关。
- 允许写：
"scripts": {"build-scene": "node build-scene.js --env=prod"}—— 这只是借壳调用 Node.js - 禁止写：
"scripts": {"scene:switch": "php scene-switcher.php"}并期望它自动加载 GLB、插值相机路径——PHP 没有 WebGL 上下文，也无帧循环机制 - 所有路径必须绝对明确：
node build-scene.js要能直接运行，不能依赖vendor/bin/下不存在的二进制 - CI 中执行前务必加
--no-ansi --no-progress --no-interaction，否则 ANSI 控制符会污染日志，导致后续 grep 或解析失败
最难的从来不是怎么写命令，而是分清哪部分该由 Composer 管、哪部分该交给 Nginx、Node 或 Three.js——一旦混淆职责，调试成本会指数级上升。比如，把场景切换逻辑塞进 post-install-cmd，结果发现每次装包都要等 30 秒渲染，却查不出是谁在后台调用了 ffmpeg。
