PHP 怎么PHP 四眼原则

wen PHP项目 2026-07-31 3

本文目录导读：

PHP 怎么PHP 四眼原则

代码审查配置（Code Review - Git）
后台管理操作权限（Two-Person Rule / N-Person Control）
敏感配置文件的分离与保护

“四眼原则”（Four Eyes Principle）在 PHP 开发中并不是一个 PHP 语言本身的特性，而是一个软件开发流程或安全权限控制的概念。

这个原则的核心是：任何重要的操作，都需要至少两个人（或者两个独立的环节）来审查或授权，才能执行。

在 PHP 的技术语境下,它通常指代下面几种情况：

代码审查配置（Code Review - Git）

这是“四眼原则”在 PHP 项目中最常见的表现形式。

场景：一个开发者在本地写完代码，git push 到远程仓库。
原则：不能直接合并到主分支（如 master 或 main），必须先创建 Pull Request (PR) 或 Merge Request (MR)，然后由另外一位开发者（第二双眼睛）进行代码审查，确认无误后，再由此人点击“合并”。
PHP 中如何实现：
- 使用 Git 平台（如 GitHub, GitLab, Gitea）。
- 在仓库设置中，启用分支保护规则（Branch Protection Rules）。
- 规则设置：Require a pull request before merging，并勾选 Require approvals（通常设为 1）。
- 这样，即使开发者有 main 分支的写入权限，没有经过第二个人审查,他也无法直接提交。

后台管理操作权限（Two-Person Rule / N-Person Control）

在电商、金融、企业内部 ERP 等 PHP 管理后台中，为了防止操作失误或恶意操作,会引入此原则。

场景：管理员 A 想要修改商品价格、给用户退款、或者删除一个数据库表。
原则：这是一个包含“提议-审核-执行”三步骤的流程。
1. 提议：管理员 A 发起一个操作（如“退款 100 元给用户 UID=123”），系统将操作状态设为“待审核”,并未真正执行。
2. 审核：管理员 B（权限更高或同等级）登录系统，看到这条待审核记录，他仔细检查 A 的操作是否合理。
3. 执行：B 点击“通过”，系统才真正的执行退款操作，B 点击“驳回”,操作作废。

PHP 中如何实现：

数据库设计：增加一个 operation_queue 或类似的表，字段包括 proposer_id, action_details, status (pending/approved/rejected), reviewer_id, reviewed_at 等。

逻辑代码：

// 1. 提议阶段（A 执行）
$queue = new OperationQueue();
$queue->user_id = 123;
$queue->action_type = 'refund';
$queue->action_data = json_encode(['amount' => 100, 'order_id' => 456]);
$queue->status = 'pending';
$queue->proposer_id = $currentAdmin->id;
$queue->save();
// 通知管理员 B 有任务待审核
// 2. 审核阶段（B 登录后）
$pendingOps = OperationQueue::where('status', 'pending')->get();
// B 查看详情
// 3. 执行阶段（B 点击批准）
public function approve($id) {
    $op = OperationQueue::findOrFail($id);
    if ($op->status != 'pending') {
        throw new Exception('操作已被处理');
    }
    // 此处是关键：只有 B 批准了，才会真正执行
    DB::transaction(function () use ($op) {
        // 执行 SQL：update users set balance = balance - 100 where id = 123
        $user = User::find($op->user_id);
        $user->balance -= json_decode($op->action_data)->amount;
        $user->save();
        // 更新队列状态
        $op->status = 'approved';
        $op->reviewer_id = auth()->id();
        $op->save();
    });
}

敏感配置文件的分离与保护

也可以看作一种延伸。

场景：修改 .env 文件中的数据库密码、API Key 或支付密钥。
原则：不让单一的开发者可以随意修改生产环境的敏感配置。
PHP 中如何实现：
- 使用配置管理工具（如 Laravel 的 Vapor、Envoy 或 Ansible）。
- Vault 服务：将敏感配置存在 HashiCorp Vault 中，PHP 服务器启动时动态获取,而不是写死在文件中。
- 文件权限：生产环境下的 .env 文件权限通常设置为 600（仅文件所有者可读写），且修改流程需要 DevOps 或经理的二次确认。

上下文	具体含义	PHP 实现难度
Git 代码提交	必须通过 Pull Request 并由另一人审查后才能合并	低（取决于 Git 平台配置）
后台管理操作	敏感操作需要“申请-管理员批准”两步	中（需要业务逻辑和数据库支持）
配置/运维	修改生产环境密钥需要多人权限或自动化工具	高（通常不直接在 PHP 层解决）

当有人问“PHP 怎么实现四眼原则”时，大概率是在问后台管理系统中的审核流程，只需要记住：不直接执行危险操作，而是将其记录为“待办事项”，等待第二个人确认后再执行。