PHP代码审查的六大核心检查点包括：一、编码风格与PSR规范符合性；二、变量与函数命名语义化；三、输入安全与输出转义；四、高危行为与运行时风险；五、函数与类设计合理性；六、自动化与流程闭环保障。
PHP代码审查不是走形式，而是守住质量、安全和协作底线的关键环节。真正有效的审查聚焦可验证、可修正的具体点，而不是泛泛而谈“逻辑是否合理”。以下是当前主流PHP团队实际落地的六大核心检查点，覆盖风格、安全、性能、健壮性、可维护性和工程流程。
一、编码风格与PSR规范符合性
统一风格是降低认知成本的基础，必须用工具强制保障：
- 必须使用
<?php或<?=标签，禁用<? ... ?>短标签 - 文件必须为UTF-8无BOM编码，结尾为Unix换行符（LF），纯PHP文件省略
?> - 类名用StudlyCaps（如
UserRepository），方法名用camelCase（如findActiveUsers），常量全大写加下划线（如MAX_RETRY_ATTEMPTS） - 缩进严格为4个空格，禁止Tab；行宽软限120字符，超长需合理换行
- 命名空间声明、use语句、类定义顺序须符合PSR-12结构要求
二、变量与函数命名语义化
命名不是个人偏好，而是接口契约：
- 变量名必须是名词，准确表达数据含义（如
$userEmail，而非$em或$data1） - 函数名必须以动词开头，明确动作意图（如
sendWelcomeEmail()，不叫doEmail()） - 同类功能命名必须统一（避免
getUserInfo()、fetchUser()、loadUserRecord()混用） - 杜绝魔术数字和模糊字面量，关键值必须定义为命名常量或使用预定义常量（如用
JSON_UNESCAPED_UNICODE代替256）
三、输入安全与输出转义
所有外部输入默认不可信，所有输出必须按上下文防护：
立即学习“PHP免费学习笔记（深入）”；
- 所有
$_GET、$_POST、$_COOKIE、$_SERVER等来源数据，必须经过filter_input()或filter_var()校验/净化 - 数据库查询必须使用PDO预处理或MySQLi绑定参数，禁止字符串拼接SQL
- HTML输出必须调用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')；JS上下文输出需json_encode()或addslashes()（依场景） - 文件路径拼接需用
realpath()+ 白名单校验，禁止直接接受用户传入的include或require路径
四、高危行为与运行时风险
这些代码一旦上线，极可能直接引发事故：
- 禁用
eval()、exec()、system()、passthru()、shell_exec()等执行函数 - 循环内禁止单条数据库查询（N+1问题），应改用
whereIn、批量加载或数据映射 - 未捕获的异常必须有
try/catch或全局异常处理器，禁止裸抛出未定义异常 - 敏感操作（如删除、支付、权限变更）必须有日志记录，且关键字段脱敏
- 配置文件不得存于Web可访问目录，数据库密码、API密钥等必须从环境变量或独立配置中心读取
五、函数与类设计合理性
代码结构决定长期可维护性：
- 函数参数不超过2个，超过则封装为DTO对象或Config类
- 单个方法长度建议≤30行，嵌套层级≤3层，圈复杂度（Cyclomatic Complexity）建议≤10
- 类职责单一，一个类只解决一个领域问题；避免巨型类（>500行）或上帝对象
- 类型声明必须完整：参数类型、返回类型、属性类型（启用
declare(strict_types=1)） - 避免重复逻辑，相同判断或计算应提取为私有方法或工具函数
六、自动化与流程闭环保障
靠人盯不如靠机制防漏：
- PR必须关联Issue编号，标题带标准前缀（
feat/、fix/、refactor/） - CI流水线必须集成
phpcs --standard=PSR12、phpstan level 5、phpmd，任一失败即阻断合并 - Git pre-commit钩子中运行
phpcbf自动修复基础格式问题 - 高危模块（如支付、权限、用户中心）的修改，需组织结构化审查会议并形成书面结论
- 每条审查意见必须定位到具体文件与行号，并附带可执行的改写建议，不接受“请优化”“注意一下”类模糊反馈
