PHP通知推送过滤方案选型：存储可调用函数VS类型分支？

一、两种方案的优劣势对比 #

1. 类型分支（if-else）方案 #

• 优势：
  • 完全可控，无安全风险，所有逻辑都在代码库内，不会执行外部未知代码
  • 调试简单，分支逻辑清晰，出错时容易定位
• 劣势：
  • 扩展性极差，新增过滤规则必须修改push_or_not方法的代码，违反开闭原则
  • 规则与通知数据分离，无法针对单个通知灵活定制过滤逻辑

2. 通用过滤函数存储方案 #

• 优势：
  • 极致灵活，每个通知可以独立定义专属过滤逻辑，无需修改核心代码
  • 规则与通知数据绑定，配置化程度高，适合复杂多变的过滤需求
• 劣势：
  • 安全风险高，如果过滤函数来源不可信（比如用户输入），会导致代码注入漏洞
  • 存储与执行的技术复杂度高，需要解决callable的序列化、反序列化和安全执行问题

二、过滤函数存储方案的优化实现 #

针对你当前遇到的callable存储和eval风险问题，给出以下替代方案：

1. 序列化可调用对象（针对自定义类方法） #

如果过滤逻辑基于类的方法，可使用serialize()存储，读取时用unserialize()恢复：

// 定义过滤类
class NotificationFilter {
    public function filterByDevice($user, $notification) {
        return $user->device === $notification->target_device;
    }

    public function filterByIP($user, $notification) {
        return in_array($user->ip, $notification->allowed_ips);
    }
}

// 存储类方法callable
$filter = [new NotificationFilter(), 'filterByDevice'];
file_put_contents('filter.dat', serialize($filter));

// 读取并执行
$storedFilter = unserialize(file_get_contents('filter.dat'));
$shouldPush = $storedFilter($user, $notification);

注意：此方式仅适用于可序列化的对象/方法，匿名函数无法直接序列化。

2. 匿名函数的序列化解决方案 #

若必须使用匿名函数，可借助opis/closure扩展（PHP官方推荐的匿名函数序列化库）：

use Opis\Closure\SerializableClosure;

// 定义匿名过滤函数
$filter = function($user, $notification) {
    return $user->ip === '192.168.1.100';
};

// 序列化存储
$serialized = serialize(new SerializableClosure($filter));
file_put_contents('filter.dat', $serialized);

// 读取并执行
$stored = unserialize(file_get_contents('filter.dat'));
$shouldPush = $stored->getClosure()($user, $notification);

3. 替代eval的安全执行方式 #

绝对禁止直接使用eval(readfile())，这会引发严重的代码注入风险。推荐以下安全方式：
将过滤函数定义为独立的预定义函数，仅存储函数名到配置文件，执行时加载调用：

// 存储函数名到配置文件
file_put_contents('filter.conf', 'filter_by_ip');

// 预定义过滤函数文件 filter_functions.php
function filter_by_ip($user, $notification) {
    return in_array($user->ip, $notification->allowed_ips);
}

// 执行过滤逻辑
include 'filter_functions.php';
$filterName = trim(file_get_contents('filter.conf'));
if (function_exists($filterName)) {
    $shouldPush = $filterName($user, $notification);
}

这种方式将过滤逻辑限制在预定义范围内，大幅降低安全风险。

三、最终方案选择建议 #

• 如果通知过滤规则变化极少，且所有规则可提前预见，优先选择类型分支方案，简单安全，维护成本低。
• 如果过滤规则频繁变化，需要针对单个通知定制逻辑，且能确保过滤函数来源完全可信（比如仅由后台管理员配置，无用户输入参与），可选择通用过滤函数存储方案，但必须严格做好安全防护：
  • 禁止存储来自不可信来源的代码
  • 对存储的过滤逻辑进行白名单校验
  • 优先使用预定义类方法或函数，避免匿名函数

内容的提问来源于stack exchange，提问作者NullVoid