17370845950

PHP后端是处理业务逻辑的中间层，负责接收请求、调用数据库/缓存/第三方服务、返回JSON/HTML等响应，不渲染页面也不直接操作硬件；需防范SQL注入、权限绕过、重复IO等问题，确保接口契约稳定与状态一致。

PHP后端主要负责接收请求、处理业务逻辑和返回响应

它不渲染页面（那是前端的事），也不直接操作硬件，而是作为“中间人”：从 $_GET、$_POST、API 请求中读取数据，调用数据库、缓存、第三方服务，做完计算或状态变更后，把结果（JSON、HTML 片段、重定向指令等）交还给 Web 服务器（如 Nginx/Apache）再发给客户端。

典型任务包括用户登录验证、订单创建、文件上传解析、邮件发送触发

这些不是靠单行代码完成的，而是一组协同动作：

• 用 password_verify() 校验密码哈希，而非明文比对
• 在创建订单前，用事务包裹 $pdo->beginTransaction()、库存扣减、订单写入，避免超卖
• 上传文件时检查 $_FILES['file']['error'] === UPLOAD_ERR_OK，再验证 mime_content_type() 而非只看扩展名
• 发邮件不直接调用 mail()（易被拒收），而是走 PHPMailer 或 SMTP 封装类

常见错误：把本该后端做的逻辑甩给前端，或忽略状态一致性

比如：

• 前端 JavaScript 做权限判断（if (user.role === 'admin') showDeleteBtn()），后端却没在 API 入口校验 $_SESSION['role'] === 'admin' —— 权限可被绕过
• 用 file_get_contents('config.json') 读配置但没加 opcache_disable() 或缓存层，高并发下反复 IO 导致响应变慢
• 数据库查询用 mysql_query()（已废弃），或拼接 "SELECT * FROM users WHERE id = " . $_GET['id'] —— SQL 注入风险极高

与前端交互的关键点：接口契约必须明确且稳定

后端输出的 JSON 结构一旦上线，就不能随意改字段名或嵌套层级，否则前端会报 Cannot read property 'name' of undefined。建议：

• 用 json_encode($data, JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR) 避免乱码和静默失败
• 统一返回格式，例如始终含 'code'、'message'、'data' 三层，哪怕 data 是 null
• 开发期用 var_dump($_SERVER['REQUEST_METHOD'], $_REQUEST) 快速确认实际收到什么，而不是只信前端说的“我传了 POST”

真实项目里，最难的往往不是写完功能，而是让每次请求都干净地进、安全地转、确定地出——尤其当多个接口共享同一份数据库连接或 Session 数据时，状态残留、并发冲突、错误没被捕获，都会在看似无关的环节突然冒出来。