laravel 项目必须将 web 服务器根目录严格指向 public/，确保 config/、app/ 等敏感目录无法被 http 直接访问；命名空间须与目录结构完全一致（如 apphttpcontrollers 对应 app/http/controllers/）；上传文件必须存入 storage/ 并禁用 php 解析；vendor/ 不提交 git，但 composer.lock 必须提交。
public/ 必须是 Web 服务器唯一可访问的根目录
任何 PHP 文件只要不在 public/ 下，就**不能被 HTTP 请求直接读取内容**。这是 Laravel 强制推行、也是现代 PHP 项目最基础的安全底线。如果把 config/database.php 放在项目根目录，而 Web 服务器又没限制访问，攻击者访问 https://yoursite.com/config/database.php 就能直接看到明文数据库密码。
实操建议：
- Nginx 配置中
root必须指向public/，不是项目根目录 - Apache 同样要确保
DocumentRoot指向public/，并在该目录下放好.htaccess - 验证方式：手动浏览器访问任意一个
config/或app/下的 PHP 文件，应返回 403 或 404，绝不能输出代码或数组 - 共享主机不支持改根目录？那就每个敏感目录（
config/、app/、storage/）里都放一个index.php，内容仅是<?php exit;
src/ 或 app/ 下的命名空间必须与目录结构完全对齐
Laravel 默认用 App 命名空间，对应 app/ 目录；但很多项目照搬却忽略路径映射细节，结果 composer dump-autoload 后类死活找不到。
常见错误现象：
-
Class AppHttpControllersHomeController not found—— 实际文件在app/Http/Controller/HomeController.php，少了一个s（Controllers ≠ Controller） -
AppModelsUser类声明了，但文件放在app/models/User.php（小写models），Linux 下直接加载失败 -
composer.json写的是"App\": "src/"，但类文件却在app/目录下
正确做法：
- 确认
composer.json中 PSR-4 映射前缀与实际路径严格一致，例如："App\": "app/" - 所有子目录名首字母大写（
Http、Models、Providers），避免大小写混用 - 不要在
app/下塞配置文件、迁移脚本或命令行脚本——它们该去config/、migrations/、app/Console/Commands/
storage/ 和 uploads/ 必须独立且受控，不能和代码混放
Laravel 把运行时生成的文件全扔进 storage/（缓存、日志、会话、上传临时文件），再通过符号链接把 public/storage 指向 storage/app/public 来暴露部分资源。这个设计不是为了好看，而是为了解耦和安全。
为什么不能把上传文件直接丢进 public/uploads/？
- 用户上传的 PHP 文件（比如伪装成图片的
shell.php）可能被 Web 服务器直接执行 - 单目录文件超 1 万，Linux
ls和 PHPscandir()会明显变慢 - 无法按环境隔离：开发用本地文件存储，生产想切到 S3，混在一起就难替换
实操建议：
- 上传路径必须动态生成，例如
storage/app/uploads/{date('Y/m/d')}/{$hash}_{$filename} - 过滤文件名：用
pathinfo($file, PATHINFO_EXTENSION)提取扩展名，再白名单校验（['jpg', 'png', 'pdf']） - 禁止解析上传目录下的 PHP：Nginx 加
location ~ ^/uploads/.*.php$ { return 403; } - 权限设为
755（目录）和644（文件），Web 用户只读不写
vendor/ 不进 Git，但 composer.lock 必须提交
Laravel 项目里 vendor/ 是 Composer 下载的第三方库，体积大、更新频繁、含平台相关二进制扩展（如 ext-redis），绝对不能进版本库。
但 composer.lock 文件必须提交，否则：
- 不同机器
composer install装出的依赖版本不一致，某天突然报错说Method IlluminateSupportStr::of does not exist - CI/CD 流水线构建失败，因为没锁版本，
monolog升级后日志格式变了
额外注意点：
- 部署时优先跑
composer install --no-dev，跳过测试和开发专用包 - 本地开发用
composer update，但每次改完composer.json后必须立刻git add composer.lock - 别在
vendor/里改任何代码——要定制就 fork、改包、换源，或用 Composer 的repositories覆盖
真正容易被忽略的是：目录结构不是一次性设计完就一劳永逸的。随着业务增长，app/ 下模块越来越多，app/Services/ 会膨胀成十几个子目录，这时候就得考虑按领域拆分（如 app/Orders/、app/Users/），而不是继续堆砌层级。结构演进本身，就是架构能力的体现。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
