我愿意在本节中发布代码来完成优化，但是它有点长且很复杂，因此我希望有人可以为我提供一些调试问题的帮助。我的目标是找出导致我的Apex CPU时间限制超出问题的原因。
以其基本或常规布局使用调试日志时，会收到消息
最大CPU时间：10,000中的15062 **接近极限
我已经多次优化和编写各种循环和查询，每种情况下该数字都在此结束，这使我相信它对我撒谎，而我的实际用法远远超出了这个数字。因此，在旅途中，我将开发人员控制台的“日志面板”切换为“分析”，希望准确地隔离出什么循环，方法或代码区域使我头疼。
这使我想到了我的主要问题和问题。
执行树，性能树和执行单元
所有人都告诉我我的持续时间少于10,000毫秒。我最大的消耗是3,556.19ms，这是由我在构造函数方法中创建和使用的包装器类使用的，在构造器方法中，大量的逻辑正在构造一个相当复杂的包装器类，该包装器类跨越5-7个自定义对象。即使使用了3,000ms，该过程的其余部分仍可以忽略不计，这使我的总工作时间约为4,000ms。同样，我的问题是...。为什么我无法看到或发现正在消耗所有时间的东西？
错误的迭代数据
除此之外，“性能”树上还有一列数据，显示每种方法的迭代次数。我知道我的Production Org有81个对象，这些对象实际上将为我的自定义包装对象调用构造函数。即我的构造函数应该被调用81次，但是应该被调用32次。所以我的另一个问题是，我可以依赖列中的迭代数据吗？还是因为它迭代了很多次，它才在某个点停止计数？我的一个对象可能被损坏或以某种方式导致了无限循环，但如果已知的问题是迭代数据仍然不正确，我不想挖掘所有数据以寻找该结论。
生产组织中的System.Debug
最后一个问题是为什么我的System.Debug（）行未显示在生产组织的开发人员控制台中。我在整个代码中添加了服务器面包屑，这将有助于我隔离哪些对象正在通过，哪些不是，但是，我无法在任何布局视图system.debug沙盒之外的消息。
很抱歉有很多问题，但是我确实想做出诚实的努力，以更好地了解Salesforce中的调试过程。如果这是一个失败的原因，我也很乐意也开始共享一些代码，但是希望一些调试技巧可以帮助我找到解决方案。
答案 0 :(得分：1)
您的调试日志可能会被截断，请参阅{{3中的每个调试日志必须小于或等于20 MB。如果超出此数量，您将看不到所需的所有内容。。“ }} 下载日志并搜索类似于“ 跳过123456字节的详细日志” 的文本以确认，某些system.debug语句将不会显示。
您可能必须微调日志级别（不记录验证规则和工作流程？不要使用“ FINE”级别记录每个变量分配等）。您可能必须将所有标志都设置为NONE，然后仅跟踪您怀疑的1个特定类/触发器（请参见https://trailhead.salesforce.com/en/content/learn/modules/apex_basics_dotnet/debugging_diagnostics和https://help.salesforce.com/articleView?id=code_debug_log_classes.htm&type=5）
如果它被截断了，则可能会放弃分析工具（说实话，我对控制台的运气还很满意，有时https://salesforce.stackexchange.com/questions/214380/how-are-we-supposed-to-use-debug-logs-for-a-specific-apex-class-only可以很好地进行概述-但它也无法解析20 MB的日志...
当所有其他方法均失败时，您可以将日志加载到Notepad ++（或您选择的任何编辑器）中，找到与方法进入/方法退出相关的行（您可能需要进行正则表达式搜索），将这些过滤后的行移至excel，播放“文本到列”，然后手动查看计时，看看是否有导致峰值的记录。因为可能是＃10，所以它耗尽了81中的＃32的限制的意义并不大。像[METHOD_ENTRY|METHOD_EXIT]MyTriggerHandler.onBeforeUpdate这样的搜索可能是一个不错的开始。但是首先要确保日志不会被截断。