基于Composer库实现PHP原生的实时日志脱敏与敏感信息预警-composer-PHP中文网

不能直接用error_log()或file_put_contents()做脱敏日志，因为它们不感知上下文、不识别敏感字段、也不支持运行时规则匹配；真正可落地的方案是基于monolog的可插拔处理器链，通过symfony propertyaccess解析路径、配置驱动规则、分层脱敏与告警。

基于composer库实现php原生的实时日志脱敏与敏感信息预警

为什么不能直接用 `error_log()` 或 `file_put_contents()` 做脱敏日志

因为它们不感知上下文、不识别敏感字段、也不支持运行时规则匹配。你写死一个 str_replace() 替换手机号，结果日志里出现身份证号、银行卡号、JWT Token，全漏掉——这不是脱敏，是自我安慰。

真正能落地的方案，得靠可插拔的处理器链：先解析日志结构（比如 JSON），再逐字段匹配规则（正则 or 白名单路径），最后替换或告警。Composer 生态里 monolog/monolog 是事实标准，但它默认不带脱敏能力，得自己加 Processor。

Monolog\Handler\StreamHandler 只负责写，不碰内容；脱敏必须在 Processor 阶段介入，且要在格式化（Formatter）之前
别把脱敏逻辑塞进 Formatter::format()——那会导致重复编码、JSON 字段被双重转义，尤其当你的日志含嵌套数组时，json_encode() 会崩
规则不能硬编码在 Processor 类里。用配置驱动，比如 YAML 定义：fields: ['user.phone', 'data.id_card']，否则改个字段就得发版

怎么写一个可复用的 `SensitiveDataProcessor`

它要接收日志 record，遍历 $record['context'] 和 $record['extra']，对指定路径执行脱敏，并在命中时触发预警（比如写入独立告警文件或调用 error_log() 带 LOG_WARNING）。

关键点在于路径解析——别手写递归取值，用 symfony/property-access（已广泛用于 Laravel/Symfony），它支持 user[profile][phone] 和 user.profile.phone 两种语法，且自动跳过不存在的键，不报 Notice。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

构造时传入规则数组，例如：['user.phone' => 'phone', 'order.card_number' => 'card']，value 是脱敏类型（决定用 *** 还是 138****1234）
对每个匹配字段，先备份原始值（用于告警），再替换为脱敏后值；注意保留字段结构，别把 int 变成 string 导致下游 JSON 解析失败
预警不走主日志通道，单独开 Monolog\Handler\StreamHandler 写到 /var/log/app/sensitive-alert.log，避免污染审计日志

class SensitiveDataProcessor implements Monolog\Processor\ProcessorInterface
{
    private $rules;
    private $accessor;

    public function __construct(array $rules)
    {
        $this->rules = $rules;
        $this->accessor = PropertyAccess::createPropertyAccessor();
    }

    public function __invoke(array $record): array
    {
        foreach ($this->rules as $path => $type) {
            $original = $this->accessor->getValue($record['context'], $path) ?: 
                        $this->accessor->getValue($record['extra'], $path);
            if ($original !== null) {
                $masked = $this->mask($original, $type);
                $this->accessor->setValue($record['context'], $path, $masked);
                $this->accessor->setValue($record['extra'], $path, $masked);
                $this->alert($path, $original);
            }
        }
        return $record;
    }

    private function mask($value, string $type): string
    {
        return match($type) {
            'phone' => preg_replace('/^(\d{3})\d{4}(\d{4})$/', '$1****$2', (string)$value),
            'card' => str_pad(substr((string)$value, -4), strlen((string)$value), '*', STR_PAD_LEFT),
            default => '***',
        };
    }

    private function alert(string $path, $original): void
    {
        error_log(sprintf('[SENSITIVE] %s: %s', $path, json_encode($original)), 3, '/var/log/app/sensitive-alert.log');
    }
}

如何集成到现有 Monolog 实例并避开常见坑

不是所有 record 都有 context 或 extra，有些框架（如 Slim）把数据全塞进 context，有些（如 CodeIgniter）压根不用这两个键——得先判断键存在再处理，否则 PropertyAccessor 会静默失败，你还以为没命中规则。

注册 Processor 时用 pushProcessor()，别用 pushHandler()——后者是给 Handler 用的，放错位置等于没装
如果项目用了 monolog/formatter 的 JsonFormatter，确保 Processor 在 Formatter 之前执行，否则你脱敏的是字符串而非数组，正则一跑全乱码
测试时别只 mock 单层数组。真实日志常含 ['context' => ['user' => ['profile' => ['phone' => '13812345678']]]]，路径写成 user.profile.phone 才生效，user->profile->phone 会失败