不能靠事后过滤错误消息中的密码，而必须在错误发生前切断敏感信息传递路径；应通过连接工厂隔离密码、应用层try/catch手动构造精简错误、set_error_handler中主动清洗$context敏感键并跳过底层错误记录。
PHP自定义错误处理器里如何剥离数据库密码
直接说结论：不能靠「事后过滤」错误消息里的密码字符串，而必须在错误发生前就切断敏感信息的传递路径。PHP的set_error_handler拿到的是最终拼好的错误字符串或$error_context数组，此时密码往往已混在dsn、mysqli_connect参数或异常堆栈里，正则替换极不可靠——比如密码是pass123!@#，而日志里出现Failed to connect: pass123!@#_db或堆栈中mysqli::__construct('localhost', 'user', 'pass123!@#', ...)，简单str_replace会漏掉、误删、或破坏堆栈结构。
为什么error_get_last()和$error_context不安全
$error_context（第四个参数）看似能拿到出错时的局部变量，但它的内容受track_errors和zend.exception_ignore_args影响，PHP 8.0+ 默认不包含函数参数值；即使开启，也只保留「可序列化」的标量和数组，对象、资源、闭包全被丢弃——而PDO/MySQLi连接通常以对象形式存在，$error_context里根本看不到$pdo或$host/$pass变量。用error_get_last()拿不到上下文，纯属白忙。
真正有效的三步隔离法
核心思路：让密码永远不进入错误上下文。不是「擦除」，而是「不带入」。
- 数据库连接参数绝不直接传入
new PDO()或mysqli_connect()调用——改用预定义的连接工厂函数，在内部处理敏感字段，外部只传标识符（如'production'），密码从环境变量或加密配置文件读取，且不在调用栈中暴露 - 所有数据库操作封装在try/catch内，捕获
PDOException或mysqli_sql_exception，手动构造精简错误消息："DB connection failed for user {$user} on {$host}"，显式排除$password、$dsn完整串 - 在
set_error_handler中检查$error_file和$error_line，若来自vendor/或mysqli扩展底层，直接跳过记录；仅记录应用层（app/、src/）抛出的错误，并强制清空$error_context数组中的password、pwd、secret等键（注意大小写和下划线变体）
一个防漏的set_error_handler片段示例
set_error_handler(function ($severity, $message, $file, $line, $context) {
// 只处理应用代码里的错误
if (strpos($file, 'vendor/') !== false || strpos($file, '/mysqli') !== false) {
return false;
}
// 清洗 $context 中常见敏感键
$sensitiveKeys = ['password', 'pwd', 'secret', 'auth', 'token'];
foreach ($sensitiveKeys as $key) {
unset($context[$key], $context[strtoupper($key)], $context[ucfirst($key)]);
}
// 记录时用 error_log() + 自定义格式，不拼接原始 $message
$logMsg = sprintf(
"[%s] %s in %s:%d | Context: %s",
date('c'),
$message,
basename($file),
$line,
json_encode($context, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE)
);
error_log($logMsg, 3, '/var/log/php-app.log');
});
关键点在于：不信任任何自动提取的上下文，不依赖$message文本清洗，而是从源头控制参数流向和错误生成逻辑。密码一旦出现在$context或堆栈里，就已经算泄露了。
立即学习“PHP免费学习笔记（深入）”；
