php项目中src/目录结构错配命名空间、混用大小写目录、误放非类文件易致composer自动加载失败；上传文件须按日期分层+哈希防重+安全过滤；public/外放php文件会因web服务器根目录限制导致代码泄露。
PHP项目中哪些文件夹结构容易引发自动加载失败
Composer 自动加载机制依赖目录与命名空间的严格对应，常见错误是把 src/Utils/Helper.php 的类声明为 namespace AppHelper，但 composer.json 中却配置了 "App\": "src/" —— 这会导致 AppHelper 被映射到 src/Helper.php，而非实际路径。
- 确保 PSR-4 映射前缀与目录层级完全对齐：如
"App\": "src/"，则AppHttpControllersHomeController必须位于src/Http/Controllers/HomeController.php - 避免在
src/下混用大小写不敏感的目录名（如models和Models），Windows 开发环境可能不报错，Linux 部署时直接类找不到 - 不要把配置文件、迁移或命令脚本硬塞进
src/；它们不属于可自动加载的业务代码，应归入config/、migrations/、app/Commands/等专用目录
如何用 PHP 脚本安全地批量整理散乱的上传文件
用户上传的文件若直接丢进 uploads/ 根目录，几个月后就会变成无法维护的“文件坟场”。PHP 本身不提供自动归档逻辑，必须自己控制存储路径生成策略。
- 按日期分层：用
date('Y/m/d')生成子目录，如uploads/2024/06/15/abc.jpg，避免单目录文件数超 10000 导致 Linuxls卡顿 - 加哈希前缀防重名：
$hash = substr(md5($originalName . time()), 0, 8)，再拼成uploads/2024/06/15/{$hash}_{$originalName} - 禁止直接使用用户传来的
$_FILES['file']['name']构造路径，必须过滤掉../、空字节、控制字符；可用basename()+pathinfo()提取扩展名，再白名单校验
public/ 目录之外为什么不能放可执行 PHP 文件
Web 服务器（如 Nginx/Apache）默认只将 public/（或 web/）设为网站根目录。如果误把 index.php 放在项目根下，而 config/database.php 又没加 <?php exit;，攻击者可能直接通过 URL 访问并输出明文数据库密码。
-
public/是唯一允许被 HTTP 请求直接访问的目录；所有其他目录（app/、config/、vendor/）必须在 Web 根目录之外，或通过服务器配置禁止解析 - 验证方式：在浏览器访问
https://yoursite.com/config/database.php，应返回 403 或 404，绝不能看到数组内容 - 某些共享主机不支持自定义根目录，此时需在
config/等敏感目录里放一个空的.htaccess（Apache）或index.php（Nginx 兜底），内容仅为<?php exit;
为什么 vendor/ 不该被放进 Git，但 composer.lock 必须提交
vendor/ 是 Composer 下载安装的第三方代码集合，体积大、更新频繁、含平台相关二进制（如 ext-redis 的 so 文件），Git 跟踪它只会拖慢克隆、增加冲突概率。
立即学习“PHP免费学习笔记（深入）”；
-
composer.lock锁定了每个包的确切版本和哈希值，CI/CD 或协作开发时运行composer install才能复现完全一致的依赖树 - 本地开发用
composer update升级依赖后，必须立刻提交更新后的composer.lock，否则队友composer install会装出旧版本，引发“在我机器上是好的”问题 - 若项目需离线部署，可提前运行
composer install --no-dev --prefer-dist并打包vendor/，但这属于发布流程，不是日常文件夹结构设计范畴
文件夹结构不是越深越好，也不是越扁平越安全。真正关键的是让每一层目录的职责不可替代、边界清晰——比如 app/Models 里不该出现 sendEmail() 方法，那属于 app/Services 或 app/Mailers 的事。结构一旦定型，改起来比换数据库还疼，动手前多看两眼 PSR-4 和你用的框架文档。
