PHP项目在线上运行时，未捕获的异常、模糊的错误日志、失效的过滤规则，往往让开发者翻来覆去地查代码。

目前有一些平台免费集成了Gemini模型，比如 RskAi（b.rsk.cn），可以直接在网页上使用。

下面通过四个典型的PHP异常场景，演示如何用Gemini把错误定位和异常处理变成有章可循的修复流程。

场景一：从未捕获的异常栈直接定位业务逻辑Bug

线上报错有时只有一句“Fatal error: Uncaught Exception … in /path/to/file.php on line 42”，缺少上下文。Gemini可以结合错误信息和对应的代码，分析异常发生的业务条件并给出修复方案。

操作步骤：

复制完整的错误栈，例如：“Uncaught InvalidArgumentException: 订单状态不能从‘已取消’变为‘已发货’ in OrderService.php:138”。

将 OrderService.php 中相关方法的代码（约50-100行）粘贴进对话框。

输入以下提示：

以上是错误栈和对应代码。请分析抛出该异常的原因，指出是什么业务流程导致订单在已取消状态下触发了发货操作。给出两种修复思路：

在调用该方法前增加状态校验

在方法内部改为更安全的处理方式
输出修复后的代码，并说明每种思路的适用场景。

Gemini会分析出可能是用户反复点击发货按钮或消息队列重复投递，在“已取消”状态下仍执行了发货逻辑。它会给出在Controller层增加 if($order->status !== 'paid') 守卫的代码，以及方法内部改为 if($order->status !== 'paid') { throw new LogicException(...); } 的版本。开发者可根据项目架构选择，几分钟内完成修复验证。

场景二：编写统一的自定义异常处理器与日志记录

项目里到处是 try-catch 然后 echo 错误信息或记一条 error_log，既不统一也不好排查。Gemini可以生成一套完整的异常处理类，将异常按类型分级记录。

操作步骤：

描述需求：“需要一个PHP异常处理器，能捕获所有未处理异常，按严重程度分为Critical、Warning、Info三级，分别记录到不同日志文件，并以JSON格式输出错误响应。对PDOException单独标记为数据库错误。”

输入以下提示：

请编写一个PHP自定义异常处理器类，要求：

实现 set_exception_handler 和 set_error_handler 的统一注册

自定义一个 AppException 基类，包含严重程度常量

根据异常类型自动分级：PDOException为Critical，ValidationException为Warning，其他为Info

日志格式为JSON，包含时间、级别、消息、文件行号和请求ID

返回给前端的响应统一为JSON，且在生产环境下不暴露内部错误详情
输出完整类和注册代码。

Gemini会生成一个 ExceptionHandler 类，其中 handle() 方法使用 instanceof 判断异常类型并设置级别，通过 Monolog 或原生 error_log 写入。响应部分用 $_ENV['APP_ENV'] 判断环境，生产模式只显示“服务器错误”。整个类复制到项目中，替换原有零散的异常处理，日志立刻规范化。

场景三：从大量日志反向提取高频错误并生成修复列表

当错误日志达到几百兆，人工逐条看根本不现实。Gemini可以读入一段日志样本，自动归类错误并输出优先级修复清单。

操作步骤：

从 error.log 或 laravel.log 中导出最近500条ERROR级别的日志，将其粘贴或上传。

输入以下提示：

以下是PHP应用的错误日志片段。请完成：

按错误类型归类（如数据库连接、文件权限、输入验证、第三方接口超时等）

统计每类出现的次数

按出现频率从高到低排序，给出每类错误的修复建议

对于占比超过20%的错误，额外提供详细的排查步骤
输出Markdown表格。

Gemini会快速分析，可能发现“SQLSTATE[HY000] General error: 2006 MySQL server has gone away”出现了143次，占28%，建议检查 wait_timeout 和连接池的心跳机制。另一类“file_put_contents failed to open stream: Permission denied”出现67次，建议修复目录权限。修复清单直接标定了优先处理哪类错误最有效。

场景四：检查并修复输入过滤和输出转义的安全漏洞

PHP应用中，忘记对用户输入做过滤、对输出做转义，可能导致XSS或SQL注入。Gemini可以扫描控制器或模板代码，标记不安全的输入输出点并输出修复后的代码。

操作步骤：

将前端表单处理和后端保存的代码粘贴进去，比如一个接收用户评论并显示的功能。

输入以下提示：

审查这段用户评论功能的代码，找出所有可能存在XSS和SQL注入的输入输出点。要求：

标注代码行号和风险类型

输出PHP中应使用的安全函数（如htmlspecialchars、filter_var、预处理语句）

给出修复后的完整代码

如果是SQL拼接，改用PDO预处理语句

Gemini会标记出 echo $_POST['comment'] 缺少 htmlspecialchars，以及 $db->query("INSERT INTO comments VALUES ('$user', '$comment')") 存在注入风险。修复后的代码中，输出用 htmlspecialchars($comment, ENT_QUOTES, 'UTF-8')，查询改为 $stmt = $pdo->prepare("INSERT...") 并绑定参数。此类修复一次性排除多个常见漏洞。

常见问题

1. Gemini能实时监控线上错误吗？
不能。你需要手动提供错误日志或错误栈，它负责分析并给出解决方案。它更适合作为开发调试和日志排查环节的辅助，而非线上监控。

2. 如果日志太大无法全部提供怎么办？
选取每类错误的代表性日志或错误数最多的前100条即可，模型能从样本中归纳出模式。也可以在提示中要求“根据样本推测其余错误的分布”，它会在分析中注明是基于部分数据。

3. 自定义异常处理器会不会和框架默认处理冲突？
如果使用Laravel或Symfony等框架，框架自身有异常处理。Gemini会输出两种版本：纯PHP通用版和与框架兼容版。在提示中加上“适配Laravel的Exception Handler”，它会继承框架基类并保留原有逻辑。

4. 安全审查能替代专业安全测试吗？
它覆盖的是常见Web安全漏洞，属于开发阶段的自动化自查，不能替代专业渗透测试。但能在代码编写阶段就拦截大量低级安全缺陷。

5. 为什么修复后的代码有时还是报错？
模型基于上下文生成，可能未考虑到项目中某些自定义的函数或配置。建议先在测试环境运行，将新的报错反馈给Gemini，它会进行二次修正。

总结

把Gemini整合到PHP的异常处理和错误排查中，等于在每个调试环节都多了一位能快速解读错误、生成代码、扫描安全的搭档。它不是代替开发者对代码逻辑的理解，而是让定位错误和编写异常处理代码的效率提升一个量级。当线上错误不再是让人头疼的谜题，你就可以把更多精力放在完善业务功能本身。

【本文完】