01. 错误级别与环境配置
01.01 错误级别的含义与常见组合
错误级别决定了在代码运行时哪些问题会被报告，以及这些报告是否会直接展示给终端用户。理解 E_ALL、E_ERROR、E_WARNING、E_NOTICE 以及它们的组合，是实现可控错误输出和日志记录的前提。
在开发阶段，常见的做法是使用E_ALL或包含 E_STRICT 的组合，以便尽早发现潜在问题；而在生产环境中，通常会对 E_NOTICE 与 E_DEPRECATED 进行剔除，以减少无关噪声对性能与用户体验的影响。
为避免直接在页面上暴露细节，理解生产环境的目标是将所有真正的错误记录到日志中，而不是呈现在用户侧界面上。这样可以在不影响体验的前提下实现监控与追踪。
01.02 运行时设置与 php.ini 的配置
运行时设置通过 ini_set 可以在应用启动阶段覆盖默认配置，方便在不同环境切换。与此同时，可以通过修改 php.ini 全局生效以保持一致性。
示例中，通过调整错误显示与日志机制，在开发与生产环境之间实现灵活切换：
ini_set('display_errors', '0');
ini_set('log_errors', '1');
ini_set('error_reporting', 'E_ALL & ~E_NOTICE');
如果需要在不同环境快速切换，也可以在入口文件根据环境变量动态设置：
$env = getenv('APP_ENV');
if ($env === 'production') {ini_set('display_errors', '0');ini_set('log_errors', '1');ini_set('error_reporting', E_ALL & ~E_NOTICE & ~E_DEPRECATED);
} else {ini_set('display_errors', '1');ini_set('log_errors', '0');ini_set('error_reporting', E_ALL);
}
01.03 生产环境的行为设计
在生产环境中，应确保错误信息不直接显示给用户，同时将日志集中化，以便后续分析与告警。关键点包括将 display_errors 设为 0、开启 log_errors、并指定明确的 error_log 路径，以实现可追溯的日志记录。
下面的配置示例展示了一个典型的生产环境做法：
ini_set('display_errors', '0');
ini_set('log_errors', '1');
ini_set('error_log', '/var/log/php-app/error.log');
02. 将错误日志写入持久化存储的实战技巧
02.01 日志存储路径与轮转
选择稳定的日志存储路径至关重要，建议将日志放在专用目录如 /var/log/php-app，并确保具备合适的权限（如 web 用户可写，但其他用户不可随意写入）。
为了防止日志文件持续增大，需要结合日志轮转策略，例如使用 logrotate 定期轮换、归档与压缩，以节省磁盘空间并便于归档。
/var/log/php-app/*.log {dailyrotate 7compressdelaycompressmissingoknotifemptycreate 0640 www-data www-datasharedscriptspostrotatesystemctl reload php-fpm >/dev/null 2>&1 || trueendscript
}
02.02 集中化日志系统（ELK/Graylog/GELF 等）
将日志集中化，是提升可观测性与故障定位效率的有效做法。可以通过诸如 Monolog 等库，将 PHP 日志输出到集中式系统（如 ELK、Graylog、Graylog GELF、Syslog 等）。
下面给出一个使用 Monolog 通过 GELF 将日志发送到 Graylog 的示例：
use Monolog\Logger;
use Monolog\Handler\GelfHandler;
use Gelf\Publisher;
use Gelf\Transport\UdpTransport;$transport = new UdpTransport('graylog.example.com', 12201);
$publisher = new Publisher($transport);
$log = new Logger('app');
$log->pushHandler(new GelfHandler($publisher, Logger::WARNING));$log->warning('User login failed');
$log->error('Database connection error');
通过这种方式，结构化日志便于在后端分析、可视化和告警触发，日志结构化与统一格式将显著提升运维效率。
02.03 本地与云端混合策略
在开发阶段可以优先使用本地日志，以便快速调试；在生产阶段则通过集中化系统实现跨节点的日志收集、检索与告警。实现混合策略的关键是制定清晰的日志级别与信息粒度，以及统一的时间戳和上下文信息。
保持日志收集的一致性与可追溯性，可以帮助团队在面对故障时快速定位根本原因，并满足合规性要求。
03. 错误处理策略与异常监控
03.01 自定义错误处理器与异常处理
通过 set_error_handler 与 set_exception_handler 可以将错误与异常集中在一个统一入口进行处理与记录，避免不同模块使用不同的处理方式导致日志分散。
使用自定义处理器时，尽量让处理逻辑只负责记录与告警，保留核心业务逻辑的分离，以便后续维护与扩展。
set_error_handler(function ($severity, $message, $file, $line) {// 将错误信息写入日志系统// 例如：$log->error("{$message} in {$file} on line {$line}");return false; // 让PHP自带的错误处理继续执行
});
set_exception_handler(function ($exception) {// 统一记录未捕获的异常// 例如：error_log($exception->getMessage());
});03.02 生产环境的监控指标
对错误与异常进行监控，可以帮助团队在问题出现时快速告警并分析趋势。常见的监控维度包括错误率、警告密度、以及平均修复时间等。
实践中，可以结合 Prometheus、StatsD/Graphite 等指标系统，将日志中的关键信息转化为可查询的指标，并通过仪表板进行可视化。
// 示例：将错误计数上报到监控系统（伪代码，具体实现依赖所用客户端库）
$statsd->incr('php.errors', 1);
04. 常见误区与安全性要点
04.01 避免在生产环境中暴露错误
一个常见的误区是误将开发环境设置延续到生产环境，导致对用户显示详细错误信息。应确保display_errors始终设为 0，并将所有错误通过日志记录。
在生产环境中，错误信息应集中化、结构化地被收集和分析，而不是直接输出给终端用户。
04.02 日志权限与数据安全
日志文件和目录的权限需要严格管理，推荐使用 0640 的权限，且确保归属用户为运行 Web 服务的账号（如 www-data）。
另外，对日志中的敏感信息进行脱敏或分级存储，以满足安全和合规性要求。
