17370845950

必须脱敏手机号、身份证号、银行卡号、收货地址、用户姓名等敏感字段，应基于实际订单结构定义白名单并递归过滤，禁用全量正则以防误杀或漏脱敏。

PHP 订单日志中直接记录 $_POST、$orderData 或数据库原始行，极大概率泄露手机号、身份证号、银行卡号、收货地址、用户姓名等敏感字段——这不是“要不要脱敏”的问题，而是“不脱敏就违规”的事实。

哪些字段必须脱敏？看实际订单结构再决定

别盲目套用“手机号打星”模板。真实订单数据结构差异很大，需先确认日志来源：

• 是记录 $_REQUEST 原始输入？重点过滤 phone、id_card、bank_card、full_address、realname
• 是记录 ORM 模型对象（如 Laravel 的 $order->toArray()）？注意关联模型里可能嵌套 user.phone、address.detail
• 是记录 SQL 查询日志（如 PDO::exec() 后的 $sql 和 $params）？需对 $params 数组逐项检测，避免把 '138****1234' 当作普通字符串再拼进日志

用正则还是白名单？推荐白名单 + 简单正则组合

正则全量扫描日志内容（比如 preg_replace('/1[3-9]\d{9}/', '1**********', $log)）风险高：可能误杀订单号（如以 138 开头的内部单号）、破坏 JSON 结构、漏掉带分隔符的身份证（110101****00001234）。更稳妥的做法是结构化过滤：

• 定义脱敏字段白名单：['phone', 'mobile', 'id_card', 'card_no', 'bank_account', 'address', 'full_address', 'consignee', 'real_name']
• 对数组/对象递归遍历，只对键名匹配白名单的值做处理
• 手机号统一替换为 substr($val, 0, 3) . '****' . substr($val, -4)；身份证保留前 6 位和后 4 位，中间用 ***** 替代
• 地址类字段若含“省/市/区”，可保留到区级，后面门牌号打星：preg_replace('/(?

日志写入前统一拦截：Middleware or Monolog Processor?

不要在每个 error_log() 或 file_put_contents() 前手动调用脱敏函数。两种主流方式：

• Laravel / Symfony 项目：用 Monolog\Processor\ProcessorInterface 实现自定义处理器，在 __invoke() 中对 $record['context'] 和 $record['extra'] 做白名单脱敏，注册到 logger channel 即可全局生效
• 原生 PHP 或 ThinkPHP：在公共日志函数（如 write_order_log($data)）里封装脱敏逻辑，确保所有订单相关日志必经此函数
• 绝对禁止：在控制器里 Log::info('order created', $order->toArray()) —— 这等于把未过滤的裸数据交给了日志系统

脱敏后还要验证日志可读性

脱敏不是把一切变星号就完事。以下情况说明脱敏过度或失效：

• JSON 日志无法解析：{"phone":"****","id_card":"***"} 缺少长度校验，导致前端或 ELK 解析失败
• 订单号被误脱敏：正则没加字边界，把订单号 ORD13812345678 变成 ORD******45678
• 空值或 null 被转成字符串 "****"，掩盖了字段本为空的事实

上线前务必用真实订单数据样本跑一遍脱敏函数，用 json_encode() 验证输出是否仍为合法 JSON，并检查关键业务字段（如 order_id、status、amount）是否完好。

function maskOrderFields(array $data): array
{
    $sensitiveKeys = ['phone', 'mobile', 'id_card', 'card_no', 'bank_account', 'address', 'consignee', 'real_name'];
    $result = [];

    foreach ($data as $key => $value) {
        if (in_array(strtolower($key), $sensitiveKeys)) {
            if (is_string($value) && preg_match('/^1[3-9]\d{9}$/', $value)) {
                $result[$key] = substr($value, 0, 3) . '****' . substr($value, -4);
            } elseif (is_string($value) && preg_match('/^\d{17}[\dXx]$/', $value)) {
                $result[$key] = substr($value, 0, 6) . '******' . substr($value, -4);
            } elseif (is_string($value) && strlen($value) > 10) {
                $result[$key] = mb_substr($value, 0, 3, 'UTF-8') . '****';
            } else {
                $result[$key] = $value; // 不匹配规则的原样保留，不强行打星
            }
        } elseif (is_array($value)) {
            $result[$key] = maskOrderFields($value);
        } else {
            $result[$key] = $value;
        }
    }

    return $result;
}

最常被忽略的一点：数据库慢查询日志、MySQL general_log、Redis 操作日志这些“非应用层日志”同样可能含敏感信息，它们不受 PHP 脱敏逻辑控制，得靠数据库配置或代理层过滤——这点比代码里漏一个 maskOrderFields() 调用更难发现。