简介Chatlog 是一款面向开发者与数据分析师的微信本地聊天记录结构化工具基于 Go 语言实现跨平台支持解决微信原始数据库难以检索、解密与集成的问题。它无需 root 或越狱即可自动发现并解密 Windows/macOS 上多账号的微信 3.x 与 4.0 客户端数据提供 Terminal UI 交互、CLI 脚本调用及 HTTP API/SSE 双栈服务特别适配 AI 助手上下文接入与自动化分析场景。资源包共 139 个文件含 123 个核心 Go 源码覆盖数据源解析、媒体解码、API 路由、SSE 推送等模块、4 份 Markdown 文档含部署说明与协议规范、3 个 Protobuf 定义文件支撑 MCP 协议对接以及 YAML 配置、Makefile 构建脚本等总大小仅 213KB轻量易部署。已有 913 人学习下载读者可直接运行调试完整解密流程复用 CLI 工具链进行批量查询或基于 REST/SSE 接口快速对接 LLM 应用掌握本地隐私数据合规调用的关键实践。1. Chatlog 项目拆解为什么一条聊天记录查询工具能成为“神器”先说结论Chatlog 就是用 Go 语言写的一个本地微信聊天记录读取、检索、导出工具并且在上层接入了大模型接口让你能对聊天记录做摘要、关键词提取甚至语义问答。很多人一听到“微信聊天记录查询”第一反应是“这玩意儿是不是又是那种灰产工具”说实话我当时也这么想过。但深入看这个项目的源码结构和设计思路之后你会发现它其实是一个很典型的“本地数据解析 AI 能力集成”的样板工程值得好好拆一拆。先解释一下它到底解决了什么问题。微信电脑版会把聊天记录存在本地 SQLite 数据库文件里但普通用户根本不会去看那个文件——二进制结构、字段不透明、消息类型复杂。就算你把数据库文件拷贝出来没有工具也只能干瞪眼。Chatlog 做的事情就是把这一层窗户纸捅破它能扫描本地微信数据目录定位数据库文件读取出联系人、群聊、单聊消息然后暴露成命令行或 HTTP 接口供查询。最重要的是它在查询结果之上接了一层大模型分析可以把几百条聊天记录自动压缩成几条摘要或者按话题聚类这就把“查询”升级成了“理解”。适合谁看如果你是 Go 开发者可以把它当做一个“本地文件解析 结构化查询 AI 接口集成”的三段式范本来学习如果你只是对微信聊天记录备份和分析感兴趣也可以把它当成一个可以直接跑起来的工具来用。不过有一点必须提前说清楚这个项目只建议在你自己的设备上、对你自己产生的聊天数据做分析不要拿去碰别人的数据也不要用于任何未经授权的场景。隐私和数据安全问题不是玩笑。再来说说为什么会用 Go 语言。我最早接触这类工具的时候市面上类似的仓库大多用 Python 写毕竟 Python 搞数据处理顺手。但 Go 有一个天然优势交叉编译。你可以在 Linux 上直接编出 Windows 可执行文件扔到对方电脑上就能跑不带任何运行时依赖。对于这种“读取本机数据”的场景静态编译的单一二进制文件极具吸引力。另外一个点是并发处理解析数据库、批量拉取消息、分批请求 AI 接口这些操作用 Go 的 goroutine 写起来非常自然调度器帮你搞定大部分并发问题不需要像 Python 那样折腾 asyncio 或者多线程加锁。而且 Go 的 database/sql 生态很成熟SQLite 驱动选择多配合纯 SQL 查询完全够用。2. 核心难点解析微信聊天记录的结构、存储和读取原理2.1 微信本地数据库到底长什么样既然要做聊天记录查询第一步就得搞清楚微信的数据库存在哪、结构是什么。以微信 PC 版Windows 生态下最常见为例数据目录通常在%APPDATA%\Tencent\WeChat或%APPDATA%\Tencent\WeChat Files下具体路径取决于微信版本。新版微信的数据结构比较清晰每个微信号对应一个独立目录里面存放各类数据库文件最核心的是Msg开头的几个文件。Chatlog 在源码里做的主要事情就是先扫描这些目录找到对应微信号的数据库文件然后尝试用 SQLite 协议去连接。需要提醒的是微信的部分数据库可能加了 SQLCipher 加密或者处于 WAL 模式下有额外的.wal文件。Chatlog 这类工具通常以“只读模式”打开数据库避免对原始数据造成污染。我在自己机器上实测的时候直接打开旧版本微信的MSG.db是可以读出数据的但如果是较新版本的微信由于加密策略调整不一定能直接读出明文。这一步的兼容性处理是项目里最有价值也最麻烦的地方。2.2 核心表结构和消息字段说明拿到数据库之后重点关注的表主要是msg表和contact表。msg表的字段通常包括localId本地自增 ID仅本地有效Talker会话对象标识单聊时是对方微信号群聊时是群聊 IDType消息类型1 代表文本3 代表图片34 代表语音43 代表视频49 代表文件/链接等SubType子类型IsSender是否为当前登录账号发送0 接收1 发送CreateTime消息发送时间Unix 时间戳Content消息内容文本消息直接是文字非文本消息一般是 XML 结构或文件路径描述contact表则维护了联系人和群聊的基础信息字段一般包含UserName、NickName、Remark等。查询时可以按消息里的Talker去关联contact表把展示名解析出来。要注意的是微信的数据结构是闭源反向分析出来的不同版本之间字段可能有细微差别。比如某些版本里消息表叫msg另一些版本叫MSGTABLE有的版本有ChatInfo表有的没有。Chatlog 的源码里一般会写一个“表结构探测”逻辑——先查询sqlite_master拿到实际建表语句再动态决定字段映射。这个设计思路非常值得借鉴比硬编码字段名要健壮得多。2.3 Go 语言读取 SQLite 的标准姿势读取这块用的是 Go 标准库database/sqlgithub.com/mattn/go-sqlite3驱动。下面这段代码基本还原了 Chatlog 项目的核心读取逻辑我用它打开只读模式连接数据库然后按会话拉取消息package main import ( database/sql fmt log _ github.com/mattn/go-sqlite3 ) type Message struct { LocalID int64 Talker string Type int IsSender int CreateTime int64 Content string } func openMsgDB(dbPath string) (*sql.DB, error) { // 只读模式打开避免微信正在运行时产生写锁冲突 dsn : fmt.Sprintf(file:%s?modero_pragmabusy_timeout(5000), dbPath) db, err : sql.Open(sqlite3, dsn) if err ! nil { return nil, err } if err : db.Ping(); err ! nil { return nil, err } return db, nil } func queryMessagesByTalker(db *sql.DB, talker string) ([]Message, error) { rows, err : db.Query( SELECT localId, Talker, Type, IsSender, CreateTime, Content FROM msg WHERE Talker ? ORDER BY CreateTime ASC , talker) if err ! nil { return nil, err } defer rows.Close() var messages []Message for rows.Next() { var m Message if err : rows.Scan(m.LocalID, m.Talker, m.Type, m.IsSender, m.CreateTime, m.Content); err ! nil { return nil, err } messages append(messages, m) } return messages, rows.Err() }几个细节值得展开。第一DSN 里加了modero和busy_timeout(5000)这两样是血泪教训换来的。如果你的微信还在后台运行直接用默认方式打开数据库会触发文件锁定错误加了busy_timeout能让 SQLite 在等待锁时自动重试而不是立刻报错。第二defer rows.Close()是必须的查询完之后不关闭 rows 会导致连接无法释放长时间跑下来连接池会被耗尽。第三SQL 语句里把Type、IsSender都拉出来是因为后面做消息展示和 AI 分析时需要区分文本消息、文件消息、图片消息也要区分“自己发的”和“对方发的”——AI 摘要要是把两边混在一起生成的结果会非常奇怪。2.4 跨平台路径定位和兼容性处理路径定位是很多初学者忽视的点。Windows 下微信数据目录要遍历注册表、%APPDATA%环境变量、已知安装目录等多个来源。Chatlog 项目中一般会封装一个Locator接口针对不同平台返回各自的候选路径列表。比如在 Windows 下候选路径包括C:\Users\%USERNAME%\Documents\WeChat Files、C:\Users\%USERNAME%\AppData\Roaming\Tencent\WeChat等macOS 下则是~/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/。这个列表可以随着使用场景不断补充反正核心思路就是“多枚举几个候选路径逐个探测是否存在数据库文件”。在读取之前最好先做一次目录校验确认文件存在且非空。我实际使用中遇到过一个情况微信版本升级之后数据库文件被迁移到了新的目录老目录只剩下一个空的占位文件。如果不做校验直接打开会得到一个看似正常的 SQLite 连接但查任何表都返回空。最终排查方式是在代码里加一个“健康检查”——读sqlite_master表看msg表是否存在不存在就直接跳过这个候选路径。3. AI 集成原理从聊天记录原始文本到结构化智能摘要3.1 AI 集成的定位和接口选型如果光是把聊天记录读出来那这个项目充其量就是个 SQLite 查询工具谈不上“神器”。Chatlog 真正的亮点在 AI 集成。所谓 AI 集成说白了就是调用大模型接口把从数据库里读出来的原始聊天内容拼成 Prompt让大模型返回摘要、关键词、情绪分析或问答结果。接口选型上Chatlog 走的是“兼容 OpenAI 格式”的路子因为国内外的模型服务大多都提供 OpenAI 兼容的/v1/chat/completions接口配一个 BaseURL 就行。源码里通常不会硬编码某一家厂商的 SDK而是直接用 HTTP 构造 JSON 请求把 BaseURL、API Key、模型名都做成可配置项。这样灵活性最高换模型服务商时只改配置不改代码。3.2 构造 Prompt 的工程细节AI 输出的质量取决于两个因素模型能力和 Prompt 质量。在 Chatlog 这种场景下Prompt 的构造有讲究不能把几百条聊天记录一股脑全怼进去要控制 token 数、按时间分组、过滤无用消息。我给一个常见的 Prompt 模板参考你是一个帮助用户总结聊天记录摘要的助手。 以下是某个会话的聊天记录按时间顺序排列。 请提取其中的关键信息生成 1. 一句话概括本次聊天的核心主题 2. 3-5 条关键要点 3. 待办事项如果有 4. 整个对话的情绪倾向正面/中性/负面 聊天记录开始 [消息1] [消息2] ... 聊天记录结束。这个模板有效的地方在于它明确要求输出结构化结果而不是让模型“自由发挥”。你如果不限定格式模型很容易给你输出一大段散文式的总结不利于后续程序解析。Chatlog 里一般会约定返回 JSON 格式比如{ summary: 讨论了项目上线计划和风险, key_points: [确定上线时间, 分工完成, 待测试], action_items: [周一前提交测试报告], sentiment: 正面 }拿到 JSON 之后程序就可以把它渲染到终端或者网页上用户看到的就不是一堆聊天记录而是一个信息密度极高的分析报告。3.3 在 Go 里调用大模型 API 的实现思路Chatlog 源码中实现 AI 调用时核心代码大致长这样package main import ( bytes encoding/json fmt io net/http time ) type ChatMessage struct { Role string json:role Content string json:content } type ChatRequest struct { Model string json:model Messages []ChatMessage json:messages } type ChatResponse struct { Choices []struct { Message ChatMessage json:message } json:choices } func callLLM(apiKey, baseURL, model string, messages []ChatMessage) (string, error) { if baseURL { baseURL https://api.openai.com/v1 } url : fmt.Sprintf(%s/chat/completions, baseURL) payload : ChatRequest{ Model: model, Messages: messages, } bodyBytes, _ : json.Marshal(payload) req, err : http.NewRequest(POST, url, bytes.NewReader(bodyBytes)) if err ! nil { return , err } req.Header.Set(Content-Type, application/json) req.Header.Set(Authorization, Bearer apiKey) client : http.Client{Timeout: 60 * time.Second} resp, err : client.Do(req) if err ! nil { return , err } defer resp.Body.Close() if resp.StatusCode ! http.StatusOK { respBody, _ : io.ReadAll(resp.Body) return , fmt.Errorf(LLM API error: %d, %s, resp.StatusCode, string(respBody)) } var result ChatResponse if err : json.NewDecoder(resp.Body).Decode(result); err ! nil { return , err } if len(result.Choices) 0 { return , fmt.Errorf(LLM API returned empty choices) } return result.Choices[0].Message.Content, nil }这里有两个容易被忽略的点。第一超时时间设成了 60 秒因为大模型接口在高峰期响应可能比较慢设置太短会导致大量超时失败设置太长又会让用户等得焦虑。第二错误处理里把 HTTP 状态码和响应体原样返回这在调试时非常有价值——不同模型服务商返回的错误格式差异很大只有把原始响应打出来才能快速定位是认证失败、余额不足还是 Prompt 内容违规。3.4 批量消息的 Token 控制策略一次聊天的记录可能几百条甚至上千条而大模型接口有 token 上限。Chatlog 的处理方式一般有三种截断、分段、抽样。截断就是把原始消息截取前 N 条分段是把消息按时间切片每段单独送进模型最后再做一次汇总抽样通常用于超长群聊按固定步长取一部分消息。实际项目中“分段汇合”的效果最好但代价是请求次数变多、耗时变长。我建议的思路是如果是少于 100 条消息的会话直接一次性送进去100 到 500 条之间按时间切成 2-3 段分别摘要然后把摘要拼起来再请求一次做汇总超过 500 条则先做关键词过滤挑出包含“收到”“好的”“明天”“项目”“合同”这类关键信息的消息再做摘要。这个方案的缺点是逻辑稍复杂但能明显提升分析质量同时避免超出上下文窗口的报错。4. 从源码编译到本地跑起来完整实操记录4.1 环境准备和依赖安装Chatlog 是 Go 项目所以第一步是装 Go 工具链。我平时用的是 Go 1.21 及以上版本主要因为它对泛型和多模块工作区的支持更成熟。安装好之后把项目克隆到本地进入项目目录执行go mod tidy这步会拉取所有依赖包括go-sqlite3。如果你在 Linux 或 macOS 上编译需要确保系统里有gcc因为go-sqlite3底层依赖 CGO需要调用 C 编译器。Windows 上交叉编译到 Linux 时需要设置CGO_ENABLED0 GOOSlinux GOARCHamd64 go build -o chatlog不过要提醒的是go-sqlite3这个驱动在CGO_ENABLED0的情况下没法用因为它本质上是 C 代码的绑定。如果你真的需要静态编译且不依赖 CGO那得换用纯 Go 实现的 SQLite 驱动比如modernc.org/sqlite。Chatlog 项目如果贴的是go-sqlite3就老老实实在目标平台上编译不要折腾交叉编译省得绕弯路。4.2 数据库发现和连接初始化项目启动时首先会调用前面提到的目录定位逻辑扫描出所有候选数据库文件。实际运行日志大概是这样[INFO] 扫描微信数据目录... [INFO] 发现候选数据库: /home/user/Documents/WeChat Files/wxid_xxx/msg/msg.db [INFO] 数据库健康检查通过msg 表存在 [INFO] 共加载 3 个联系人分组从源码层面看这部分的代码逻辑是把“路径发现”和“数据库连接”解耦。DiscoverDatabasePaths()返回一个字符串切片每个路径作为一个CandidateDB后续连接循环处理。这样做的好处是便于扩展——以后如果想要支持手机备份文件的解析只需要往路径发现函数里多加一个来源即可连接和查询逻辑完全不用改。4.3 查询接口和终端展示Chatlog 支持命令行交互也支持起一个本地 HTTP 服务。命令行模式下常用操作是# 列出最近 20 个活跃会话 chatlog sessions --limit 20 # 查询某个会话最近消息 chatlog messages --talker wxid_xxx --limit 50 # 对某个会话生成 AI 摘要 chatlog summary --talker wxid_xxx --days 7HTTP 服务模式则更灵活可以返回 JSON 给前端页面。我个人更推荐 HTTP 模式因为它的输出更结构化方便调试也方便接一些自定义 UI。4.4 AI 摘要功能的完整配置流程假设你用的是 OpenAI 兼容接口配置项可以通过环境变量或配置文件指定。Chatlog 项目里一般会提供一个config.yaml示例database: scan_paths: - C:/Users/xxx/Documents/WeChat Files llm: base_url: https://api.your-provider.com/v1 api_key: sk-xxxx model: qwen-plus max_messages_per_request: 200 temperature: 0.3temperature设置为 0.3 是个经验值。摘要任务偏事实提取不需要太多创意temperature 越低输出越稳定、越不容易跑偏。如果你把这个值设成 0.9模型会很“飘”输出的摘要里经常带一些原文里没有的推测内容这在聊天记录分析场景下是致命的。配置好之后调用摘要命令chatlog summary --talker group_xxx --days 3 --format json底层会读取对应时间范围的消息按上文提到的策略分段总结最后输出结构化 JSON。实测下来一份 300 条消息的群聊记录分段两轮请求总耗时大约 10-15 秒取决于模型服务商的响应速度。5. 常见问题与排查技巧实录5.1 SQLite 数据库文件被占用或锁定这是最经常碰到的问题。微信正在运行的时候数据库文件会被进程持有。加只读模式和 busy_timeout 能缓解大部分情况但如果真的发生锁冲突错误信息通常长这样unable to open database file database is locked我的排查建议是先确认有没有别的进程占用数据库文件Windows 可以用handle.exeLinux 可以用lsof然后确认程序是否以只读方式打开。如果确认是微信自身占用最稳妥的办法是引导用户先退出微信或者做一次数据库文件的复制副本再对副本做分析。Chatlog 在实际使用中我更推荐把数据库复制到临时目录再解析避免对源文件产生任何影响。5.2 消息时间戳显示异常或乱码微信消息表里的CreateTime是 Unix 时间戳单位是秒。Go 里面用time.Unix(ts, 0)转换即可但要注意时区问题。默认情况下time.Unix返回的是本地时区时间如果你在服务器上运行而服务器设置的时区是 UTC那显示的时间会比北京时间慢 8 小时。处理方式是把 Location 固定设置为time.Local或者显式指定Asia/Shanghailoc, _ : time.LoadLocation(Asia/Shanghai) displayTime : time.Unix(m.CreateTime, 0).In(loc)乱码问题则多半出在编码上。有些版本的微信消息内容存的是 UTF-8但部分历史消息是 GBK 编码。处理技巧是先按 UTF-8 解析如果发现乱码特征解析后包含大量\uFFFD或不可见字符则尝试转码为 GBK。不过大多数情况下新版微信的消息内容都是 UTF-8不需要额外处理。5.3 AI 接口调用报错和超时调用大模型 API 报错的原因千奇百怪最常见的是这几种API Key 无效、余额不足、请求内容触发了内容审核、模型不存在、请求体格式错误。Chatlog 源码在错误处理上一定要把 HTTP 响应体打印出来否则你根本没法判断是哪种错误。我见过一些人图省事只判断err ! nil出了问题完全没法排查最后逐行加日志才定位到是模型名写错了。超时方面如果聊天记录消息数量巨大单次请求超过 60 秒很正常。建议的策略是客户端把超时时间放大到 120 秒同时用并发控制限制同时最多跑 3 个摘要任务避免把模型服务的并发配额打满。我实测过用 3 并发处理 30 个会话总耗时大约 5 分钟效果可以接受。5.4 隐私合规和数据安全必备提醒这个部分必须单独讲。Chatlog 这类工具天然涉及个人隐私数据任何人都应该把“最小必要”原则刻在脑子里。你自己的代码里至少要做到三件事不要让程序把聊天记录自动上传到任何非用户指定的服务器API Key 不要硬编码在源码里优先从环境变量或本地配置文件读取数据展示时可以做脱敏处理比如隐藏微信号中间几位我也建议在项目 README 里明确写清楚“本项目仅用于技术学习、本机个人数据分析请勿用于非法用途”。这种声明不光是法律层面的自我保护也是在帮助这个项目能长期健康地存在下去。另外一个容易被忽略的细节AI 摘要功能会把聊天内容发送到模型服务商那里。这本身就是一次数据出境或第三方数据处理行为。如果你处理的是工作相关的聊天记录提前确认公司数据合规政策如果是别人的聊天记录无论如何都要先获得授权。技术是中性的但使用技术的人要有边界感。5.5 功能扩展方向最后说点实用的扩展思路。Chatlog 当前版本能做查询和 AI 摘要但你完全可以顺着这个架构往下加功能。比如做一个“年度聊天报告”按月份统计最常聊天的联系人、最活跃的群聊、消息量趋势把 AI 摘要进一步可视化比如接入向量数据库把聊天记录切片之后做 Embedding实现语义搜索——输入“我上次跟他说了什么时间交文档”直接返回对应的原始消息再比如做定时任务每周自动对重要群聊生成周报通过 Webhook 推送到自己的笔记系统。整体技术架构在 Chatlog 里已经是现成的加功能基本上就是往管道里塞新模块的事情不会伤筋动骨。我自己实际扩展过一个版本把消息导出的 JSON 格式对齐了一些主流笔记软件的导入格式用完感觉这类工具的想象空间其实挺大的。本文还有配套的精品资源点击获取 用Go语言解析微信聊天记录并接入大模型：Chatlog项目全拆解
简介Chatlog 是一款面向开发者与数据分析师的微信本地聊天记录结构化工具基于 Go 语言实现跨平台支持解决微信原始数据库难以检索、解密与集成的问题。它无需 root 或越狱即可自动发现并解密 Windows/macOS 上多账号的微信 3.x 与 4.0 客户端数据提供 Terminal UI 交互、CLI 脚本调用及 HTTP API/SSE 双栈服务特别适配 AI 助手上下文接入与自动化分析场景。资源包共 139 个文件含 123 个核心 Go 源码覆盖数据源解析、媒体解码、API 路由、SSE 推送等模块、4 份 Markdown 文档含部署说明与协议规范、3 个 Protobuf 定义文件支撑 MCP 协议对接以及 YAML 配置、Makefile 构建脚本等总大小仅 213KB轻量易部署。已有 913 人学习下载读者可直接运行调试完整解密流程复用 CLI 工具链进行批量查询或基于 REST/SSE 接口快速对接 LLM 应用掌握本地隐私数据合规调用的关键实践。1. Chatlog 项目拆解为什么一条聊天记录查询工具能成为“神器”先说结论Chatlog 就是用 Go 语言写的一个本地微信聊天记录读取、检索、导出工具并且在上层接入了大模型接口让你能对聊天记录做摘要、关键词提取甚至语义问答。很多人一听到“微信聊天记录查询”第一反应是“这玩意儿是不是又是那种灰产工具”说实话我当时也这么想过。但深入看这个项目的源码结构和设计思路之后你会发现它其实是一个很典型的“本地数据解析 AI 能力集成”的样板工程值得好好拆一拆。先解释一下它到底解决了什么问题。微信电脑版会把聊天记录存在本地 SQLite 数据库文件里但普通用户根本不会去看那个文件——二进制结构、字段不透明、消息类型复杂。就算你把数据库文件拷贝出来没有工具也只能干瞪眼。Chatlog 做的事情就是把这一层窗户纸捅破它能扫描本地微信数据目录定位数据库文件读取出联系人、群聊、单聊消息然后暴露成命令行或 HTTP 接口供查询。最重要的是它在查询结果之上接了一层大模型分析可以把几百条聊天记录自动压缩成几条摘要或者按话题聚类这就把“查询”升级成了“理解”。适合谁看如果你是 Go 开发者可以把它当做一个“本地文件解析 结构化查询 AI 接口集成”的三段式范本来学习如果你只是对微信聊天记录备份和分析感兴趣也可以把它当成一个可以直接跑起来的工具来用。不过有一点必须提前说清楚这个项目只建议在你自己的设备上、对你自己产生的聊天数据做分析不要拿去碰别人的数据也不要用于任何未经授权的场景。隐私和数据安全问题不是玩笑。再来说说为什么会用 Go 语言。我最早接触这类工具的时候市面上类似的仓库大多用 Python 写毕竟 Python 搞数据处理顺手。但 Go 有一个天然优势交叉编译。你可以在 Linux 上直接编出 Windows 可执行文件扔到对方电脑上就能跑不带任何运行时依赖。对于这种“读取本机数据”的场景静态编译的单一二进制文件极具吸引力。另外一个点是并发处理解析数据库、批量拉取消息、分批请求 AI 接口这些操作用 Go 的 goroutine 写起来非常自然调度器帮你搞定大部分并发问题不需要像 Python 那样折腾 asyncio 或者多线程加锁。而且 Go 的 database/sql 生态很成熟SQLite 驱动选择多配合纯 SQL 查询完全够用。2. 核心难点解析微信聊天记录的结构、存储和读取原理2.1 微信本地数据库到底长什么样既然要做聊天记录查询第一步就得搞清楚微信的数据库存在哪、结构是什么。以微信 PC 版Windows 生态下最常见为例数据目录通常在%APPDATA%\Tencent\WeChat或%APPDATA%\Tencent\WeChat Files下具体路径取决于微信版本。新版微信的数据结构比较清晰每个微信号对应一个独立目录里面存放各类数据库文件最核心的是Msg开头的几个文件。Chatlog 在源码里做的主要事情就是先扫描这些目录找到对应微信号的数据库文件然后尝试用 SQLite 协议去连接。需要提醒的是微信的部分数据库可能加了 SQLCipher 加密或者处于 WAL 模式下有额外的.wal文件。Chatlog 这类工具通常以“只读模式”打开数据库避免对原始数据造成污染。我在自己机器上实测的时候直接打开旧版本微信的MSG.db是可以读出数据的但如果是较新版本的微信由于加密策略调整不一定能直接读出明文。这一步的兼容性处理是项目里最有价值也最麻烦的地方。2.2 核心表结构和消息字段说明拿到数据库之后重点关注的表主要是msg表和contact表。msg表的字段通常包括localId本地自增 ID仅本地有效Talker会话对象标识单聊时是对方微信号群聊时是群聊 IDType消息类型1 代表文本3 代表图片34 代表语音43 代表视频49 代表文件/链接等SubType子类型IsSender是否为当前登录账号发送0 接收1 发送CreateTime消息发送时间Unix 时间戳Content消息内容文本消息直接是文字非文本消息一般是 XML 结构或文件路径描述contact表则维护了联系人和群聊的基础信息字段一般包含UserName、NickName、Remark等。查询时可以按消息里的Talker去关联contact表把展示名解析出来。要注意的是微信的数据结构是闭源反向分析出来的不同版本之间字段可能有细微差别。比如某些版本里消息表叫msg另一些版本叫MSGTABLE有的版本有ChatInfo表有的没有。Chatlog 的源码里一般会写一个“表结构探测”逻辑——先查询sqlite_master拿到实际建表语句再动态决定字段映射。这个设计思路非常值得借鉴比硬编码字段名要健壮得多。2.3 Go 语言读取 SQLite 的标准姿势读取这块用的是 Go 标准库database/sqlgithub.com/mattn/go-sqlite3驱动。下面这段代码基本还原了 Chatlog 项目的核心读取逻辑我用它打开只读模式连接数据库然后按会话拉取消息package main import ( database/sql fmt log _ github.com/mattn/go-sqlite3 ) type Message struct { LocalID int64 Talker string Type int IsSender int CreateTime int64 Content string } func openMsgDB(dbPath string) (*sql.DB, error) { // 只读模式打开避免微信正在运行时产生写锁冲突 dsn : fmt.Sprintf(file:%s?modero_pragmabusy_timeout(5000), dbPath) db, err : sql.Open(sqlite3, dsn) if err ! nil { return nil, err } if err : db.Ping(); err ! nil { return nil, err } return db, nil } func queryMessagesByTalker(db *sql.DB, talker string) ([]Message, error) { rows, err : db.Query( SELECT localId, Talker, Type, IsSender, CreateTime, Content FROM msg WHERE Talker ? ORDER BY CreateTime ASC , talker) if err ! nil { return nil, err } defer rows.Close() var messages []Message for rows.Next() { var m Message if err : rows.Scan(m.LocalID, m.Talker, m.Type, m.IsSender, m.CreateTime, m.Content); err ! nil { return nil, err } messages append(messages, m) } return messages, rows.Err() }几个细节值得展开。第一DSN 里加了modero和busy_timeout(5000)这两样是血泪教训换来的。如果你的微信还在后台运行直接用默认方式打开数据库会触发文件锁定错误加了busy_timeout能让 SQLite 在等待锁时自动重试而不是立刻报错。第二defer rows.Close()是必须的查询完之后不关闭 rows 会导致连接无法释放长时间跑下来连接池会被耗尽。第三SQL 语句里把Type、IsSender都拉出来是因为后面做消息展示和 AI 分析时需要区分文本消息、文件消息、图片消息也要区分“自己发的”和“对方发的”——AI 摘要要是把两边混在一起生成的结果会非常奇怪。2.4 跨平台路径定位和兼容性处理路径定位是很多初学者忽视的点。Windows 下微信数据目录要遍历注册表、%APPDATA%环境变量、已知安装目录等多个来源。Chatlog 项目中一般会封装一个Locator接口针对不同平台返回各自的候选路径列表。比如在 Windows 下候选路径包括C:\Users\%USERNAME%\Documents\WeChat Files、C:\Users\%USERNAME%\AppData\Roaming\Tencent\WeChat等macOS 下则是~/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/。这个列表可以随着使用场景不断补充反正核心思路就是“多枚举几个候选路径逐个探测是否存在数据库文件”。在读取之前最好先做一次目录校验确认文件存在且非空。我实际使用中遇到过一个情况微信版本升级之后数据库文件被迁移到了新的目录老目录只剩下一个空的占位文件。如果不做校验直接打开会得到一个看似正常的 SQLite 连接但查任何表都返回空。最终排查方式是在代码里加一个“健康检查”——读sqlite_master表看msg表是否存在不存在就直接跳过这个候选路径。3. AI 集成原理从聊天记录原始文本到结构化智能摘要3.1 AI 集成的定位和接口选型如果光是把聊天记录读出来那这个项目充其量就是个 SQLite 查询工具谈不上“神器”。Chatlog 真正的亮点在 AI 集成。所谓 AI 集成说白了就是调用大模型接口把从数据库里读出来的原始聊天内容拼成 Prompt让大模型返回摘要、关键词、情绪分析或问答结果。接口选型上Chatlog 走的是“兼容 OpenAI 格式”的路子因为国内外的模型服务大多都提供 OpenAI 兼容的/v1/chat/completions接口配一个 BaseURL 就行。源码里通常不会硬编码某一家厂商的 SDK而是直接用 HTTP 构造 JSON 请求把 BaseURL、API Key、模型名都做成可配置项。这样灵活性最高换模型服务商时只改配置不改代码。3.2 构造 Prompt 的工程细节AI 输出的质量取决于两个因素模型能力和 Prompt 质量。在 Chatlog 这种场景下Prompt 的构造有讲究不能把几百条聊天记录一股脑全怼进去要控制 token 数、按时间分组、过滤无用消息。我给一个常见的 Prompt 模板参考你是一个帮助用户总结聊天记录摘要的助手。 以下是某个会话的聊天记录按时间顺序排列。 请提取其中的关键信息生成 1. 一句话概括本次聊天的核心主题 2. 3-5 条关键要点 3. 待办事项如果有 4. 整个对话的情绪倾向正面/中性/负面 聊天记录开始 [消息1] [消息2] ... 聊天记录结束。这个模板有效的地方在于它明确要求输出结构化结果而不是让模型“自由发挥”。你如果不限定格式模型很容易给你输出一大段散文式的总结不利于后续程序解析。Chatlog 里一般会约定返回 JSON 格式比如{ summary: 讨论了项目上线计划和风险, key_points: [确定上线时间, 分工完成, 待测试], action_items: [周一前提交测试报告], sentiment: 正面 }拿到 JSON 之后程序就可以把它渲染到终端或者网页上用户看到的就不是一堆聊天记录而是一个信息密度极高的分析报告。3.3 在 Go 里调用大模型 API 的实现思路Chatlog 源码中实现 AI 调用时核心代码大致长这样package main import ( bytes encoding/json fmt io net/http time ) type ChatMessage struct { Role string json:role Content string json:content } type ChatRequest struct { Model string json:model Messages []ChatMessage json:messages } type ChatResponse struct { Choices []struct { Message ChatMessage json:message } json:choices } func callLLM(apiKey, baseURL, model string, messages []ChatMessage) (string, error) { if baseURL { baseURL https://api.openai.com/v1 } url : fmt.Sprintf(%s/chat/completions, baseURL) payload : ChatRequest{ Model: model, Messages: messages, } bodyBytes, _ : json.Marshal(payload) req, err : http.NewRequest(POST, url, bytes.NewReader(bodyBytes)) if err ! nil { return , err } req.Header.Set(Content-Type, application/json) req.Header.Set(Authorization, Bearer apiKey) client : http.Client{Timeout: 60 * time.Second} resp, err : client.Do(req) if err ! nil { return , err } defer resp.Body.Close() if resp.StatusCode ! http.StatusOK { respBody, _ : io.ReadAll(resp.Body) return , fmt.Errorf(LLM API error: %d, %s, resp.StatusCode, string(respBody)) } var result ChatResponse if err : json.NewDecoder(resp.Body).Decode(result); err ! nil { return , err } if len(result.Choices) 0 { return , fmt.Errorf(LLM API returned empty choices) } return result.Choices[0].Message.Content, nil }这里有两个容易被忽略的点。第一超时时间设成了 60 秒因为大模型接口在高峰期响应可能比较慢设置太短会导致大量超时失败设置太长又会让用户等得焦虑。第二错误处理里把 HTTP 状态码和响应体原样返回这在调试时非常有价值——不同模型服务商返回的错误格式差异很大只有把原始响应打出来才能快速定位是认证失败、余额不足还是 Prompt 内容违规。3.4 批量消息的 Token 控制策略一次聊天的记录可能几百条甚至上千条而大模型接口有 token 上限。Chatlog 的处理方式一般有三种截断、分段、抽样。截断就是把原始消息截取前 N 条分段是把消息按时间切片每段单独送进模型最后再做一次汇总抽样通常用于超长群聊按固定步长取一部分消息。实际项目中“分段汇合”的效果最好但代价是请求次数变多、耗时变长。我建议的思路是如果是少于 100 条消息的会话直接一次性送进去100 到 500 条之间按时间切成 2-3 段分别摘要然后把摘要拼起来再请求一次做汇总超过 500 条则先做关键词过滤挑出包含“收到”“好的”“明天”“项目”“合同”这类关键信息的消息再做摘要。这个方案的缺点是逻辑稍复杂但能明显提升分析质量同时避免超出上下文窗口的报错。4. 从源码编译到本地跑起来完整实操记录4.1 环境准备和依赖安装Chatlog 是 Go 项目所以第一步是装 Go 工具链。我平时用的是 Go 1.21 及以上版本主要因为它对泛型和多模块工作区的支持更成熟。安装好之后把项目克隆到本地进入项目目录执行go mod tidy这步会拉取所有依赖包括go-sqlite3。如果你在 Linux 或 macOS 上编译需要确保系统里有gcc因为go-sqlite3底层依赖 CGO需要调用 C 编译器。Windows 上交叉编译到 Linux 时需要设置CGO_ENABLED0 GOOSlinux GOARCHamd64 go build -o chatlog不过要提醒的是go-sqlite3这个驱动在CGO_ENABLED0的情况下没法用因为它本质上是 C 代码的绑定。如果你真的需要静态编译且不依赖 CGO那得换用纯 Go 实现的 SQLite 驱动比如modernc.org/sqlite。Chatlog 项目如果贴的是go-sqlite3就老老实实在目标平台上编译不要折腾交叉编译省得绕弯路。4.2 数据库发现和连接初始化项目启动时首先会调用前面提到的目录定位逻辑扫描出所有候选数据库文件。实际运行日志大概是这样[INFO] 扫描微信数据目录... [INFO] 发现候选数据库: /home/user/Documents/WeChat Files/wxid_xxx/msg/msg.db [INFO] 数据库健康检查通过msg 表存在 [INFO] 共加载 3 个联系人分组从源码层面看这部分的代码逻辑是把“路径发现”和“数据库连接”解耦。DiscoverDatabasePaths()返回一个字符串切片每个路径作为一个CandidateDB后续连接循环处理。这样做的好处是便于扩展——以后如果想要支持手机备份文件的解析只需要往路径发现函数里多加一个来源即可连接和查询逻辑完全不用改。4.3 查询接口和终端展示Chatlog 支持命令行交互也支持起一个本地 HTTP 服务。命令行模式下常用操作是# 列出最近 20 个活跃会话 chatlog sessions --limit 20 # 查询某个会话最近消息 chatlog messages --talker wxid_xxx --limit 50 # 对某个会话生成 AI 摘要 chatlog summary --talker wxid_xxx --days 7HTTP 服务模式则更灵活可以返回 JSON 给前端页面。我个人更推荐 HTTP 模式因为它的输出更结构化方便调试也方便接一些自定义 UI。4.4 AI 摘要功能的完整配置流程假设你用的是 OpenAI 兼容接口配置项可以通过环境变量或配置文件指定。Chatlog 项目里一般会提供一个config.yaml示例database: scan_paths: - C:/Users/xxx/Documents/WeChat Files llm: base_url: https://api.your-provider.com/v1 api_key: sk-xxxx model: qwen-plus max_messages_per_request: 200 temperature: 0.3temperature设置为 0.3 是个经验值。摘要任务偏事实提取不需要太多创意temperature 越低输出越稳定、越不容易跑偏。如果你把这个值设成 0.9模型会很“飘”输出的摘要里经常带一些原文里没有的推测内容这在聊天记录分析场景下是致命的。配置好之后调用摘要命令chatlog summary --talker group_xxx --days 3 --format json底层会读取对应时间范围的消息按上文提到的策略分段总结最后输出结构化 JSON。实测下来一份 300 条消息的群聊记录分段两轮请求总耗时大约 10-15 秒取决于模型服务商的响应速度。5. 常见问题与排查技巧实录5.1 SQLite 数据库文件被占用或锁定这是最经常碰到的问题。微信正在运行的时候数据库文件会被进程持有。加只读模式和 busy_timeout 能缓解大部分情况但如果真的发生锁冲突错误信息通常长这样unable to open database file database is locked我的排查建议是先确认有没有别的进程占用数据库文件Windows 可以用handle.exeLinux 可以用lsof然后确认程序是否以只读方式打开。如果确认是微信自身占用最稳妥的办法是引导用户先退出微信或者做一次数据库文件的复制副本再对副本做分析。Chatlog 在实际使用中我更推荐把数据库复制到临时目录再解析避免对源文件产生任何影响。5.2 消息时间戳显示异常或乱码微信消息表里的CreateTime是 Unix 时间戳单位是秒。Go 里面用time.Unix(ts, 0)转换即可但要注意时区问题。默认情况下time.Unix返回的是本地时区时间如果你在服务器上运行而服务器设置的时区是 UTC那显示的时间会比北京时间慢 8 小时。处理方式是把 Location 固定设置为time.Local或者显式指定Asia/Shanghailoc, _ : time.LoadLocation(Asia/Shanghai) displayTime : time.Unix(m.CreateTime, 0).In(loc)乱码问题则多半出在编码上。有些版本的微信消息内容存的是 UTF-8但部分历史消息是 GBK 编码。处理技巧是先按 UTF-8 解析如果发现乱码特征解析后包含大量\uFFFD或不可见字符则尝试转码为 GBK。不过大多数情况下新版微信的消息内容都是 UTF-8不需要额外处理。5.3 AI 接口调用报错和超时调用大模型 API 报错的原因千奇百怪最常见的是这几种API Key 无效、余额不足、请求内容触发了内容审核、模型不存在、请求体格式错误。Chatlog 源码在错误处理上一定要把 HTTP 响应体打印出来否则你根本没法判断是哪种错误。我见过一些人图省事只判断err ! nil出了问题完全没法排查最后逐行加日志才定位到是模型名写错了。超时方面如果聊天记录消息数量巨大单次请求超过 60 秒很正常。建议的策略是客户端把超时时间放大到 120 秒同时用并发控制限制同时最多跑 3 个摘要任务避免把模型服务的并发配额打满。我实测过用 3 并发处理 30 个会话总耗时大约 5 分钟效果可以接受。5.4 隐私合规和数据安全必备提醒这个部分必须单独讲。Chatlog 这类工具天然涉及个人隐私数据任何人都应该把“最小必要”原则刻在脑子里。你自己的代码里至少要做到三件事不要让程序把聊天记录自动上传到任何非用户指定的服务器API Key 不要硬编码在源码里优先从环境变量或本地配置文件读取数据展示时可以做脱敏处理比如隐藏微信号中间几位我也建议在项目 README 里明确写清楚“本项目仅用于技术学习、本机个人数据分析请勿用于非法用途”。这种声明不光是法律层面的自我保护也是在帮助这个项目能长期健康地存在下去。另外一个容易被忽略的细节AI 摘要功能会把聊天内容发送到模型服务商那里。这本身就是一次数据出境或第三方数据处理行为。如果你处理的是工作相关的聊天记录提前确认公司数据合规政策如果是别人的聊天记录无论如何都要先获得授权。技术是中性的但使用技术的人要有边界感。5.5 功能扩展方向最后说点实用的扩展思路。Chatlog 当前版本能做查询和 AI 摘要但你完全可以顺着这个架构往下加功能。比如做一个“年度聊天报告”按月份统计最常聊天的联系人、最活跃的群聊、消息量趋势把 AI 摘要进一步可视化比如接入向量数据库把聊天记录切片之后做 Embedding实现语义搜索——输入“我上次跟他说了什么时间交文档”直接返回对应的原始消息再比如做定时任务每周自动对重要群聊生成周报通过 Webhook 推送到自己的笔记系统。整体技术架构在 Chatlog 里已经是现成的加功能基本上就是往管道里塞新模块的事情不会伤筋动骨。我自己实际扩展过一个版本把消息导出的 JSON 格式对齐了一些主流笔记软件的导入格式用完感觉这类工具的想象空间其实挺大的。本文还有配套的精品资源点击获取