先说个真实场景：手机游戏打到一半直接闪退回桌面，或者微信视频突然断流，你去联系官方售后，工程师开口第一句大概率是“麻烦抓一份 Log”。很多朋友一听“Log”就懵了，觉得是不是要刷机、要写代码、要拿到什么内部工具才行。其实抓日志这件事，说穿了就是把手机里记录问题过程的“黑匣子数据”导出来，拯救者系列机型在系统层面早就给好了入口，官方教程里的标准流程甚至比你想的还要简单，只是没人把这套东西完整串起来讲一遍。
这篇文章专门写给拯救者手机用户，同时也适合刚入门的开发者或者做手机测试的朋友。我会从日志是什么、为什么非抓不可开始，把官方的图形界面入口、ADB 命令行抓取、Bugreport 快照提取、内核日志和专项日志这几条路都走一遍，最后把我这些年抓 Log 踩过的坑一并列出来。看完之后你不需要再到处问“日志在哪”，直接照着操作就能交出一份能用的、结构清晰的日志包。
1. 抓 Log 之前，先搞清楚手机日志里到底有什么
1.1 系统里的日志不是只有一种
很多人以为 Log 就是“一个文本文件”，其实手机端的日志分好几层。平时我们用 adb logcat 抓到的，叫系统日志，它主要记录应用层的输出，比如某个 App 崩溃时的异常堆栈、系统服务的报错、权限拒绝这类信息。系统日志内部还分了好几类缓冲区，常见的 main、system、radio、events 各有各的用途：main 存应用普通输出，system 存系统进程的调试信息，radio 存电话和网络相关的日志，events 存系统关键事件。
除了系统日志，还有内核日志，也就是 dmesg，记录的是驱动、电源管理、内核崩溃这类底层信息。手机如果出现莫名重启、冻屏、充不进电，光看 logcat 往往找不到根因，得靠内核日志。另外还有一类是 Crash 日志，安卓系统会把应用崩溃和系统崩溃的现场快照单独存下来，集中在 DropBox 和 tombstone 目录里。最后还有厂商和硬件平台专项日志，比如 Wi-Fi 连接日志、移动网络信号日志、传感器日志。拯救者这类游戏手机，还会额外记录游戏场景下的帧率、温度、功耗数据。
1.2 Log 记录一次崩溃的过程，可以这样理解
把 Log 想象成飞机的黑匣子或者行车记录仪更直观。你的手机某个时刻出了问题，系统的各个模块会在那一瞬间把“我看到了什么”“我正在做什么”写进日志缓冲区。工程师拿到日志，就是回放这一小段现场，判断到底是 App 自己崩了，还是系统杀进程杀的，是驱动休眠出问题，还是网络切换触发了异常。
举个例子，一个游戏闪退问题。正常流程下，用户在游戏界面看到的是“应用程序已停止运行”，但在日志里，你会看到类似 FATAL EXCEPTION、AndroidRuntime、Process com.xxx.game 这类关键词，紧接着是 Java 堆栈，指向具体是哪一个类、哪一行代码抛的异常。如果问题更底层，比如 GPU 驱动崩溃，你可能会在内核日志里看到 GPU 相关的错误。这些信息对于定位问题性质，是区分“软件的锅”还是“硬件的锅”，非常关键。
1.3 普通用户和开发者要的 Log 完全不一样
这一点不提前说清楚，很容易白抓。普通用户找客服，客服要的一般是“截图 + 系统日志包”，他们通过日志里的崩溃栈判断现象是不是已知问题，所以对格式要求比较宽松，但要求日志能完整覆盖问题发生的前后几分钟。开发者或测试人员要的则精细得多，可能需要指定进程的 log、热点时刻的 CPU 调度、甚至内核事件序列。
所以抓 Log 之前，先问清楚对方到底要什么。如果是官方客服让你提交，优先用手机系统自带的日志抓取，其次是 Bugreport；如果是开发者让你 adb logcat，那你就按照他给的命令来，不要自己换过滤条件。盲目抓一份几十兆的日志发过去，看起来诚意满满，实际有效信息可能早就被无关输出刷掉了。
2. 两步准备：开发者选项、USB 调试和那根不冤枉的数据线
2.1 开启开发者选项的正确入口
在拯救者机型上，开发者选项默认是隐藏的。打开方式是进“设置”，拉到最下面找“关于本机”，找到“版本号”这一项，连续点击 7 次。点的时候会提示“再点 X 次即可进入开发者模式”，直到提示“您已处于开发者模式”，然后返回设置主页就能看到“开发者选项”了。不同系统版本入口稍微有点差异，有的在“设置-我的设备”里，有的在“设置-更多设置”里，但关键步骤都是一样的。
如果不做这一步，后面的 ADB 命令、错误报告入口全都用不了。系统自带的“一键抓取日志”功能，很多版本虽然不强制要求开发者选项，但为了保证能抓到完整系统日志，我建议还是开一下，实在不想开就先用自带功能，后文会讲。
2.2 开发者选项里这 4 个开关必须检查
进到开发者选项之后，不是每个开关都要动，但下面几个直接影响能不能抓 Log：
- USB 调试：必须开。这是 ADB 连接的基础，关了之后电脑上
adb devices什么都看不到。 - “USB 调试（安全设置）”或类似选项：部分机型有，主要控制是否允许通过 USB 模拟输入等操作，一般保持开启。
- “日志记录器缓冲区大小”：这个建议手动调大。默认情况下日志缓冲区可能只有 256KB 或 1MB，系统日志多的时候，前面几条还没来得及看就被后来的日志覆盖了。我习惯调到 4MB 或 16MB，抓取窗口更宽裕。
- “错误报告”或“Bug report”入口：有些系统版本在这个界面直接有“提取错误报告”按钮，这就是我们后面要说的 Bugreport。
另外提一句，开启了 USB 调试之后，如果长时间不连电脑，系统会自动撤销授权，下次插上又得重新点授权框，这是正常现象。
2.3 数据线、驱动和授权框三个连环坑
准备工作里最容易翻车的地方，不是设置，而是物理连接。第一个坑是数据线不对。现在很多充电线内部只接了电源线，没有数据通道，插上之后手机明明显示在充电，但电脑设备管理器里毫无反应。抓日志之前先确认数据线能传输文件，最简单的测试方法是插到电脑上，看手机端有没有弹出“允许访问手机文件”的提示。
第二个坑是驱动。Windows 系统如果之前没装过安卓 USB 驱动，adb devices会显示unauthorized或者干脆empty list。官方教程建议从手机品牌官网或系统工具更新器里安装驱动组件，但如果你只是临时用，也可以先试试 Windows 自带的“更新驱动程序”。Mac 和 Linux 下绝大多数情况不需要额外装驱动，插上就能识别。
第三个坑是授权弹窗。第一次连电脑，手机屏幕上应该会弹出类似“是否允许 USB 调试”的窗口，必须点允许，并且建议勾选“始终允许使用这台计算机进行调试”。如果你插上之后根本没看到弹窗，可以拔线重新插，或者在开发者选项里先关闭再开启 USB 调试，也可以点“撤销 USB 调试授权”后重新授权。
3. 先选最简单的路：系统自带的一键日志抓取
3.1 自带功能在哪，官方文档其实就这么说的
很多朋友不知道，拯救者机型其实内置了给普通用户用的日志抓取工具，一般在“设置-用户反馈”或“设置-我的设备-反馈辅助”这类位置，名字可能叫“一键反馈”“日志抓取”“提交错误报告”，不同系统版本会有差异。官方教程通常推荐先走这条路，因为它是按系统自己的节奏抓的，时间戳、目录结构、日志范围都是规范好的，你不用记任何命令。
进到反馈工具之后，一般会让你先勾选问题类型，比如“异常重启”“游戏闪退”“网络异常”，然后点“开始抓取”。这时候系统会在后台录制日志，你只需要去做操作复现问题，复现完了回到工具里点“停止”，系统会把这一段时间内所有相关日志打包成一个 zip 文件。接下来按系统提示走分享流程，通过邮件、云盘或者官方反馈通道上传。
3.2 游戏场景还有专门的日志开关
游戏手机和平常手机不太一样的地方在于，它有一套专门的游戏场景管理能力，比如游戏助手、游戏空间这类模块。里面通常会提供“游戏日志”或“性能日志”开关。如果你是打游戏闪退、卡顿、掉帧的问题，不要只抓系统日志，应该先把这个开关打开。
进了游戏助手之后，找到与“性能”“日志”相关的菜单，打开“记录游戏日志”，部分版本还能同时录制屏幕和记录帧率曲线。然后正常进游戏复现问题，退出游戏之后，在游戏助手的历史记录里能看到刚才的日志条目，可以直接导出。这样抓到的日志包含了系统层、游戏层和性能数据三层信息，比通用日志有用得多，发给售后工程师基本不用二次沟通。
3.3 为什么我建议新手先从这里开始
你说 ADB 难吗？真不难，背几条命令就会了。但它对小白有门槛，光环境变量、驱动、命令行这些词就可能劝退人。系统自带抓取工具的优点就是零门槛，而且日志是系统按规范打包的，不会出现“漏抓某个缓冲区”“格式乱码”这种低级问题。
有一点要注意：自带工具抓出来的包通常不包含内核日志，如果你遇到的是重启、冻屏这类底层问题，单靠它可能不够。我的建议是，普通闪退、网络断流、耗电异常优先用自带工具；重复重启、彻底冻屏、开机异常这类问题，再用后面的 Bugreport 和内核日志方案。
4. ADB logcat 实时抓取实战：复现类问题的主力方法
4.1 一分钟搭好 ADB 环境
ADB 全称 Android Debug Bridge，是安卓官方提供的调试工具。抓日志之前，电脑上先要有 adb 程序。最省事的方法是从安卓开发者官网下载包含 adb 的 Platform Tools 压缩包，解压到一个路径里，然后在命令行进入这个目录，所有命令就都能用了。
Windows 用户建议把解压目录记住，比如D:\platform-tools，之后每次打开命令行要cd /d D:\platform-tools。也可以在系统环境变量的 Path 里加上这个目录，这样以后不需要 cd 也能直接敲 adb。Mac 和 Linux 下用法类似，文件解压后直接在终端里运行./adb，或者配置 alias。
连接手机之前，确保 USB 调试已经打开，然后用数据线连电脑，命令行输入：
adb devices看到类似下面这行就代表连接正常：
List of devices attached R58N12345678 device如果显示unauthorized，去手机屏幕确认授权弹窗；什么都没显示，回到第 2 章排查驱动和数据线。
4.2 第一条抓取命令，先学会保存到文件
实时抓取日志最常用的命令是这样：
adb logcat -v threadtime > D:\logs\bug_20250101_1200.log-v threadtime表示每条日志前面带上日期、时间、线程号，这是我最推荐的格式，因为它能让你在回看的时候分清事件发生顺序和线程关系。>后面的路径是自己定义的日志文件位置，Windows 注意不要在路径里留空格，避免命令行解析出错。
敲完这条命令后，屏幕会持续刷新，这就是系统正在输出的实时日志。这时候不要急着动，先让日志跑起来，然后去复现问题。问题触发后，回到命令行按Ctrl + C停止抓取，日志就留在刚才指定的文件里了。如果之前已经抓过又忘了删，>会直接覆盖文件，想追加而不覆盖就把一个>换成两个>>。
4.3 复现问题的标准节奏
抓实时日志的核心不是命令，而是节奏。官方工程师给了个很经典的要求：开始抓取的时刻，要在问题发生之前至少 30 秒，结束的时刻，要在问题发生后至少 5 秒。为什么要这样？因为日志是需要“前因”的。比如一个闪退，触发闪退的关键异常前几百毫秒，可能网络、内存、信号都在发生剧烈变化，这些信息如果没抓到，工程师只能看到结果看不到原因。
我的习惯是，抓之前先在手机设置里把自动锁屏关掉，把通知提醒降到最低，减少无关日志刷屏。然后在电脑上开一个记事本，记下当前时间，开始抓取后，做 2 到 3 次复现操作，每次操作的时间点都记下来。这样日志传过去之后，对方可以直接按时间点切进去看，而不是在一堆日志里大海捞针。
4.4 日志量太大，怎么快速定位关键内容
如果问题已经稳定复现，日志文件里全是无关输出，几条命令就能筛出来。
先看有没有崩溃信息：
adb logcat -d -v threadtime AndroidRuntime:E *:S-d意思是把当前缓冲区里的日志一次性 dump 出来然后退出，不加则进入实时刷屏模式。AndroidRuntime:E *:S表示只显示 AndroidRuntime 标签下 Error 以上级别的日志，其他标签全部静默，这样定位崩溃堆栈特别快。
如果想看某个 App 的完整日志，先找到它的进程 ID：
adb shell pidof com.某个包名然后用 PID 过滤：
adb logcat -v threadtime --pid=12345这个方法比用包名过滤更准，因为一个应用可能开多个进程。另外，游戏场景下如果发现崩溃和系统内存有关，可以搜关键词lowmemorykiller、am_proc_died；如果是网络断流，搜wifi、wlan、mobile data相关 tag 会更有帮助。
4.5 缓冲区被覆盖了别慌，先看这一段
刚才提到开发者选项里的“日志记录器缓冲区大小”，为什么建议调大？因为 logcat 的缓冲区是循环的，写满了之后最早的日志会被覆盖。如果你开完抓取之后过了很久才复现问题，等到崩溃发生时，崩溃前 30 秒的关键日志可能已经被后续刷屏覆盖掉了。
所以抓实时日志的时候，时间窗口要克制，我建议整个抓取过程控制在 5 到 10 分钟以内，最多不要超过 20 分钟。问题稳定触发，就快速复现一次立刻停；问题间隔时间长，再考虑放宽，但中间不要让手机一直挂着加载动画和日志刷屏。如果发现停止抓取后，文件开头并不是你想要的“问题前 30 秒”，那大概率是缓冲区不够或抓得太晚，直接调大缓冲区再来一次。
5. 问题已经发生、没法现场复现？用它：Bugreport 快照提取
5.1 Bugreport 是什么，和 logcat 有什么不同
logcat 抓的是“实时流水”，Bugreport 抓的是“全家福快照”。它不是简单把 logcat 存下来，而是会执行一连串系统命令，把当前的系统状态、运行中的进程、内存信息、电池历史、网络统计、已经发生的崩溃记录、内核日志、应用 ANR 痕迹等打包到一起。安卓 7 以上，一条adb bugreport命令会直接生成一个 zip 压缩包，里面是结构清晰的各类文本。
什么时候用 Bugreport？我总结三种情况：一是问题已经发生过了，不能现场复现，比如昨晚自动重启了一次，今天想拿昨晚的证据；二是问题涉及多个模块，比如耗电异常且伴有发热和断流，单独抓 logcat 很难覆盖全面；三是官方工程师明确要求完整数据包。一句话，logcat 适合“我正在现场守着复现”，Bugreport 适合“事情已经过去了，我要留取现场证据”。
5.2 两种获取方式，命令行和手机操作都对
命令行方式最简单，手机连电脑之后执行：
adb bugreport D:\logs\bugreport_20250101.zip这条命令会生成一个带时间戳的 zip 文件。第一次跑它可能耗时 1 到 3 分钟，期间命令行没有输出，属正常情况，不要急着 Ctrl+C。生成之后到指定目录查看，如果只看到一长串类似bugreport-xxx-2025-01-01-12-00-00.zip的文件，那就是对的。
不连电脑的获取方式也有：进开发者选项，找到“错误报告”或“Bug report”，点击后会弹出提示，选择“完整报告”，系统会生成一个 zip，接着弹出发送方式，你可以存到网盘或通过邮件附件发送。这种方式适合身边没电脑的朋友，但完整报告生成过程中，手机界面会有一小段时间卡顿，属于正常现象。
5.3 文件到手之后怎么让工程师一眼看懂
Bugreport zip 里包含的东西非常多，直接按原名扔给客服可能让人头疼。我自己的做法是先重命名，命名格式统一成“机型_系统版本_问题描述_时间”。比如：
Legion_2025_Android14_GameCrash_20250101_1200.zip系统版本可以在“设置-关于本机”里看到，Android 大版本和系统补丁版本都带上。问题描述尽量写得具体，别写“有问题”这种，要写“玩某游戏十分钟后闪退回桌面”、“待机一夜掉电 30%”这种能被复现的表述。
另外，官方反馈渠道通常有单独的提交入口，比如开发者社区、用户反馈工具或客服工单系统。如果对方提供上传链接，直接把 zip 传过去即可；如果只能通过邮箱发送附件，注意邮箱附件大小限制，太大的包优先传云盘再发链接，避免邮件被退回。提交之后把对应的工单号记下来，后续沟通直接报号，效率高很多。
5.4 Bugreport 里的隐私，不检查就发等于裸奔
这一点必须重点说。Bugreport 是系统级快照，里面会包含你的手机号对应的 SIM 卡信息、IMEI、MAC 地址、已安装应用列表、Wi-Fi 网络名称，甚至部分通知和账号相关字段。官方客服系统当然能看到这些，但如果这个包要发到公开的论坛、开发者群，甚至只是发给线下朋友帮忙看，那就必须脱敏。
脱敏不复杂，把 zip 里的 txt 文件解压出来，用文本编辑器搜一下自己的手机号、微信号、常用账号名，看到相关内容直接替换成***再重新打包。如果整个流程你嫌麻烦，那就守住一条底线：包含隐私信息的 Bugreport 只通过官方正规提交渠道发送，绝对不要丢到公开渠道。
6. 重启、断流、卡顿这类疑难杂症，还得靠内核和专项日志
6.1 dmesg 内核日志怎么抓
系统日志覆盖不到底层问题时，就该上内核日志了。最基础的命令是：
adb shell dmesg > D:\logs\kernel_20250101.logdmesg 输出的是内核环形缓冲区的信息，包括驱动加载、电源状态切换、温度、CPU 频率、I2C 通信、USB 枚举等底层内容。比如手机自动重启，logcat 里往往只能看到“system_server 死了”这种结果，但内核日志里可能会有watchdog、panic、power supply相关的关键行，指向触发点。
这里提醒一下，多数市售稳定版系统里，普通用户用adb shell dmesg会提示权限不足，因为新版安卓收紧了内核日志的读取权限。如果你在自己手机上执行后没有任何输出，不要怀疑命令写错，这是正常限制。这种情况下可以试试：
adb shell cat /proc/last_kmsg这个文件保存的是上次关机或重启前的内核日志，但很多新机型同样没有这个节点。真要深挖内核层，通常需要官方提供调试版本固件，或者使用开发者模式配合特定工程权限，这个一般普通用户接触不到。你只需要记住：内核日志抓不到时，Bugreport 里的部分 dump 信息也能提供补充，不要因此卡住整个反馈流程。
6.2 Wi-Fi 断流和移动网络问题的专项抓法
网络类问题，光靠 logcat 的 radio 缓冲区不够，还需要打开系统的 Wi-Fi 详细日志。在开发者选项里找“启用 Wi-Fi 详细日志记录”之类的开关，打开后系统会把 Wi-Fi 连接的底层层信息写进日志。然后按前面的方法用 logcat 抓取，过滤 tag 的时候多关注wpa_supplicant、wifi、WifiStateMachine、WifiMonitor这些关键词。
移动网络断流，则要重点看 radio 缓冲区的日志。抓取时建议指定缓冲区：
adb logcat -v threadtime -b radio > D:\logs\radio_20250101.log如果你对日志里的专业内容不熟悉，不要试图自己分析，只需要保证“问题发生时 radio 日志没有被覆盖”就行。我遇到过很多人抓网络问题，开着下载任务一遍遍测网速，结果几十分钟下来，radio 缓冲区早就被刷没，最后发过去的日志里一条断流时间点的有效记录都没有。正确做法是，打开日志抓取后，把手机切换到飞行模式再关掉，或者开关一次 Wi-Fi，制造一次干净的连接动作，然后马上停止。
6.3 游戏卡顿和掉帧，用 Perfetto 抓性能轨迹
如果问题是“游戏卡顿、掉帧、帧率波动”，logcat 能提供的信息非常有限，这时候要用性能追踪工具。安卓官方的 Perfetto 可以记录一段时间的 CPU 调度、线程状态、GPU 频率、内存分配过程，比看帧率数字有说服力得多。
Perfetto 的完整界面在浏览器里，但命令行也能直接用。Android 9 以上的机型，基本命令是：
adb shell perfetto -o /data/local/tmp/perfetto.trace -t 10s sched freq idle这条命令会在手机上记录 10 秒的调度和频率信息，结束后需要再拉取到电脑：
adb pull /data/local/tmp/perfetto.trace D:\logs\然后把 .trace 文件拖进 Perfetto 的可视化页面里查看。比较尴尬的是，普通用户看到一堆线程信息和 CPU freq 曲线很难快速定位问题，所以我更推荐把它作为“官方工程师要求时再跑”的工具。普通用户遇到卡顿，老老实实用系统游戏助手录屏加导日志，性价比最高。
6.4 拯救者机型游戏场景的完整抓取组合
官方售后在收到游戏类问题反馈时，最理想的数据组合是：一段录屏、一份游戏日志、一份系统日志和一份性能数据。前面三个很好理解，性能数据指的就是帧率、温度、CPU 占用这类指标。拯救者系列的游戏助手里一般自带性能浮窗和日志记录功能，建议你们平时就熟悉一下入口在哪，别等到问题发生了才翻半天。
我的经验是，先把游戏助手里的“日志开关”打开，同时开启录屏和帧率显示，然后玩一把，尽量把问题复现出来。退出游戏之后导出的日志包都保留好。如果问题严重到会重启手机，建议额外补一个 Bugreport，因为重启后游戏助手的实时日志可能没来得及落盘，Bugreport 里的 last reboot 信息反而更关键。整个组合打包后按第 5 章的命名规范提交，官方一般很容易就能定位方向。
7. 我踩过的坑：从“抓了等于白抓”到“一份日志就能定位”
7.1 手机时间不准，日志时间线整体错乱
这条是新手最容易忽略的坑。logcat 的 threadtime 时间戳用的是手机本地时间，如果手机时间没开自动校准，或者时间差了好几分钟，那么日志里的时间点和你的复现记录就对不上。工程师按你给的时间点切进去看，看到的完全是另一段时间的内容，第一印象就是你乱抓。
解决方式很简单：抓日志之前，先在系统设置里打开“自动确定日期和时间”，然后开飞行模式再关掉，强制触发一次网络校时。然后再记录复现时间点。别小看这一步，我见过有人日志里的时间比真实时间晚了 8 个小时，整个文件直接作废。
7.2 抓太久不是勤快，是浪费
很多人觉得日志抓得越久越全面，结果一抓就是一下午。问题是 logcat 缓冲区循环覆盖，你最后拿到的可能是“问题刚结束之后”的日志，而不是“问题发生之时”的日志。系统自带的抓取工具一般有时间上限，命令行的 logcat 没有，全靠自己控制。
正确的做法是：先确定一个可重复的操作步骤，把抓取窗口压缩到问题前后各 1 分钟。比如问题是在启动游戏后第 3 分钟出现，就先打开日志，等 30 秒，开始操作，第 3 分钟问题出现，再等 5 秒，停止。这样即使缓冲区不大，关键信息也不会丢。
7.3 日志文件传到电脑后，别在聊天软件里反复转
logcat 输出的是纯文本，但量大到一定程度后，通过聊天软件传输很容易被压缩、改名、截断。更麻烦的是，聊天软件还会把 zip 处理成“无法直接下载”的格式，对方工程师可能压根打不开。我建议走网盘链接或者邮件附件，文件到手后确认一下 zip 大小有没有变化，解压一下保证能正常打开。
如果你把日志复制进 Windows 记事本准备自己看，遇到几个 G 的日志文件，记事本会直接卡死。用支持大文件的文本工具，或者先用命令把无关信息过滤掉再查看，思路也比直接硬啃强。
7.4 上传前花两分钟搜一遍隐私信息
第 5 章说过 Bugreport 里的隐私问题，其实 logcat 也可能包含个人数据。某些应用会把账号名、邮箱地址、搜索关键词通过 Log 输出到系统日志。发之前建议用文本编辑器搜一下自己的手机号、微信号、邮箱地址，顺手把http链接也扫一眼，看到敏感内容就删除或打码。
注意一点，这个动作只是为了保护你自己，不要影响日志里的核心内容。日志里如果包含部分内部文件的路径，这个不用管，那是定位问题需要保留的。你删的是“账号类、位置类、凭证类”信息，不是系统路径。
7.5 最后分享一个我一直在用的抓日志小脚本
每次都手动敲命令，时间长了总会漏点什么。我给自己写了一个 Windows 批处理脚本，一条命令解决“清空旧缓冲区、抓新日志、自动命名”三个痛点。
@echo off set /p desc=请输入问题描述: set now=%date:~0,4%%date:~5,2%%date:~8,2%_%time:~0,2%%time:~3,2%%time:~6,2% set now=%now: =0% set out=D:\logs\%desc%_%now%.log adb logcat -b all -c adb logcat -v threadtime > %out% echo 日志已保存到 %out%这段脚本的逻辑是：先清空所有缓冲区，保证新日志里只有本次复现过程；然后以“描述_时间”为文件名开抓，停止时按 Ctrl+C。每次要抓的时候，运行脚本，输入问题描述，然后去复现问题就行。理解这个思路后，你也可以把它改写成 Mac 的 shell 脚本，核心就是adb logcat -b all -c清缓冲区那一步。
这些年经手了不少日志反馈单，最大的体会是，大多数人不是不会抓，是抓的时候不会“围绕问题设计抓取窗口”。设备型号、系统版本、复现步骤、问题时间点，加上一份覆盖问题前后 1 分钟的干净日志，这五样凑齐了，基本没有工程师说看不懂的。下次再遇到手机出问题，按这个思路来，你会发现所谓“Log 抓取全指导”，真正难的地方其实在于你有没有把整个现场还原出来。
