大家好我是 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 问题给出同一个答案。你现在缺少的证据是消息来自哪个运行对象还是当前筛选条件是什么先补清其中一项再判断是否需要改代码。