Lara vel 引入 Vite 编译：不是“共存”，而是“替换”
在 Lara vel 项目中引入 Vite，首先要明确一个核心概念：这通常不是“引入”，而是一场彻底的“替换”。关键在于，你需要关闭并移除原有的 Lara vel Mix，否则两个构建工具会同时争夺资源，导致缓存爆炸、热更新（HMR）完全失灵。
怎么让 Lara vel 用上 vite build 的产物
核心目标很明确：将 vite build 命令输出的静态文件路径，精准地对齐到 Lara vel 的 public/ 目录结构下，并确保 Blade 模板能够正确加载那些经过哈希处理的资源文件。
- 执行
vite build后，默认的构建产物会输出到public/build/目录。这个路径由vite.config.js文件中的build.outDir选项控制，而 Lara vel 内置的@vite指令默认也指向这里。 - 在 Blade 模板中，必须使用
@vite(['resources/js/app.js'])这样的指令，切忌手动编写的脚本，并连接本地的 Vite 开发服务器，这是实现热更新的基础。 - 生产环境：必须首先运行
vite build命令生成manifest.json文件。@vite指令会读取这个清单，将资源入口替换为带哈希的真实路径，例如assets/app.8a2f3bdc.js。 - 如果部署后页面出现白屏，且浏览器控制台报错
Failed to fetch dynamically imported module，十有八九是manifest.json文件没有生成、路径配置错误，或者忘记上传到服务器。
为什么 mix 和 vite 不能共存
根本原因在于它们的工作模式存在冲突。两者都会监听 resources/js/ 等目录的变动，并试图向 public/ 目录写入文件，但策略截然不同：Mix 倾向于硬拷贝并附加时间戳，而 Vite 则使用内容哈希并依赖 manifest 文件进行映射。这种冲突会直接体现在缓存机制、热更新流程以及 CDN 路径处理上。
立即学习“前端免费学习笔记（深入）”；
- 彻底清理 Mix：删除根目录下的
webpack.mix.js和node_modules/.bin/mix文件，并卸载lara vel-mix相关的 npm 包（但需保留lara vel-vite-plugin）。 - 确保脚本指向正确：检查
package.json文件，确认"scripts"部分中的"dev"命令指向的是"vite"。 - 迁移旧项目时的清理工作：别忘了清除
public/mix-manifest.json以及public/js/、public/css/等目录下由 Mix 生成的旧文件。否则，Nginx 或 Apache 服务器可能会错误地优先提供这些已过时的资源。
最后，有一个步骤最容易被忽略：在修改完所有配置后，没有运行 vite build 就直接部署上线。结果就是，页面加载的是未经哈希处理的开发版本 Ja vaScript 文件，缓存机制完全失效，问题还难以排查。请务必记住，Vite 构建产物的路径和加载逻辑，完全依赖于 manifest.json 这个文件来绑定。缺少它，就等于整个编译过程没有真正完成。
