日志应从用户任务开始
一份有用的日志先写明当时要完成什么，例如登录、下载、同步文件或打开网页。
没有任务背景的状态码很难解释，也容易让后续排查走偏。
按顺序记录关键环节
入口是否打开、账号是否通过、客户端是否读取配置、节点是否建立连接、目标服务是否响应，是一条完整链路。
只记录最终失败，会失去判断位置的依据。
保留原始提示而不是自行改写
错误提示、发生时间和版本号应按原样保存。
不要把“请求超时”改写成“服务器故障”，因为前者描述现象，后者已经加入未经验证的结论。
让每次调整都能说明问题
先换节点并完成原任务，观察结果后再决定是否换网络。
若同时升级客户端、切换网络并更换配置，即使恢复正常，也无法知道真正原因。
每项调整之间留出一次完整测试，日志就会形成清楚的前后对照。
一条实用日志长什么样
例如：“20:15，Windows 11，家庭Wi-Fi，Linkcube客户端可以登录；打开资料页时主文档正常，图片约十秒后出现；切换到移动热点后图片恢复。
”这段话没有猜测服务器故障，却交代了时间、设备、任务和对照结果。
比起堆叠几十个字段，它更容易让另一名使用者继续复现。
何时适合暂停操作
如果页面开始要求与任务无关的敏感信息、下载来源无法确认，或短时间内连续出现账号验证限制，应先停止操作。
反复刷新和重复登录可能让现象更复杂。
可以保留错误原文和发生时间，稍后从已知首页重新进入，或在帮助页查找对应情形。
把日志变成可以交接的信息
个人排查完成后，可以把记录整理成三段：当时要做什么、第一处异常是什么、调整后结果怎样。
团队成员看到这三段，就能从同一位置继续，而不是重新询问所有背景。
不要发送密码、验证码和完整订阅地址；需要截图时遮住账号、令牌和个人文件名。
若问题只在某台设备发生，再补充系统版本和客户端版本；若多台设备同时发生，则补充网络与时段。
这样的交接既保护隐私，也能缩短重复确认。
日志应在问题解决后收尾
恢复正常后补上最后一次测试的时间和结果，并注明实际有效的操作。
无关尝试不必全部删除，但可以标明没有产生变化。
若问题后来再次出现，新的记录应接在原结果之后，而不是覆盖旧内容。
保留前后差异能够判断异常是否重复，也能避免把短暂恢复误认为长期解决。
完成收尾后，下一次相同现象就有明确基线，不必重新回忆当时做过哪些操作。