Composer不处理模型渲染，所谓“更新模型后渲染模式丢失”实为前端三维引擎（如Three.js）、可视化库或CMS模板配置错误所致，与Composer本身无关。
Composer 不处理模型渲染，所谓“更新模型后渲染模式丢失”是典型的概念混淆——你更新的不是 Composer，而是前端三维引擎（如 Three.js）、可视化库或 CMS 的模板配置。Composer 只负责 PHP 类库的安装与自动加载，它不会碰 GLB 文件、Shader 代码、Blender 导出设置或 Vue 组件里的 <model-viewer></model-viewer> 属性。
为什么 composer update 后模型不渲染了
根本原因几乎总是以下之一：
- 前端构建产物被清空或未重新打包：比如
composer update触发了post-update-cmd脚本，误删了public/build/或没运行npm run build - 模型文件路径硬编码在 PHP 模板里，但实际文件被移出版本控制（例如从
resources/assets/models/移到storage/app/models/），而链接逻辑没同步更新 - 依赖升级导致前端库行为变更：比如
three@0.152.0升级到0.153.0后默认禁用dracoLoader，而你的 GLB 是 Draco 压缩格式，结果静默失败 - Laravel Mix/Vite 配置中漏掉了
copy()或publicDir映射，composer update后构建流程没重跑，public 目录下压根没有models/gear.glb
快速验证是否真和 Composer 有关
打开浏览器开发者工具，切到 Network 标签页，过滤 glb 或 gltf，看模型请求返回什么：
- 404 → 问题在 Web 服务器路径或构建脚本，不是 Composer
- 200 但控制台报
THREE.GLTFLoader: Couldn't load DRACO module→ 是前端库版本/插件配置问题 - 200 + 模型加载成功但旋转/光照异常 → 渲染逻辑（如
OrbitControls初始化顺序、材质属性）被新依赖覆盖 - 请求卡住或超时 → 检查是否误把模型放进了
vendor/目录（Composer 不会复制它，且 vendor 不该被 Web 服务器直接访问）
修复步骤：跳过 Composer，直击源头
别再重装 Composer 或删 composer.lock —— 这些操作对渲染毫无作用。按顺序执行：
- 确认模型物理存在：
ls -l public/models/your-model.glb（Linux/macOS）或dir public\models\your-model.glb（Windows） - 检查构建命令是否执行：
npm run dev或php artisan vite:build，确保输出目录含模型文件 - 若用 Laravel Storage，改接口返回：
Storage::disk('public')->url('models/your-model.glb')，而不是拼接asset('models/...') - 前端加载器显式启用依赖：比如 Three.js 中加
DRACOLoader.setDecoderPath('/js/draco/');，路径需真实可访问 - 临时禁用所有
post-update-cmd脚本，用composer update --no-scripts测试是否脚本干扰了构建
真正容易被忽略的是：很多项目把模型加载逻辑写在 Blade 模板里，用 @include('partials.model-viewer', ['slug' => $model->slug])，而这个 partial 里又用了 asset("models/{$slug}.glb") ——一旦 $model->slug 返回空值或非法字符，URL 就变成 /models/.glb，404 且无提示。这种错误不会出现在 Composer 日志里，只会出现在浏览器 Network 面板里。
