打开任何一个PHP网站，站代看到的站代都是同一套骨架：入口文件接收请求，路由分发到对应逻辑，站代模板渲染出HTML。站代这套流程跑了几十年，站代依然没被淘汰。站代有人觉得PHP过时了，站代可WordPress、站代Wikipedia、站代Slack的站代早期版本全是用它撑起来的。问题不在语言本身，站代在于代码怎么写。站代

我见过一个日活五万的站代电商站，index.php里塞了三千行。站代从数据库连接、站代商品查询、购物车计算到页面输出，全在一个文件里。改一个价格显示逻辑，得翻半天找到对应的if分支。这种代码能跑，但每加一个功能，风险就翻一倍。后来他们重构，把数据库操作抽到model层，业务逻辑放进service，页面只负责渲染。代码量没少多少，可调试时间从两天缩到两小时。

入口文件不该是垃圾桶

很多教程教人写PHP，第一步就是“在index.php里连接数据库”。这没错，但连接完就结束。别把查询也写进去。入口文件只做三件事：定义常量、加载配置、启动路由。剩下的交给控制器。

// index.php 只做引导 require __DIR__ . '/vendor/autoload.php'; $config = require __DIR__ . '/config/app.php'; $router = new Router(); $router->dispatch($_SERVER['REQUEST_URI']); 

这样写，换框架只改入口，业务代码不动。我见过有人把数据库密码硬编码在index.php里，结果Git提交时忘了删，第二天服务器就被挖矿脚本占了。配置该放环境变量，或者至少放在web目录之外。

模板里别写SQL

早期PHP流行在HTML里直接写<?php mysql_query("SELECT * FROM users WHERE id = $id") ?>。方便是真方便，危险也是真危险。$id没过滤就是SQL注入，过滤了但逻辑复杂，模板就变成一锅粥。

现在用PDO预处理，把查询封装成函数。模板只接收数据，不碰数据库。比如商品列表页，控制器查好$products数组，模板里只写<?php foreach ($products as $p): ?>。改数据库字段？只改控制器。改页面样式？只改模板。两边不打架。

自动加载省掉一堆require

以前每个文件开头都有一串require_once 'db.php'; require_once 'user.php';。漏一个就报错，顺序错了也报错。Composer的autoload用命名空间映射目录，类名对应文件名，用的时候自动加载。省下的不只是代码行数，还有“这个函数到底在哪个文件里”的抓狂时间。

我习惯把src目录映射成App命名空间。App\Models\User对应src/Models/User.php。新建类不用改任何配置文件，直接new就行。小项目可能觉得麻烦，但超过二十个文件，手动require就是自找苦吃。

错误处理别用die

mysql_query() or die('查询失败')——这行代码在旧教程里出现频率极高。die直接终止脚本，用户看到白屏加一行英文。生产环境这样搞，等于把内部错误暴露给所有人。而且die之后，后面的清理逻辑全不执行，数据库连接不关闭，临时文件不删除。

用异常。查询失败抛DatabaseException，控制器捕获后记日志，给用户显示友好页面。PHP7之后，Error和Exception都实现了Throwable接口，可以统一捕获。别在业务代码里写die，那是调试用的，不是给用户看的。

目录结构反映逻辑分层

一个能维护的PHP项目，目录大概长这样：

app/ Controllers/ Models/ Services/ Views/ config/ public/ index.php vendor/ 

public是唯一对外暴露的目录，其他都在web根目录之外。这样即使配置写错，也不会被直接下载。我见过有人把.env放在public下，结果被人扫到，数据库直接裸奔。目录结构不只是好看，是安全边界。

PHP代码写得好不好，跟语言版本关系不大。PHP8的JIT很快，但用不好照样写出慢查询。关键在分层：入口只做引导，控制器只做调度，模型只做数据，模板只做展示。各司其职，改一处不影响另一处。这道理跟其他语言一样，只是PHP项目里更容易被忽略——因为入门太简单，简单到让人忘了架构这回事。