app、config、routes、public 四目录覆盖90%日常开发：app/Http/Controllers存控制器，app/Models存模型；config集中管理配置，.env值需经config:cache刷新才生效；routes定义Web/API路由；public为唯一Web入口，存放index.php及可公开的静态资源与上传文件。
直接看 app、config、routes、public 这四个目录，就能覆盖 90% 的日常开发需求。其他目录要么极少改动（如 bootstrap），要么只在特定场景才碰（如 database/seeds 已在 Laravel 9+ 中被弃用）。
怎么快速定位控制器和模型文件
控制器一定在 app/Http/Controllers 下，命名空间是 App\Http\Controllers；模型默认在 app/Models，命名空间为 App\Models。Artisan 命令生成时会自动按此规则放置，但注意：Laravel 并不强制模型必须放这里——只要 Composer 能自动加载（PSR-4 映射正确），放在 app 下任意子目录都行。
常见错误现象：
- 新建的控制器类报
Class not found：检查命名空间是否漏写App\Http\Controllers，或是否忘了在use语句中引入父类Controller - 模型关联失败（如
belongsTo返回 null）：确认模型类名与数据表名是否遵循 Laravel 默认约定（User→users），否则需显式指定$table属性
为什么修改了 .env 但 config/database.php 里的值没变
因为 .env 不是配置文件本身，而是运行时注入源。Laravel 在启动时通过 bootstrap/app.php 加载 Dotenv，把 .env 中的键值对注入到 $_ENV 和 $_SERVER，再由 config/database.php 等文件中的 env('DB_HOST', '127.0.0.1') 动态读取。
关键点：
- 修改
.env后，如果用了配置缓存（php artisan config:cache），必须重新运行该命令，否则旧缓存仍生效 -
env()函数仅在配置加载阶段可用；在运行时（如控制器中）调用env('APP_DEBUG')是错的，应改用config('app.debug') - 生产环境严禁开启
APP_DEBUG=true，且不应依赖.env文件存在——应由部署流程将变量注入系统环境
public/index.php 是唯一 Web 入口，但静态资源放哪
public 是 Web 服务器 DocumentRoot 必须指向的目录，所有 HTTP 请求都经由它进入 Laravel。里面除了 index.php，还应放前端构建产物（如 js/app.js、css/app.css）和用户上传的公开文件（如 uploads/avatar.jpg）。
注意区别：
-
public下的文件可被直接访问（如/js/app.js） -
resources下的是源码（如resources/js/app.js），需经 Vite/Laravel Mix 构建后复制到public - 用户上传的私有文件（如合同 PDF）不应放
public，而应存到storage/app，并通过Storage::url()或中间件控制访问权限
storage 和 bootstrap/cache 权限问题最常卡部署
这两个目录必须可写，否则日志写不进、路由/配置缓存生成失败、队列监听器起不来。Linux 下典型修复命令是：
chmod -R 755 storage bootstrap/cache
但更稳妥的做法是让 Web 服务器用户（如 www-data 或 nginx）拥有所有权：
sudo chown -R www-data:www-data storage bootstrap/cache
容易被忽略的点：
-
storage/logs如果不可写，php artisan命令可能静默失败，无任何错误输出 -
bootstrap/cache/packages.php和services.php是服务提供者注册缓存，若损坏会导致Class not found类错误，删掉它们并重跑composer dump-autoload即可恢复 - Docker 环境中，挂载卷时要注意宿主机与容器内 UID/GID 是否一致，否则即使 chmod 也无效
