如何搭建使用HTML、CSS/Tailwind与Laravel的Web开发项目结构

一、基础环境初始化 #

• 直接通过Composer安装全新Laravel框架即可，不要用来源不明的第三方一键整合包，避免后续出现依赖兼容问题：

  composer create-project laravel/laravel your-project-name
  

• Tailwind CSS不要直接引CDN用于生产环境，走NPM依赖安装适配Laravel的版本即可，核心安装命令：

  npm install -D tailwindcss postcss autoprefixer
  npx tailwindcss init -p
  

• 修改tailwind.config.js的内容扫描路径，覆盖所有Blade模板、JS文件目录，避免生产构建时漏掉用到的样式：

  export default {
    content: [
      "./resources/**/*.blade.php",
      "./resources/**/*.js",
    ],
    theme: {
      extend: {
        // 这里统一配置全局主色、辅助色、圆角、间距等设计Token
      },
    },
    plugins: [],
  }
  

• 全局样式入口统一用resources/css/app.css，只保留Tailwind核心引入指令，零散自定义样式不要直接堆在这个文件里：

  @tailwind base;
  @tailwind components;
  @tailwind utilities;
  

• 开发阶段直接跑npm run dev开启Vite热更新，改完样式、模板实时生效；上线前执行npm run build即可自动完成资源压缩、无用样式剔除，打出最优生产包。

二、核心目录结构规范 #

严格遵循Laravel默认目录约定即可，不要随意改动框架核心目录结构，最大程度降低团队协作的上手成本：

• 后端逻辑层
  • 控制器统一放在app/Http/Controllers下，按业务模块分子目录，比如前台、后台、用户中心分别建对应文件夹，控制器只做参数接收、响应返回，不要堆几百行的核心业务逻辑。
  • 数据模型统一放在app/Models下，模型关联、字段转换、搜索器逻辑全部收敛到模型内部，不要散落在控制器里。
  • 复杂业务逻辑单独抽离到app/Services目录封装，控制器直接调用服务层方法即可。
  • 路由按模块拆分，不要把所有路由全堆在web.php单文件里，前后台路由分别加前缀、绑定对应中间件。
• 前端视图层（全部放在resources/views目录下）
  • layouts目录存放全局布局文件，比如前台公共布局、后台管理布局，把公共的meta配置、资源引入、导航栏、页脚全部写在布局里，业务页面直接继承布局即可，不用重复写公共结构。
  • components目录存放所有可复用Blade组件，比如按钮、表单项、弹窗、卡片、分页器这些跨页面复用的UI块，重复用到的样式组合直接封装成组件，避免重复写结构和样式。
  • pages目录存放具体业务页面，按业务模块建子文件夹，比如首页、文章列表、个人中心页，页面内只保留当前页面的独有结构，公共块直接调用已封装的组件即可。
• 静态资源
  • 图片、字体等固定静态资源放在public/assets的对应子目录下，不要散落在public根目录。
  • 自定义交互JS全部放在resources/js目录下按模块拆分，通过Vite统一打包引入，不要在Blade模板里写大段行内JS。

三、美观UI落地的实用规则 #

• 先定全局设计规范再写页面：在Tailwind配置的theme.extend项里提前定义好全局主色、辅助色、字号层级、圆角大小、间距基准，全站所有页面都用这套配置的语义化类，比如统一用bg-primary表示主色，不要一个页面用bg-blue-500另一个页面用bg-sky-600，导致视觉风格混乱。
• 通用交互组件提前封装：比如主按钮、次按钮、危险按钮、不同尺寸的输入框、状态提示条，统一封装成Blade组件，支持传参切换尺寸、状态，全站复用保证视觉和交互统一。
• 响应式适配同步做：写页面结构时遵循移动端优先原则，先写小屏适配样式，再通过md:、lg:等断点前缀补全大屏样式，不要等PC端写完再回头补移动端适配，避免改不动。
• 补全细节状态：所有可点击元素加对应的hover、active、focus状态样式，提前封装好加载态、空状态、错误提示的统一UI，不要直接用浏览器默认的提示样式。

不要为了所谓的“个性化结构”随意修改Laravel默认目录，框架默认结构是经过大量生产项目验证的，随意改动只会大幅提升后续的维护和排错成本。

内容的提问来源于stack exchange，提问作者SolomonKing