public/css只应存放编译后的最终CSS文件，不得放入Sass源码、partial文件或未压缩开发版；小项目放app.css和custom.css，中型项目按core/modules/vendor分层，须用mix()或asset()正确引入，严禁手动复制或混入构建配置文件。

刚跑通php artisan serve，却在public/css里堆了8个命名混乱的CSS文件，页面样式错乱还找不到源头。

这不是代码问题，是目录结构没理清。

先搞懂public/css到底该放什么

public/css 里只应该放浏览器能够直接访问、而且已经编译完成的 CSS 文件。

【Sass/Scss 源文件、未压缩的开发版本，以及任何以下划线开头的 partial 文件，都不要放进来】

原因很直接：Lara vel 默认并不会帮你处理 CSS 编译。

你放进来的每一个 .css 文件，Web 服务器都会原封不动地交给浏览器，不会自动合并，也不会生成版本哈希，更谈不上条件加载。

如果你用Vite或Lara vel Mix编译前端资源，所有源码必须放在resources/css下。

public/css只是编译产物的“出口”。

把scss文件直接丢进public/css，它不会被编译。

它只会被当作普通文本暴露在公网。这既是安全风险，也是维护灾难。

小项目（1～3个页面）的极简结构

小项目直接在public/css下放两个文件即可：

• app.css：所有全局样式，如重置、基础排版、工具类
• custom.css：页面级覆盖样式，比如首页banner高度、登录页按钮圆角

不要建子文件夹，不要加版本号后缀，也不要分vendor.css和main.css。

小项目过早分层，只会让require路径变长，缓存失效也更难控制。

中型项目（含后台+多业务模块）的分层方案

中型项目可以按下面方式分层：

• 第一步：创建public/css/core/目录，放基础样式体系
• 第二步：创建public/css/modules/目录，每个业务模块一个CSS文件，如ticket.css、report.css、user-profile.css
• 第三步：创建public/css/vendor/目录，仅放第三方UI库的CDN fallback文件（如Bootstrap 5.3.3完整CSS），【禁止放未压缩的dev版或带source map的版本】
• 第四步：回到Blade模板里，按实际需要把样式引用切换一下即可： →

注意：mix()函数依赖webpack.mix.js配置，若未启用Lara vel Mix，这些路径会404。

此时应改用asset()，并确保文件真实存在于public/css下。

避免踩坑的硬性规则

• public/css里不能出现以_开头的文件（如_main.css），这是Sass partial约定，浏览器不会加载，但Git会同步，徒增混淆。
• 不要把tailwind.config.js或postcss.config.js放进来——它们属于构建工具链，必须留在项目根目录或resources目录下。
• 每次部署前运行npm run build（或yarn build），确保public/css下的文件是最新编译结果；手动复制CSS文件进去，会导致线上样式和本地开发不一致。

《夸克》非常好用的免费AI浏览器

下载APP查看