页面打开，只证明入口有响应
浏览器能够显示登录页，证明的是域名解析、网络连接和页面响应至少完成了一部分。它没有证明账户存在、密码正确、验证码有效，也没有证明服务器已经为当前浏览器建立登录会话。把“页面能开”直接理解成“登录服务正常”，会让后面的提示失去位置。
先记录地址栏中的域名、协议和最终路径，再看页面标题及按钮文字是否符合预期。若点击收藏夹后经过多次跳转，或者页面要求在陌生域名输入密码，应停止操作。本站不提供登录表单，也不会要求提交密码、验证码、Cookie或付款资料。
把一次登录拆成四个阶段
第一阶段是入口响应；第二阶段是凭据或验证码提交；第三阶段是服务器建立会话；第四阶段是登录后的账户内容加载。四段可能由不同请求完成，因此失败提示也不同。入口白屏、验证码未到、提交后回到原页、进入后内容空白，分别指向不同观察点。
MDN对网页登录过程的说明指出，服务器通常在验证成功后向浏览器发送包含会话标识的Cookie；浏览器随后在同站请求中带回该标识，服务器才知道这是已经登录的访问。这里引用的是通用Web机制，不代表Kuromis必然使用某一种Cookie名称或固定有效期。
验证码没有到达时先看时间线
验证码阶段应记录发送时间、接收渠道和页面倒计时，而不是连续点击发送。邮件可能进入垃圾邮件目录，短信可能受运营商过滤或延迟影响；连续请求还可能使前一组验证码失效。若页面明确显示冷却时间，应等待当前周期结束再尝试。
收到验证码后只在已核对的原入口使用，并确认页面仍是同一域名。不要把验证码转发给所谓客服，也不要在聊天窗口或第三方表单中提交。验证码只证明一次验证尝试，不能代替对入口身份的核对。
提交成功与会话建立不是同一句话
按钮变成加载状态，说明前端开始处理；出现HTTP响应，也不保证业务结果成功。Fetch API的通用语义是：只要服务器返回响应头，请求接口就可能获得Response，即使状态码表示错误。对普通用户而言，最有用的证据是页面最终停在哪里、出现什么提示，以及是否回到原入口。
如果提交后短暂出现账户页又立即退回登录页，问题更接近会话保存或会话被撤销；若始终停在验证码页面，则应先处理验证阶段。不要在两种现象之间来回清理全部数据，因为那会同时改变Cookie、缓存和本地存储，难以判断是哪一个因素起作用。
登录后空白要区分框架与内容
有些账户页先加载页面框架，再请求个人资料、订阅信息或设备列表。此时导航栏出现而正文空白，说明入口和部分静态资源已经到达，但后续内容请求可能失败、超时或被会话状态拒绝。它和整个页面无法打开不是同一个故障。
可先等待一次完整加载，记录空白区域是否出现错误文字，再刷新一次。若刷新后仍相同，使用同一设备换一个正常网络做对照；不要同时换设备、浏览器和网络，否则即使恢复也无法知道哪个条件参与了变化。
隐私窗口只能回答一个有限问题
隐私窗口通常使用独立的临时Cookie与缓存空间。原窗口失败、隐私窗口成功，说明原浏览器状态可能参与问题，但不能直接证明某个Cookie损坏；扩展程序、站点权限或旧缓存也可能产生差异。这个对照的价值是缩小范围，而不是立即删除全部浏览数据。
若两个窗口都在同一阶段失败，再换网络比继续清缓存更有信息量。若只有原窗口失败，可先退出账户、关闭相关标签页，再只清理该站点的数据。清理前应确认自己仍掌握正确入口和账户恢复方式。
缓存可能保留旧画面，但不能解释所有失败
RFC 9111说明HTTP缓存会依据新鲜度与验证机制复用或更新已存响应。于是浏览器看到旧登录文案、旧维护提示或旧跳转页，理论上可能与缓存有关。不过，验证码错误、账户限制或服务端拒绝不会因为清除静态页面缓存就自然消失。
判断方法仍是对照：同一入口在隐私窗口显示新页面，而普通窗口持续显示旧内容，缓存参与的可能性增加；所有设备和网络都返回相同业务提示，则更应保留提示并等待可核对的服务渠道说明。
用最小记录代替反复尝试
一条有效记录可以写成：设备与系统、浏览器、最终入口路径、尝试时间、停留阶段、页面原文、是否收到验证码、是否短暂进入账户页。无需记录密码、完整手机号、邮箱内容或会话标识。这样既保护隐私，也足以让后续排查知道问题发生在哪里。
每轮测试仅保留一项差异，并在结果后写明变化。例如“原浏览器回到入口；隐私窗口仍回到入口”，说明本地旧会话不是唯一解释；“Wi-Fi超时，移动网络进入验证码页”，只说明接入网络参与可达性，仍不能证明账户验证已经正常。
这些情况应立即停止
若页面域名与既有入口不符、证书警告无法解释、页面索取支付密码或完整订阅地址、所谓客服要求提供验证码，均应停止。即使页面设计和品牌名称看起来熟悉，也不能代替域名与连接安全核对。
如果多次请求已经触发频率限制，应等待提示给出的时间，不要继续自动刷新。账户被锁、身份资料变更或支付争议属于经营方权限范围，独立指南不能替代账户支持，也不能承诺恢复时间。
从记录决定后续处理
停在入口响应以前，可转到故障索引检查DNS、网络和浏览器；停在验证码阶段，应核对接收渠道与等待时间；提交后回入口，重点观察会话和域名跳转；进入后空白，则记录具体缺失模块与网络对照。这样的分流比重复输入凭据更安全。
完成一次记录后，进入本站账号章节查看对应说明。若稍后恢复，也保留首次失败与恢复时间；时间差能帮助区分短暂服务变化和稳定的本地条件，而不是把一次成功当成所有问题都已经消失。