PHP代码审查：每个开发者必须检查的8个关键事项

为什么代码审查不仅仅是“找bug”

想象一下：你写了一段完美的代码。它能运行，通过了测试，甚至客户也很满意。但在代码审查时，同事来了……然后开始了。“为什么这里用==而不是===？”，“这个方法一次性做了5件事”，“异常处理在哪里？”熟悉吗？

实际上，PHP代码审查不仅仅是抓bug（虽然这也是其中一部分）。它是一种让代码变得可读、安全且易于维护的方式。尤其是在PHP中，经过25年的演变，积累了很多“坑”。

在这篇文章中，我们将详细分析PHP代码审查需要检查什么，让代码不仅仅是能运行，而是成为质量的标杆。准备好了吗？出发！

1. 类型化和严格模式

PHP 7+ 和 8 为我们提供了强大的类型控制工具。但许多项目仍然处于“混乱模式”。

检查什么：

\n
• 是否声明了参数和返回值的类型？ 如果方法接受int，但你传入了string——这就是需要讨论的理由。
\n
• 文件开头是否有declare(strict_types=1);？ 没有这个，PHP会隐式转换类型，这常常导致隐藏的错误。
\n

<?php\ndeclare(strict_types=1);\n\n// 不好：没有类型\nfunction calculate($a, $b) {\n    return $a + $b;\n}\n\n// 好：严格类型化\nfunction calculate(int $a, int $b): int {\n    return $a + $b;\n}\n?>\n

代码审查建议： 如果看到mixed或没有具体说明的array——请提问“这里具体期望什么？”。

2. 安全性：SQL注入和XSS

PHP就像一把瑞士军刀：功能很多，其中许多很危险。尤其是在遗留代码中。

三大危险信号：

\n
• SQL查询中的字符串拼接。 如果看到"SELECT * FROM users WHERE id = ".$_GET['id']——这是在求救。
\n
• 输出数据时未转义。 echo $userInput;——你好，XSS。
\n
• 以明文存储密码。 说真的，这种情况仍然存在。
\n

<?php\n// 危险！\n$sql = "SELECT * FROM users WHERE email = '" . $email . "'";\n\n// 安全（PDO）\n$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");\n$stmt->execute(['email' => $email]);\n?>\n

在PHP代码审查中，始终检查对外部数据的处理。任何$_GET、$_POST、$_COOKIE都必须经过过滤。

3. 遵循PSR标准

PHP社区制定PSR（PHP标准建议）不是为了走过场。这是所有PHP开发者共同的语言。

每个PR中应该包含的内容：

\n
• PSR-12（编码风格）：缩进4个空格，类的大括号换行，运算符周围加空格。
\n
• PSR-4（自动加载）：命名空间必须与文件路径匹配。
\n
• 类名使用StudlyCaps，方法使用camelCase，常量使用UPPER_CASE。
\n

<?php\nnamespace App\\Service;\n\nclass UserService  // PSR-4：文件应位于 src/Service/UserService.php\n{\n    public function getUserById(int $id): ?User  // camelCase\n    {\n        // ...\n    }\n}\n?>\n

小技巧： 如果项目中没有自动格式化工具（PHP CS Fixer, PHP_CodeSniffer）——这是第一个需要改进的地方。

4. 复杂性和架构

好的代码是可以像书一样阅读的代码。而糟糕的代码则像解读古代手稿。

需要注意什么：

\n
• 方法的长度。 如果方法超过20-30行，很可