必须重构的函数包括：if嵌套超3层、函数名笼统如handleuserrequest()却干多件事、参数超4个且类型模糊、函数体内重复出现数组键名或sql片段；应立即extractmethod()并命名精准，如filteractiveusers()。
PHP代码重构不是重写，而是让已有逻辑更易读、易改、易测。只要函数超过30行、类里混着SQL和HTML、同一个校验逻辑在5个地方复制粘贴——就该动手了。
怎么识别必须重构的函数
别等报错才动。以下现象出现任意一个，extractMethod() 就该提上日程：
-
if嵌套超过3层，或else分支里又带if - 函数名是
handleUserRequest()这种万能筐，实际干了查库、发邮件、写日志三件事 - 参数列表超过4个，尤其是类型全是
string或array，靠注释才能看懂谁是谁 - 函数体里有重复出现的数组键名（如
['status', 'message', 'data']）或 SQL 片段（如"WHERE deleted = 0"）
这时别修修补补，直接把其中一段逻辑剪出来，起个精准名字，比如 filterActiveUsers($users)，而不是 processUsers()。
用 DTO 替代长参数列表
当构造函数或方法接收一堆零散参数，比如 createOrder($userId, $productId, $qty, $currency, $ip, $referralCode)，它已经不是“调用”，是在填表。
改成 DTO 更安全、更可读：
class CreateOrderRequest
{
public function __construct(
public int $userId,
public int $productId,
public int $qty,
public string $currency,
public string $ip,
public ?string $referralCode = null,
) {}
}
好处不止是整洁：PHP 8.1+ 的构造器属性提升自动完成字段注入；IDE 能跳转到定义；测试时不用记参数顺序；后续加字段不破坏原有调用签名。
注意：DTO 不该含业务逻辑，只做数据容器。验证仍应放在服务层或 FormRequest 中。
为什么 declare(strict_types=1) 必须加在每个文件顶部
不加这句，function calculateTotal(array $items): float 依然会接受 null 或 string，只是静默转成空数组或 0.0 —— 等你发现数据错位，可能已在生产环境跑了三天。
严格模式真正生效的前提是：
- 每份 PHP 文件（包括 trait、interface）都显式声明
declare(strict_types=1); - 类型提示写全：参数、返回值、属性（PHP 7.4+）都标注，别漏掉
?string或array|int这类联合类型 - 调用链上所有函数都启用严格模式，否则中间某层松开，整条链就失效
没加这句的项目，phpstan 和 psalm 的检查结果会严重失真，误报率高，反而让人忽略真正危险的类型漏洞。
重复字符串字面量比重复代码更危险
看起来只是几个 'user_not_found' 散落在控制器、模型、API 响应里，但问题不在“多”，而在“散”：
- 改错一处，其他地方还是旧值，前端文案和日志对不上 OPcache 无法复用同一常量内存地址，每个文件都存一份副本，浪费缓存空间
- 搜索
'user_not_found'找不到所有使用点，因为有人写了'user not found'或USER_NOT_FOUND
正确做法是集中定义：
final class ErrorCode
{
public const USER_NOT_FOUND = 'user_not_found';
public const INVALID_TOKEN = 'invalid_token';
}
然后统一用 ErrorCode::USER_NOT_FOUND。连带收益：IDE 支持跳转、重命名自动同步、CI 可扫描未使用的常量。
最常被忽略的一点：错误码常量要和 HTTP 状态码、日志级别、前端 i18n key 形成映射关系。别只图快定义一个字符串，就扔进 response() 里完事。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
