关于 platform-apex-logs-debug
用于从 Apex 调试日志诊断 Salesforce 运行时问题,包括异常、治理限制和性能瓶颈。它依据日志证据分析根因,并给出验证建议。
主要功能
- 01解读异常与堆栈跟踪
- 02检查治理限制用量
- 03查找重复 SOQL 和 DML
- 04调查 CPU 与堆压力
- 05依据证据建议修复
适用场景
- 01诊断失败的 Salesforce 事务
- 02调查循环中的 SOQL 或 DML
- 03分析 CPU 或堆限制压力
- 04追踪空指针的根因
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ forcedotcom/ sf-skills --skill platform-apex-logs-debug安装后在 Claude Code 中输入/platform-apex-logs-debug确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
README.mdassets/benchmarking-template.clscpu-heap-optimization.clsdml-in-loop-fix.clsnull-pointer-fix.clssoql-in-loop-fix.clsreferences/analysis-playbook.mdbenchmarking-guide.mdcli-commands.mdcommon-issues.mddebug-log-reference.mdlog-analysis-tools.mdscoring-rubric.md详细介绍
platform-apex-logs-debug:Salesforce 调试日志分析与故障排查
当用户需要通过调试日志进行根因分析时,使用此技能:诊断 Governor 限制、解读堆栈跟踪、调查慢查询、分析堆 / CPU 压力,或根据日志证据完成从复现到修复的循环。
此技能适用的任务
当工作涉及以下内容时,使用 platform-apex-logs-debug:
- Salesforce 的
.log文件 - 堆栈跟踪和异常分析
- Governor 限制
- SOQL / DML / CPU / 堆故障排查
- 从日志中提取的查询计划或性能证据
以下情况应委派给其他技能:
- 运行或修复 Apex 测试 → platform-apex-test-run
- 生成或实现代码修复 → platform-apex-generate
- 调试 Agentforce 会话跟踪 / parquet 遥测数据 → agentforce-observe
首先收集所需上下文
请询问或推断:
- org 别名
- 失败的事务 / 用户流程 / 测试名称
- 大致时间戳或事务时间范围
- 用户 / 记录 / 请求 ID(如已知)
- 目标是仅进行诊断,还是进行诊断并完成修复循环
建议的工作流
1. 获取日志
使用 references/cli-commands.md 中的命令,列出、下载或流式传输目标 org 的日志。
2. 按以下顺序分析
- 入口点和事务类型
- 异常 / 致命错误
- Governor 限制
- 重复的 SOQL / DML 模式
- CPU / 堆热点
- 调用外部服务的时间和外部故障
3. 对严重程度分类
- 严重 — 运行时故障、硬性限制、数据损坏风险
- 警告 — 接近限制、非选择性查询、执行路径缓慢
- 信息 — 优化机会或规范问题
4. 推荐最小且正确的修复方案
优先选择满足以下条件的修复方案:
- 针对根因
- 可安全处理批量数据
- 可测试
- 易于通过重新运行进行验证
扩展工作流:references/analysis-playbook.md
高信号问题模式
| 问题 | 主要信号 | 默认修复方向 |
|---|---|---|
| 循环中的 SOQL | 重复调用路径中反复出现 SOQL_EXECUTE_BEGIN | 只查询一次,使用映射 / 分组集合 |
| 循环中的 DML | 反复出现 DML_BEGIN 模式 | 收集记录,一次性执行批量 DML |
| 非选择性查询 | 扫描的行数过多 / 选择性较差 | 添加索引筛选条件,缩小范围 |
| CPU 压力 | CPU 用量接近同步限制 | 降低算法复杂度、使用缓存、在可行时改用异步处理 |
| 堆压力 | 堆用量接近同步限制 | 使用 SOQL for 循环进行流式处理,减少内存中的数据 |
| 空指针 / 致命错误 | EXCEPTION_THROWN / FATAL_ERROR | 对空值假设进行保护,修复空查询处理 |
扩展示例:references/common-issues.md
输出格式
完成分析时,按以下顺序报告:
- 失败情况
- 失败位置(类 / 方法 / 行 / 事务阶段)
- 失败原因(根因,而不只是症状)
- 严重程度
- 建议的修复方案
- 验证步骤
建议格式:
Issue: <summary>
Location: <class / line / transaction>
Root cause: <explanation>
Severity: Critical | Warning | Info
Fix: <specific action>
Verify: <test or rerun step>
规则 / 限制
| 规则 | 原因 |
|---|---|
| 修复建议始终以日志证据为依据 | 避免推测性诊断——根因必须能在日志中追溯 |
| 对发现的每个问题都报告全部六项输出字段 | 确保每个问题的发现结果完整且可执行 |
| 将每项发现分类为严重、警告或信息 | 帮助用户确定优先处理哪些问题 |
将代码生成委派给 platform-apex-generate | 此技能负责诊断,不负责重写 Apex 代码 |
将测试执行委派给 platform-apex-test-run | 此技能不运行或修复测试类 |
未读取 LIMIT_USAGE 事件前,绝不假设限制处于安全范围 | 失败点之前发生的操作可能已经消耗了限制 |
注意事项
| 陷阱 | 解决方案 |
|---|---|
| 日志被截断至 2 MB | 降低调试级别(例如,ApexCode: INFO、ApexProfiling: FINE),然后重新捕获 |
| 同一问题同时表现为 SOQL 和 CPU 问题 | 先修复循环中的 SOQL 查询——它通常会进一步导致 CPU 峰值 |
| 设置跟踪标志后没有日志出现 | 确认跟踪标志的 ExpirationDate 在未来,并且跟踪的是正确的用户 |
| 异步上下文会改变限制值 | 异步 CPU 限制为 60,000 ms,同步为 10,000 ms——报告超限前先检查事务类型 |
| 堆栈跟踪指向框架代码行,而非用户代码 | 沿调用堆栈向上查找,越过触发器处理程序,找到源头用户代码 |
跨技能集成
| 需求 | 委派给 | 原因 |
|---|---|---|
| 实现 Apex 修复 | platform-apex-generate | 生成/审查代码变更 |
| 通过测试复现 | platform-apex-test-run | 执行测试并循环检查覆盖率 |
| 部署修复 | platform-metadata-deploy | 部署编排 |
| 创建调试数据 | platform-data-manage | 创建有针对性的种子数据/复现数据 |
| 优化缓慢的 SOQL 查询 | platform-soql-query | 调整查询结构/性能 |
参考文件索引
| 文件 | 阅读时机 |
|---|---|
references/analysis-playbook.md | 从这里开始——适用于任何调试会话的详细分步工作流 |
references/common-issues.md | 快速查阅循环中的 SOQL、循环中的 DML、CPU/堆压力、空指针模式 |
references/cli-commands.md | 用于检索、流式传输和管理调试日志的 SF CLI 命令 |
references/debug-log-reference.md | 完整的事件类型目录、日志级别和治理限制参考值 |
references/log-analysis-tools.md | 工具指南:Apex Log Analyzer、Developer Console、CLI grep 模式 |
references/benchmarking-guide.md | 性能基准测试技术、基准测试数据和反模式 |
references/scoring-rubric.md | 用于评估分析质量的 100 分评分标准 |
assets/benchmarking-template.cls | 可复制粘贴的 Anonymous Apex 模板,用于运行性能基准测试 |
assets/cpu-heap-optimization.cls | 用于减少 CPU 时间和堆分配的 Apex 模式 |
assets/dml-in-loop-fix.cls | 用于解决循环中 DML 违规的修复前后示例 |
assets/soql-in-loop-fix.cls | 用于解决循环中 SOQL 违规的修复前后示例 |
assets/null-pointer-fix.cls | 防范空指针异常的模式 |
评分指南
| 分数 | 含义 |
|---|---|
| 90+ | 专业分析,并提供有力的修复指导 |
| 80–89 | 分析良好,仅有少量遗漏 |
| 70–79 | 可以接受,但可能遗漏次要问题 |
| 60–69 | 仅完成部分诊断 |
| < 60 | 分析不完整 |
评论
支持 Markdown