Composer不直接管理前端依赖，因其专为PHP设计；正确做法是用Composer安装构建工具（如laravel/mix），由npm/yarn管理前端库并参与tree-shaking，确保职责分离、CI可复现。
Composer 本身不直接管理前端依赖，强行用它装 npm 包会绕过语义化版本、破坏构建流程、引发缓存和路径混乱——除非你明确需要 Asset Packagist 这类桥接方案，否则别这么做。
为什么不能直接 composer require bootstrap
因为 bootstrap 是 npm 包，不是 Composer 包。运行 composer require bootstrap 实际拉的是 npm-asset/bootstrap（通过 Asset Packagist 映射），但这个包：
- 版本号和 npm 上的不一致（比如 npm 的
5.3.3可能映射成5.3.3.0） - 文件结构是扁平化的
vendor/npm-asset/bootstrap/dist/，没做入口统一处理 - 无法参与 Webpack/Vite 的 tree-shaking 或按需 import
- 升级时容易和
package.json中的版本脱节，CI 构建失败率上升
正确做法：用 Composer 安装前端构建工具，而非前端库
Laravel 官方推荐路径是让 Composer 管构建链路，npm/yarn/pnpm 管前端依赖本身。例如：
-
composer require laravel/mix→ 安装 Mix 封装（PHP 侧集成） -
npm install bootstrap @popperjs/core→ 在package.json中声明真实依赖 - 在
resources/js/app.js里import 'bootstrap'，由 Mix 编译打包
这样 composer.lock 锁的是构建能力，package-lock.json 锁的是前端资源——职责清晰，CI 可复现。
立即学习“前端免费学习笔记（深入）”；
真要用 Composer 加载前端资源？只在三种场景下考虑
只有当满足以下任一条件时，才值得引入 Asset Packagist 或自定义 path 包：
- 项目完全无 Node.js 环境（如老旧服务器、某些嵌入式 PHP 部署）
- 团队拒绝维护
package.json，坚持“全 PHP 流程” - 私有 UI 组件库已打包为 Composer 包（含
public/静态资源 +autoload命名空间），且需被多个 Laravel 项目复用
此时必须手动配置 repositories 并确保 composer.json 中有 "type": "library" 和正确的 extra.installer-paths，否则资源不会自动复制到 public/。
常见报错：Basset 或 vendor:publish 后资源 404
这不是 Composer 没装好，而是路径映射断了。检查三处：
-
composer show backpack/basset是否显示type: library，不是project -
php artisan basset:install是否执行成功（它会创建public/vendor/basset/符号链接） - Blade 中是否用了
@basset('js/app.js')而非硬编码<script src="/js/app.js">—— 后者绕过 Basset 的去重和哈希机制
最易忽略的一点：APP_ENV=production 下，Basset 默认不启用开发模式的实时编译，得先 php artisan basset:build 才生成哈希文件。
