深色模式
日志怎么找、怎么读
本章你将学到：日志是什么、为什么它是升级给技术时最值钱的材料；日志一般藏在电脑的哪几个地方、哪个文件是最新的；怎么看时间戳、级别、关键词和那一大段"堆栈"；怎么让一个完全不懂电脑的用户把日志找出来、打包发给你；以及崩溃转储是什么、该怎么处理。
什么时候用得上：问题没有明确报错、复现不了、或者你已经排查完能排查的但还是没头绪——这时候日志是唯一能告诉你"程序在出事那一刻到底在干什么"的东西。也用于每一次升级：没有日志的升级，技术同事多半要回来重新找用户要。
日志是什么
程序在运行时会把自己在做什么、遇到了什么，一行一行写进一个文本文件里，这就是日志。每一行通常有时间、级别和一句话描述。程序正常时它写"我启动了""我连上服务器了""我开始下载了"；出错时它写"连接超时""文件找不到""发生了异常，详细位置如下"。
大白话
日志是程序的行车记录仪。车撞了，人说不清当时怎么回事，但记录仪拍下来了。你不需要会修车，只要知道记录仪在哪、怎么把撞车前那一段拷出来给修车师傅。
为什么它是升级时最有价值的材料
用户的描述是"感觉"，截图是"某一瞬间"，日志是连续的、精确到秒的、程序自己说的话。它能回答三个其他材料回答不了的问题：
- 出事的精确时刻：用户说"大概八点多"，日志说
20:14:37。 - 出事前程序在做什么：是在连服务器？在校验文件？在加载反作弊？
- 程序自己给出的错误原因：
Connection timed out、Access denied、File not found: xxx.dll。
技术同事拿到一份带日志的升级，可能十分钟定位；拿到一份没日志的，要先花半天找用户重新要，而且用户可能已经重装把日志清了。
日志的通用位置
不同程序把日志放在不同地方，但大体只有这几处：
| 位置 | 怎么打开 | 通常放谁的日志 |
|---|---|---|
安装目录下的 logs / log 文件夹 | 右键桌面图标 → 属性 → "打开文件所在的位置" → 找 logs | 很多程序的主日志 |
%APPDATA%\<程序名>\ 下 | Win + R 输入 %APPDATA% 回车 | 用户级日志、配置 |
%LOCALAPPDATA%\<程序名>\ 下 | Win + R 输入 %LOCALAPPDATA% 回车 | 缓存类日志、崩溃转储 |
%PROGRAMDATA%\<程序名>\ 下 | Win + R 输入 %PROGRAMDATA% 回车 | 服务、驱动、反作弊类组件的日志 |
| Steam 的日志 | Steam 安装目录下的 logs 文件夹 | Steam 自己的连接、下载、工坊日志 |
| CS2 的日志 | CS2 目录下 game\csgo\ 内（如 console.log，需开启控制台日志） | 游戏控制台输出 |
| Windows 事件查看器 | Win + R 输入 eventvwr 回车 | 系统级：程序崩溃、驱动错误、蓝屏、服务失败 |
| 崩溃转储（dump） | 程序目录下的 crashes / dumps，或 %LOCALAPPDATA%\CrashDumps | 崩溃那一刻的内存快照 |
待技术确认
平台客户端的日志目录（安装目录 / %APPDATA% / %LOCALAPPDATA% / %PROGRAMDATA% 中的哪一个或哪几个）、日志文件名格式、反作弊组件 R0Guard 的日志位置、崩溃转储的存放位置，需与技术确认后填入 客户端。本页的"让用户找日志"步骤中出现的目录名以该页为准。
日志文件的命名与轮转
日志会越写越大，所以程序会"轮转"：写满一定大小或到了新的一天，就开一个新文件，旧的改名保留几份，再旧的删掉。常见命名：
| 命名方式 | 例子 | 哪个是最新的 |
|---|---|---|
| 按日期 | app_2026-09-08.log、20260908.txt | 日期最大的那个 |
| 固定名 + 序号 | app.log、app.log.1、app.log.2 | 没有序号的是最新的，序号越大越旧 |
| 固定名 + 启动时间 | client_20260908_201437.log | 时间最大的 |
| 单个固定文件 | debug.log、output.txt | 只有一个，看末尾 |
| 分模块 | launcher.log、downloader.log、anticheat.log | 每个模块各自最新的那个 |
后缀可能是 .log、.txt，也可能没有后缀。不要靠文件名猜，靠修改时间。
让用户找到最新的日志文件
- "打开日志文件夹以后，在文件夹空白处右键，选'查看' → '详细信息'。"
- "然后点一下上面的'修改日期'那一栏标题，让最新的排到最上面（点一下是升序，再点一下是降序，看箭头方向）。"
- "最上面那一个（或几个）就是最新的，把整个文件夹窗口截图给我，我告诉你要哪个。"
| 看到什么 | 说明什么 |
|---|---|
| 最新文件的修改时间就是出问题的时间附近 | 找对了 |
| 最新文件的修改时间是几天前 | 程序最近根本没写日志——可能没启动成功、或日志被关了、或日志在别的目录 |
| 文件夹是空的 | 日志目录不对，或用户清理过 |
| 有几十个文件、几百 MB | 正常，程序跑得久；只要最新的几个 |
怎么读日志
客服不需要"读懂"日志，需要的是从里面找到出事的那一段。方法是四看：
一看时间戳
每行开头通常是时间，如 2026-09-08 20:14:37.123 或 [20:14:37]。把用户说的"出问题的时间"对上去。注意：
- 日志时间可能是 UTC（比北京时间少 8 小时），看到时间"差 8 小时"不要慌。
- 用户说的时间是模糊的，前后各放宽 10 分钟找。
二看级别
| 级别 | 意思 | 要不要关注 |
|---|---|---|
| DEBUG / TRACE / VERBOSE | 程序碎碎念，给开发者看的 | 忽略 |
| INFO | 正常事件："启动""连接成功""开始下载" | 用来判断"走到哪一步了" |
| WARN / WARNING | 不正常但没挂："重试第 2 次""响应慢" | 关注，往往是出事前兆 |
| ERROR | 出错了："连接失败""文件找不到" | 重点 |
| FATAL / CRITICAL | 致命错误，程序要挂了 | 最重点，通常是最后几行 |
三看关键词
用 Ctrl + F 搜这些词（不分大小写）：
| 关键词 | 通常在说什么 |
|---|---|
error、err | 出错 |
fail、failed、failure | 某件事没成功 |
exception | 程序内部异常，后面通常跟堆栈 |
timeout、timed out | 超时，等对方回应等不到，多是网络 |
denied、access is denied、permission | 权限不够，被拒绝 |
not found、no such file、missing | 找不到文件/资源 |
crash、crashed、fatal | 崩溃 |
refused、reset、unreachable | 连接被拒、被断、不可达，网络问题 |
disconnect | 断开连接 |
retry、retrying | 在重试，说明前面有失败 |
0x 开头的一串 | 错误码，原样记下来 |
四看堆栈
日志里偶尔会出现一大段长得像这样的东西：
2026-09-08 20:14:37.845 [ERROR] Unhandled exception in Downloader
System.IO.IOException: The process cannot access the file 'D:\Games\xxx\pak01.vpk' because it is being used by another process.
at System.IO.FileStream.Init(...)
at System.IO.FileStream..ctor(...)
at Downloader.ChunkWriter.Write(Int32 index)
at Downloader.Worker.Run()这叫堆栈跟踪（stack trace）：程序报错时把"出错的位置是哪个函数、被谁调用、再被谁调用"一层层列出来。小白只需要知道两件事：
- 这一大段就是程序报错的详细位置，原样发给技术，一个字都不要删。
- 堆栈第一行（
Exception:后面那句话）通常是人能读懂的原因。上面的例子第一行就说了：文件被另一个进程占用着。
大白话
堆栈像事故现场的照片加地址：技术看一眼就知道是哪条街哪个路口撞的。你不用看懂照片，把照片完整交上去就行。第一行的那句话，是照片旁边写的"事故原因简述"，这个你可以读。
用什么打开、怎么操作
| 工具 | 适合 | 关键操作 |
|---|---|---|
| 记事本 | 几 MB 以内的日志 | Ctrl + F 搜索；Ctrl + End 跳到末尾 |
| VS Code / Notepad++ | 大文件、多个文件 | 同上，而且能高亮、能同时开多个 |
| 浏览器 | 拖进去也能看 | 同上 |
超过几十 MB 的日志记事本会卡很久，让用户别硬开，直接打包发过来。
看日志的顺序：先 Ctrl + End 看最后几行 → 再 Ctrl + F 搜 error 从后往前找 → 再对时间戳。
崩溃前最后几行最重要
程序崩溃、消失、卡死，日志最后写的几行就是它最后在做的事。看最后 20–50 行，通常能看到：
| 最后几行的样子 | 说明什么 |
|---|---|
| 最后是 ERROR/FATAL + 堆栈 | 程序自己崩了，原因就在那段 |
| 最后是正常的 INFO，突然没了，没有任何错误 | 程序不是自己崩的，是被外部结束（杀软、网吧软件、用户结束任务、断电） |
| 最后几行是反复的 WARN "retry" | 在反复重试某件事，之后可能超时放弃 |
| 最后一行是"正在加载 xxx""正在初始化 xxx" | 卡在这一步了，这个 xxx 就是嫌疑 |
| 最后一行时间比用户说的出事时间早很多 | 日志在那之后就没写了，程序可能已经卡死或日志系统本身挂了 |
"正常 INFO 后突然断掉"是判断"崩溃 vs 被结束"最有力的证据之一，和 客户端、启动器与更新器 里的三分法对应。
截取片段 vs 打包整份
| 做法 | 什么时候用 | 怎么做 |
|---|---|---|
| 截取片段 | 你自己快速看、或在工单里贴关键段 | 找到出事时间点，往前 50–200 行、往后 20–50 行，复制到工单 |
| 打包整份 | 升级给技术时一律用这种 | 整个日志文件夹压缩发过来 |
技术需要的是完整上下文，不是你觉得重要的几行。升级永远发整个文件夹的压缩包，片段只作为你在工单里的说明。
让用户打包日志文件夹
- "找到那个日志文件夹（不要进去，停在它的上一级，能看到这个文件夹的图标）。"
- "右键这个文件夹，选'发送到' → '压缩(zipped)文件夹'（Win11 是右键 → '压缩为 ZIP 文件'）。"
- "旁边会出现一个同名的压缩包，把它拖到聊天窗口发给我。"
预期：出现一个 .zip 文件，大小从几百 KB 到几十 MB 都正常。如果超过 100 MB 发不出去，让用户只把最新的几个文件（按修改时间排序的前 3–5 个）单独选中后右键压缩。
隐私注意
日志里可能有：用户名、账号 ID、电脑名、安装路径（含 Windows 用户名）、IP 地址、部分请求内容。所以：
- 日志只在公司内部流转，不发到外部群、不贴到公开平台。
- 让用户发日志前告诉他"日志里可能有您的账号信息，我们只用于排查，不会外传"。
- 工单里贴片段时，把账号、IP 等敏感信息打码。
注意
不要让用户把日志发到任何非公司渠道"帮忙看看"。日志属于用户的隐私数据，处理它是有责任的。
事件查看器导出
Windows 事件查看器是系统级的日志，程序崩溃（"应用程序错误"）、驱动错误、服务失败、蓝屏都在里面。它的看法、筛选和导出方法在 资源监视器与事件查看器 里详细讲。这里只强调：升级崩溃类问题时，客户端日志 + 事件查看器"应用程序"和"系统"两栏在出事时间点的截图是一套，缺一不可。
崩溃转储（dump）
程序崩溃时，系统或程序自己可能把那一刻的内存状态存成一个文件，后缀通常是 .dmp，叫崩溃转储。它比日志更"重"——技术可以用工具还原出崩溃时程序里每一个变量的值。
| 要点 | 说明 |
|---|---|
| 在哪 | 程序目录下的 crashes / dumps / CrashDumps 文件夹；或 %LOCALAPPDATA%\CrashDumps；有的程序崩溃时会弹窗告诉你生成了 dump |
| 多大 | 几 MB 到几百 MB 甚至几 GB，取决于程序当时用了多少内存 |
| 客服要做什么 | 不用看，也看不了。确认有没有、在哪、什么时间生成的，打包给技术 |
| 太大怎么办 | 用压缩能小很多；实在太大问技术要上传方式 |
| 没有 dump 怎么办 | 正常，不是所有崩溃都会生成。日志和事件查看器仍然是主材料 |
待技术确认
平台客户端是否生成崩溃转储、存放位置、是否会自动上传，需与技术确认后补充。
让用户找日志的完整小白步骤
以"日志在 %APPDATA% 下"为例（真实目录以 客户端 确认后的为准）：
- "按键盘上的 Win 键 + R，左下角会弹出一个小框。"
- "在框里输入
%APPDATA%（包括前后两个百分号），按回车。会打开一个文件夹窗口。" - "在这个窗口里找一个叫 XXX 的文件夹（XXX 是客户端的目录名），双击进去。"
- "里面应该有一个叫 logs 或 log 的文件夹。先不要进去，右键点它，选'发送到' → '压缩(zipped)文件夹'。"
- "旁边会多出一个同名的压缩包，把它拖到聊天框里发给我。"
- 如果用户说找不到 XXX 文件夹："那可能在另一个地方。再按 Win + R，这次输入
%LOCALAPPDATA%，回车，同样找 XXX。"
每一步做完让用户说"好了"再给下一步。
| 用户反馈 | 说明什么 |
|---|---|
| "找不到 AppData" | 他在资源管理器里手动翻，那个文件夹是隐藏的。让他用 Win + R 那个方法 |
| "找到 XXX 了但没有 logs" | 日志可能在安装目录，换路径 |
| "压缩包有 200 MB" | 日志多，正常；让他只压最新的几个文件 |
| "拖不进聊天框" | 文件太大或聊天工具限制；用客户端内置的上传（如有）或网盘（注意隐私） |
禁止
不要让用户删除日志文件夹来"清理""重置"或"释放空间"。日志几乎不占空间（通常几十 MB），删了之后这次问题的证据就没了，技术只能等它下次再发生。也不要让用户用"清理软件"的"清理日志"功能。如果确实要清（比如日志占了几个 GB，属于程序 bug），先打包备份再说，并且反馈给技术。
客服看日志的边界
| 客服该做 | 客服不该做 |
|---|---|
| 找到最新的、出事时间点的日志 | 逐行分析每一条 |
| 看最后几行、搜关键词、读堆栈第一行 | 对堆栈内容下结论 |
| 把关键词和错误码记进工单 | 上网搜到一个"解决方法"就让用户做 |
| 判断"是自己崩的还是被结束的" | 判断"是哪个函数的 bug" |
| 完整打包给技术 | 只发自己觉得重要的几行 |
常见误区
- "日志太专业，客服看不懂。" 客服只需要做四件事：找到最新的、看最后几行、搜关键词、原样打包。
- "只发我觉得有问题的那几行。" 技术需要上下文。发整个文件夹。
- "用户已经重装了，日志没了，算了。" 这就是为什么 排查总原则 说不要一上来就重装。这次记录教训，下次先拿日志。
- "日志里有 error 就是出问题了。" 很多 error 是正常的（比如"检查更新失败，将使用本地版本"）。要看时间点和最后几行。
- "日志时间和用户说的差 8 小时，日志坏了。" 可能是 UTC 时间。
- "事件查看器有日志就不用客户端日志了。" 两个是互补的，一起要。
对排查意味着什么
日志在排查流程里的位置：
- 信息收集阶段（信息收集）：崩溃、消失、卡死、登录失败类问题的"补充证据"。
- 假设验证阶段：日志最后几行能直接区分"崩溃 vs 被结束""卡在哪一步""超时还是被拒"。
- 升级阶段（何时升级）：必带材料。没有日志的升级是不完整的升级。
和其他材料的搭配：
| 问题类型 | 日志 + 什么 |
|---|---|
| 崩溃/消失 | 客户端日志 + 事件查看器截图 + dump（如有） |
| 启动失败 | 客户端日志 + 报错截图 + 杀软记录 |
| 登录/连接失败 | 客户端日志 + ping 结果 + 代理设置截图 |
| 下载失败 | 客户端日志（下载器部分） + 任务管理器网络/磁盘截图 |
| 反作弊报错 | 客户端日志 + 反作弊组件日志 + msinfo32 截图 |
自检问题
- 日志为什么是升级时最有价值的材料？它能回答哪三个其他材料回答不了的问题？
- 日志一般在哪几个位置？让用户打开
%APPDATA%的小白说法是什么？ - 一个日志文件夹里有
app.log、app.log.1、app.log.2，哪个是最新的？不确定的时候靠什么判断？ - 读日志的"四看"是什么？堆栈是什么，客服要对它做什么？
- 日志最后几行是正常的 INFO 然后突然断掉，说明什么？
- 让用户打包日志文件夹的步骤是什么？为什么升级时要发整份而不是片段？