大家好，我是 SiKi老师。Console 里没有看到预期消息，还不能直接得出“代码没有执行”的结论。窗口当前显示哪个来源、有没有筛选条件，都会影响你眼前看到的列表。排查前先记录显示范围，可以避免还没确认观察条件就开始修改脚本。
本文依据 Unity 6.0 官方 Console 文档，提供观察记录的方法，不是某个报错的修复教程。当前没有在 Unity 编辑器中运行示例工程，也没有验证具体按钮在你的版本中的布局；下面的关键词与情境都是假想示例。
一 先记下自己正在观察什么
打开 Console 后，我会先记录 Unity 版本、当前工程、正在观察的操作，以及消息来源。这里只记录非敏感标识，分享给别人时不需要包含私人目录或设备地址。
Unity 文档说明，Console 可以显示 Editor 或所连接的开发版 Player 的日志。界面上的来源选择因此值得先看一眼，而不能把编辑器中的观察直接当成某个打包版本的运行证据。Unity 6.0 Console 官方说明
如果你想检查手机上的一次操作，却只拿到了编辑器窗口截图，缺少的是观察对象的对应关系。本文不指导连接外部设备，也不提供远程地址；需要连接时应在自己有权限的测试环境中按对应版本文档进行。
二 把搜索条件写进记录
官方文档说明，搜索栏会按输入文本筛选消息，类型按钮也能控制消息、警告和错误的显示。因此，截图里空空如也，只能说明当前视图没有展示目标内容，不足以单独证明没有产生消息。
假设某次练习希望观察“打开背包”这个动作，而搜索栏里还保留着前一次排查使用的 Save。我的第一步是记录这个条件，而不是先改背包代码。检查后是否调整筛选，需要结合当前任务决定，并保留调整前后的区别。
向别人求助时，可以写：“当前关键词为某个非敏感片段，关注的消息类型是某一类，执行了某个动作，列表中仍没有对应条目。”这比只说“日志不出来”包含更多可核验信息。
三 不把折叠后的行数当作调用次数
Unity 文档对 Collapse 的说明是：重复出现的错误消息只显示首个实例。阅读时要区分列表呈现和程序行为，不能仅根据当前看到几行就推算脚本执行了几次。
假想列表只剩一条重复错误，这并不告诉我们错误只发生了一次，也不解释发生原因。若问题关注次数，就应另行设计能观察次数的验证方法，保留对应运行证据；本文没有做这种测试。
我会把“Collapse 当前是否开启”放进排查笔记。这样下一位阅读截图的人至少知道列表呈现条件，不必猜测为什么两张截图的行数不同。
四 清空列表前先保留需要的证据
很多排查会从点 Clear 开始，但如果尚未记下第一条问题出现的操作、时间和完整内容，清空后可能很难再描述原来的现象。我的建议是先保存必要的非敏感记录，再决定是否需要重新观察。
尤其不要在问题尚未复现时，把“清空以后没再出现”写成已经修复。也许没有执行相同操作，也许显示范围改变了；这些都是需要核对的条件，不是本文对某次故障作出的判断。
截图和复制文本也各有用途。截图能保留界面上下文，文字便于检查完整内容。对外分享前应去除账号、令牌、私人路径以及没有授权公开的项目细节，不需要上传整个日志来说明一个筛选问题。
五 为一次观察填写一行记录
下面是原创记录模板，适合练习排查或与同学沟通。每次只改变一个观察条件，有助于说清两次结果为什么可以比较；这是一种方法建议，不是 Unity 的强制流程。
| 字段 | 记录内容 |
|---|---|
| 环境与来源 | Unity 版本，Editor 或具体测试构建的非敏感标识 |
| 触发操作 | 从什么状态开始，实际做了什么 |
| 显示条件 | 搜索词、类型显示、Collapse 状态 |
| 看到的结果 | 具体条目或没有找到目标条目 |
| 尚未确认 | 代码执行、消息产生和传递中哪些没有证据 |
| 下次检查 | 准备单独核对的一个条件 |
例如，你可以把“没打印”改成“在某次测试构建中完成指定动作，当前显示条件下没有找到目标文字”。后一种说法仍然承认未知，但能帮助对方把问题定位到可继续检查的范围。
六 显示范围确认后再研究执行路径
当来源、筛选和呈现条件都已经记录，仍找不到预期消息，再检查具体工程中的触发路径和日志代码会更有依据。这一步需要实际工程与运行观察，不能由一张空列表截图替代。
本文没有提供“关掉某个选项就一定恢复”的保证，也没有把文档核对说成实机修复。它解决的是开始排查前如何描述自己看到的东西，而不是为所有 Console 问题给出同一个答案。
你现在缺少的证据，是消息来自哪个运行对象，还是当前筛选条件是什么？先补清其中一项，再判断是否需要改代码。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2401_85555433/article/details/167075128
