Vite与Laravel共存时，Composer源配置必须项目级而非全局，因Vite不依赖Composer，而Laravel的PHP依赖需精确源控制；CI/CD中全局镜像易致私有源解析失败，repositories须为数组、私有源置首、显式禁用packagist.org，并配合--no-cache和PHP版本一致性排查卡顿。
为什么Vite和Laravel共存时，Composer源配置不能只靠全局命令
因为Vite本身不依赖Composer，但Laravel项目里的PHP依赖（比如laravel/framework、spatie/laravel-permission）仍走Composer安装；而CI/CD流程中，composer install若读到全局镜像，可能因私有包域名解析失败或认证缺失直接中断——尤其当你的repositories里混着公司内网Satis源和阿里镜像时。全局配置composer config -g repo.packagist会强制所有项目走同一源，Vite构建脚本跑在容器里、PHP版本隔离时更易出错。
项目级repositories必须写成数组且顺序敏感
很多人把"repositories": { "packagist": { ... } }写成对象，结果Composer直接忽略——它只认repositories为数组。私有包源必须放在第一位，官方镜像放最后，中间加{"packagist.org": false}显式禁用默认源：
"repositories": [
{
"type": "composer",
"url": "https://packages.internal.corp"
},
{
"packagist.org": false
},
{
"packagist": {
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
}
}
]
注意三点：url末尾必须带/，否则404；{"packagist.org": false}是独立一项，不能塞进前一个对象里；删掉composer.lock再跑composer install，否则旧lock文件会绕过新源配置。
composer install卡住时先查是否漏了--no-cache或PHP小版本变动
Vite+Laravel混合项目常在Docker里跑，PHP版本微调（比如8.3.5→8.3.6）会导致Composer缓存失效，但错误日志只显示Downloading卡住，容易误判为镜像没生效。此时要：
- 运行
composer install --no-cache强制跳过本地缓存 - 检查
php -v输出和composer -V是否匹配，不同PHP SAPI（CLI vs FPM）可能加载不同php.ini，导致disable_functions禁用了proc_open - 确认
composer.json里没残留已下线的源，比如https://packagist.phpcomposer.com（2022年停更）
私有包+Vite前端资源共存时，别让Composer管理JS/CSS
有人想用Composer装twbs/bootstrap然后在Vite里import 'bootstrap'，结果路径错乱、CSS不生效——因为Vite的resolve.alias和Composer的vendor/目录结构不兼容。正确做法是：
- 前端库全走
npm install bootstrap @popperjs/core，Vite自动处理路径和tree-shaking - Composer只管PHP逻辑包，比如封装了API Client的
mycorp/http-client - 如果非要复用
vendor/里的JS（极少数遗留场景），得在vite.config.js里手动配resolve.alias指向node_modules或vendor子目录，但维护成本高
最易被忽略的点：Vite开发服务器启动后，composer install在另一个终端执行，两者共享同一vendor/目录，但Composer更新PHP类时不会触发Vite热更新——改完PHP包记得手动npm run dev重启，否则前端可能引用旧版类方法。
