日志与崩溃报告
Kunkun 的本地日志和崩溃报告存放在哪里、崩溃后如何查看，以及如何在反馈问题时附上诊断包。
Kunkun 会把运行过程记录到本机的本地日志文件里，并且会记录自身的崩溃——包括那些原本不留任何痕迹的原生崩溃。本页说明这些文件在哪里，以及出问题时怎么用它们。
本地日志和崩溃转储只保存在你的设备上。Kunkun 不会上传到任何地方——反馈问题时由你决定分享什么。
最简单的方式：设置 → 日志
在应用内打开 设置 → 日志，你可以：
- 在文件管理器中打开日志文件夹。
- 按级别和文本搜索、筛选最近的日志。
- 导出诊断包——一个文件，方便附在问题反馈里。
只要还能打开应用，这就是最快的途径。
文件在哪里
日志写入 Kunkun 用户数据目录下的 logs/ 文件夹,按天一个文件,命名为 YYYY-MM-DD.kunkun.jsonl(JSON Lines,每行一条事件)。本地日志默认开启。
| 系统 | 日志文件夹 |
|---|---|
| macOS | ~/Library/Application Support/Kunkun/logs/ |
| Windows | %APPDATA%\Kunkun\logs\ |
| Linux | ~/.config/Kunkun/logs/ |
原生崩溃转储(minidump)写在同一用户数据目录下的另一个崩溃转储文件夹里。你几乎不需要手动去找它——检测到崩溃时,日志会直接给出具体的 minidump 路径(见下)。
崩溃之后：看什么
原生崩溃会在写完之前就杀死进程,所以崩溃本身出现在_下一次_启动的日志里,而不是那个死掉的会话里。重新打开 Kunkun 后,日志会记录上一个会话发生了什么。
在当天日志里搜索这些标记:
# macOS 示例
grep -i "Previous session\|process-gone\|crash-observability" \
~/Library/Application\ Support/Kunkun/logs/$(date +%F).kunkun.jsonl可能看到的内容及含义:
| 日志消息 | 含义 | 详情在哪 |
|---|---|---|
Previous session ended on an uncaught main-process exception | 一个 JavaScript 错误让应用崩了 | 完整堆栈就在该条日志里 |
Previous session terminated abnormally (no JS exception captured) | 原生崩溃、被强杀或断电 | 打开日志条目里的 minidump 路径,或系统崩溃报告 |
render-process-gone | 某个窗口的渲染进程死了 | 条目里的 reason / exitCode |
child-process-gone | 某个辅助进程(utility/GPU)死了 | 条目里的 type / reason |
render-process-gone 和 child-process-gone 是实时记录在同一会话里的——这两类不需要重启就能看到。
在 macOS 上,原生崩溃也会被系统记录在 ~/Library/Logs/DiagnosticReports/(文件名类似 Electron-*.ips)。那是原生崩溃堆栈最底层的可靠来源。
反馈问题
最有用的附件是诊断包:打开 设置 → 日志 → 导出诊断包,它会把最近的日志(和崩溃标记)打包成一个文件。反馈时附上它,比逐行复制更好。
给扩展开发者
在开发时从终端启动桌面应用,崩溃和故障信息也会实时打印到那个终端(以 [Crash] 为前缀),不必等下次启动或翻日志文件。worker-view 和 headless 插件还可以脱离完整应用单独测试——参见插件测试指南里的 headless 冒烟测试工具。