从登录失败说起
早上刚到公司，用户群里就炸了：好几个同事反映系统登录不了。客服电话不断，运维压力瞬间拉满。这时候别急着重启服务，先看客户端日志——往往问题就藏在里面。
明确你要找什么
客户端日志动辄几百MB，逐行翻不现实。得带着目标去看。比如登录失败，重点关注auth、login、token这些关键词。用grep快速过滤：
grep -i "login\|auth" client.log如果发现Invalid token signature，基本就能锁定是认证签名验证失败，可能是本地时间不同步，也可能是Token被篡改。
时间线对齐很关键
用户说“我点了登录就没反应”，但日志里却没记录。这时候别急着说“你再试试”。先确认客户端时间和服务器是否一致。差了几分钟，可能刚好让Token过期，日志里就会留下Token expired at 2024-05-12T10:05:00Z这样的线索。
遇到这类问题，让用户提供截图的同时，也顺手记下他的设备时间。对比NTP服务器时间，往往能发现端倪。
别忽略堆栈信息
有些错误不会直接报错，但日志里会留下Java或JavaScript的堆栈跟踪。比如：
TypeError: Cannot read property 'id' of null
at UserService.processUser (user.js:45)
at LoginController.onSuccess (login.js:22)这种明显是代码逻辑没处理空值。虽然看起来像开发的问题，但作为运维，你能第一时间把现场证据交出去，比扯皮“是不是网络问题”高效得多。
善用日志级别筛选
很多客户端默认只打INFO以上级别的日志。真出问题时，建议让用户临时切换到DEBUG模式。比如在配置文件加一行：
<logger level="DEBUG" output="file" />立刻就能看到更详细的请求参数、响应头、缓存状态。有时候发现Cache miss for user config，才知道是配置没拉下来，根本不是网络的事。
批量处理多个日志文件
一个用户不够判断？那就收集一组。用脚本统一提取关键字段：
for file in *.log; do
echo "=== $file ==="
grep "ERROR\|WARN" "$file" | head -5
done如果十个用户日志都出现Failed to connect to api.example.com: timeout，那基本可以确定是DNS或网络策略问题，而不是个别设备故障。
建立常见错误速查表
把高频错误整理成内部小文档。比如：
Network Error (ERR_CONNECTION_RESET)：本地防火墙或代理拦截Certificate expired on ...：系统时间不准或证书未更新413 Payload Too Large：上传文件超限，非网络问题
新人来了也能快速上手，不用每次都从头排查。