真实项目需按需求规模、团队习惯和部署环境动态调整PHP后端流程；小工具用原生+Slim，中大型选Laravel；注意PHP版本、数据库权限、日志配置及环境一致性。
PHP 后端开发没有标准“流程教程”可套用，真实项目里你得根据需求规模、团队习惯和部署环境动态调整。硬套所谓“完整流程”反而容易卡在环境配置或路由设计上动不了。
怎么选框架：Laravel 还是原生 PHP + Composer 包？
新项目别从 php -S 命令起步写路由——调试时 404 多半不是代码错，而是没配好重写规则。小工具类项目（比如内部 Excel 导出接口）用原生 + slimphp/slim 足够；中大型业务系统直接上 Laravel，它把 artisan、migrate、seeder 这些命令链路跑通了，省去自己搭 CLI 入口的精力。
注意两点：
- Laravel 11 默认要求 PHP 8.2+，老服务器没升级的话，Laravel 10 是更稳妥的选择
- 别在
public/index.php里手动改$_SERVER['REQUEST_URI']来兼容 Nginx 的 PATH_INFO 模式——直接用 Laravel 自带的nginx.conf示例配置
数据库迁移经常失败？重点看三个地方
php artisan migrate 报错不一定是 SQL 语法问题，更多是权限或上下文缺失：
立即学习“PHP免费学习笔记（深入）”；
- MySQL 用户没被授予
ALTER和CREATE权限，尤其在 Docker 容器里默认用户常被限制 -
.env文件里的DB_HOST写成localhost—— 容器内访问宿主机 MySQL 应该用宿主机 IP 或host.docker.internal - Migration 文件里用了
$table->json('data')，但 MySQL 版本低于 5.7，会直接报错而不是优雅降级
API 接口返回空数组或 500 却没日志？检查 error_reporting 设置
线上环境 display_errors=Off 是对的，但很多人忘了开 log_errors=On，导致异常静默。Laravel 默认把错误写进 storage/logs/laravel.log，但如果你手动改过 config/logging.php 里的 stack 配置，又没确认 channels 是否包含 single，就可能看不到任何记录。
快速验证方法：
- 在控制器里加一行
Log::error('test log');，然后查storage/logs/下最新文件 - 如果日志目录权限不对（比如 www-data 用户无法写入），
chmod -R 775 storage/比反复重启 PHP-FPM 更有效 - 别依赖浏览器 F12 看 Network → Response——有些 500 错误连 HTTP body 都没返回，得看
error_log或 Nginx 的error.log
真正卡住项目的往往不是语法或框架用法，而是本地 php.ini 和生产环境不一致、Composer autoload 加载顺序混乱、或者 Git 忽略了 .env.example 却没同步更新字段。流程只是骨架，填进去的每个配置项才是实际跑起来的关键。
