Composer install 不支持管理非 PHP 静态文件依赖，因其设计目标仅为安装 PHP 包；静态资源应交由 npm/yarn/Vite 等前端工具链处理，PHP 后端专注 API 与模板渲染。
composer install 本身不支持管理非 PHP 的静态文件依赖（如 CSS、JS、字体、图片等）。它只负责解析 composer.json 中的 require 字段，下载 Packagist 上注册的 PHP 包，并写入 vendor/ 目录。静态资源不是 Composer 的设计目标。
如果你看到某些项目把 Bootstrap、jQuery 等前端库放在 vendor/ 下，那通常是历史遗留做法或通过非标准手段“绕过”限制实现的，不推荐在新项目中复用。
为什么不能直接用 composer install 下载静态文件
- Composer 的包发现机制依赖 Packagist 元数据，而该元数据要求包必须含 PHP 代码（至少有
autoload配置），否则会被拒绝收录； - 即使手动写一个含
"type": "library"的包并托管在私仓，Composer 也不会自动把其中的dist资源解压到 Web 可访问路径（比如public/css/）； -
composer install不执行任意 shell 命令，也不提供资源复制、重命名、路径映射等能力 —— 这些得靠额外工具或脚本补足。
替代方案：用 Composer 触发外部工具完成静态文件交付
你可以把 Composer 当作“事件触发器”，借助 scripts 字段调用其他工具来拉取、提取、复制静态文件：
- 使用
npm或yarn管理前端依赖，再通过post-install-cmd把构建产物拷贝进public/； - 用
curl+unzip在post-install-cmd中下载 CDN 上的压缩包（不推荐，不可靠且难审计）； - 利用
composer/installers插件（需显式 require），它支持将特定 type 的包安装到自定义路径，例如：-
"type": "webroot"→ 安装到public/ -
"type": "wordpress-plugin"→ 安装到wp-content/plugins/
components/jquery这类老包，已基本停更）。 -
实操建议：别让 Composer 扛静态文件的事
- 前端资源走
package.json+npm install+ 构建流程（Vite/Webpack），输出到public/build/； - PHP 后端只管 API 和模板渲染，静态资源由 Web 服务器（Nginx/Apache）直接服务；
- 如果你真需要“一键拉取前端库”，用
composer require npm-asset/bootstrap（基于fxp/composer-asset-plugin的旧方案）——但该插件已废弃多年，PHP 8.2+ 下大概率报错，且不再被维护。
真正可靠的边界在这里：Composer 负责 PHP 依赖的可重现安装；静态文件交付是构建层或部署层的事。混在一起，迟早会在 CI、共享主机或 Docker 多阶段构建里踩坑。
立即学习“PHP免费学习笔记（深入）”；
