本文还有配套的精品资源点击获取简介提供两个Python脚本qq_count.py先检测目标QQ号是否存在、是否活跃并初步判断其关联群组数量qq_count_detail.py在登录态有效前提下抓取该QQ号实际加入的所有群聊ID、群名称、成员总数和创建时间等字段结果以结构化JSON格式保存到本地。运行需安装requests、beautifulsoup4、lxml依赖手动获取的登录凭证如Cookie或扫码后提取的session不支持免登录批量查询。配套README.md详细说明环境配置、执行步骤及常见错误排查方法SJT-code目录含协议解析与解密参考代码。所有数据仅存储于本地便于后续导入Excel或数据库做进一步整理分析。使用前请确保操作符合腾讯《QQ软件许可协议》及国家相关法律法规仅限个人账号自查或已获明确授权的数据整理场景。1. 项目概述这不是“爬虫”而是一套账号自查工具链你有没有过这样的经历手头有一批老QQ号想确认哪些还活着、哪些早被弃用或者刚接手一个运营多年的QQ号想快速摸清它到底加了多少群、哪些群还在活跃、哪些群名都改得面目全非了又或者在做家庭数字资产整理时需要把长辈那个“8848”开头的老QQ号里散落的几十个兴趣群、同学群、家族群一次性拉出来归档这时候市面上那些打着“一键导出全部QQ群”的GUI工具要么早已失效要么暗藏风险——弹窗广告、静默上传、甚至偷偷调用远程服务。而这个项目从设计第一天起就锚定在一个非常朴素但关键的定位上本地化、可审计、零外联、强可控的个人账号信息自查工具。它不叫“QQ群爬虫”也不叫“群组采集器”它的名字就是“QQ号群组探测工具”。两个脚本分工明确qq_count.py是你的“探针”负责轻量级打点——输入一个QQ号它不登录、不抓群详情只通过腾讯公开的轻量接口比如群搜索预检、好友关系链反射、历史消息缓存标识等判断该号码是否注册、是否在线过、是否曾加入过群聊、大概关联多少个群注意是“关联数”不是“精确数”这是合规边界的关键设计而qq_count_detail.py才是真正的“显微镜”但它必须在你亲手完成登录验证之后才能启动——它不会自动扫码、不会模拟点击、不会绕过滑块验证它只接收你手动提供的、当前有效的登录态凭证比如浏览器开发者工具里复制的完整Cookie字符串或扫码成功后Network面板中抓到的ptwebqq、skey、qrsig等关键字段组合然后基于这个真实有效的身份向腾讯服务器发起标准的、与官方客户端行为一致的API请求逐页拉取“我的群聊”列表并结构化解析每一条返回数据。关键词里的“QQ群列表”、“Python脚本”、“登录态抓取”其实已经精准概括了它的技术内核和使用范式。它不是黑箱所有逻辑都在源码里它不越界所有请求都带着你本人的真实身份它不持久所有数据只写入你本地硬盘上的JSON文件连一次HTTP POST到第三方服务器都没有。我用这套工具帮朋友整理过三代人的QQ账号遗产也用来审计过自己十年前注册的十几个小号——最深的体会是真正的效率从来不是靠“全自动”而是靠“全透明”和“全可控”。当你清楚知道每一行代码在做什么、每一个请求发给谁、每一个响应来自哪里排查问题才不会抓瞎复现结果才不会玄学更重要的是心里才真正踏实。2. 核心设计思路与方案选型解析2.1 为什么坚持“手动登录态”而不是搞自动扫码或OCR识别这是整个项目设计哲学的基石。很多初学者看到“需要手动获取登录态”第一反应是“太麻烦了能不能自动化”——这恰恰是踩坑的开始。我试过三种主流路径方案A全自动扫码登录基于PILOpenCV识别二维码理论上可行但实测下来腾讯的扫码页面更新极其频繁去年还是纯白底黑码今年加了动态水印、背景噪点、甚至会根据IP触发不同样式。更致命的是扫码成功后的跳转逻辑不统一有时跳回https://qun.qq.com/有时跳到https://user.qzone.qq.com/有时还会弹出二次验证。一套OCR模型很难长期稳定覆盖。我维护过三个月平均每周要修两次图像预处理逻辑投入产出比极低。方案B模拟Web登录填账号密码滑块验证这条路直接被堵死。腾讯的登录页早已全面接入tcaptcha腾讯防水墙其滑块轨迹检测不仅看鼠标移动路径还会采集设备指纹、Canvas渲染特征、WebGL参数、甚至键盘敲击时序。我用Selenium跑过上千次成功率不到7%且每次失败都会触发风控导致IP被临时限制。这不是技术难度问题而是平台方明确的反自动化策略。方案C手动提取有效登录态当前采用方案这才是符合现实约束的最优解。你只需要打开Chrome访问qun.qq.com用手机QQ扫码登录一次然后按F12打开开发者工具切到Application → Cookies把qrsig、ptwebqq、skey、superkey、p_skey这五个核心字段的值完整复制下来粘贴进脚本配置即可。整个过程耗时不超过90秒且一次登录态有效期通常在3~7天取决于账号安全等级。它的优势在于100%可靠你用浏览器能访问的页面脚本就能访问零风控风险所有请求都携带你真实的、由腾讯服务器签发的凭证和你在浏览器里点“我的群聊”按钮发出的请求完全一致可审计性强你可以随时在Network面板里对照脚本发出的每个请求确认URL、Headers、Payload是否与浏览器一致学习成本低不需要懂OCR、不需要研究滑块算法只要会按F12就行。所以“手动”不是妥协而是对平台规则的尊重是对自身操作安全的负责更是对工具长期可用性的投资。2.2 为什么qq_count.py只做“存在性关联数”探测而不直接拉群列表这个问题直指合规红线。我们来拆解一下腾讯官方接口的权限分层接口类型调用条件返回数据粒度是否需登录态合规风险https://qun.qq.com/cgi-bin/qun_mgr/get_group_list必须登录态群ID、群名、成员数、创建时间、群公告摘要是低官方开放接口https://qun.qq.com/cgi-bin/qun_mgr/search_group无需登录态群ID、群名、成员数估算、简介片段否中大量调用易被限流https://r.qun.qq.com/friend/https://qun.qq.com/cgi-bin/qun_mgr/get_friend_list需登录态好友昵称、QQ号、最后上线时间是低https://qun.qq.com/cgi-bin/qun_mgr/get_group_info单群需登录态群公告全文、管理员列表、入群时间是低qq_count.py的设计严格限定在第二行——即无需登录态的群搜索接口。它的工作原理是构造一个模糊搜索词如QQ号本身作为关键词向腾讯群搜索接口发起请求解析返回的JSON中result数组的长度这个长度就是该QQ号“可能关联”的群数量上限。注意这里返回的群列表并非该QQ号实际加入的群而是所有群名、简介中包含该QQ号数字串的群比如群名叫“2023届8848班”简介里写了“联系人123456789”那么搜索“123456789”就会命中这个群。因此它返回的是一个“上界估计值”而非精确值。这种设计有三个好处1.完全规避登录依赖用户无需任何前置操作输入QQ号就能立刻得到反馈2.天然具备容错性即使该QQ号已注销只要历史上有群用过它的数字仍可能被搜到这对“查老号”场景反而更友好3.绝对合规所有请求都是公开、无认证的GET和你在网页端搜索群聊的行为完全一致不存在任何协议违规。而qq_count_detail.py则必须走第一行接口因为它要获取的是你账号“真实加入”的群列表这属于个人隐私数据腾讯绝不会对未登录用户开放。两者的分工本质上是用技术手段在“能做什么”和“该做什么”之间划出了一道清晰的、可验证的边界。2.3 为什么选择requests bs4 lxml而不是Selenium或Playwright这是一个关于“重量级”与“轻量级”的权衡。很多人一上来就想用浏览器自动化觉得“万能”。但在这个场景下它会带来三重负担资源开销大启动一个Chromium实例内存占用动辄500MBCPU持续占用而我们的核心任务只是发几个HTTP请求、解析几段JSON和HTML。用坦克去打蚊子既慢又笨重。稳定性差浏览器版本一升级XPath/CSS Selector就可能失效页面JS加载顺序稍有变化document.readyState complete的判断就可能出错更别说腾讯页面里那些动态插入的script标签经常让page.content()拿到的HTML和Network里看到的原始响应对不上。调试困难当请求失败时你是该去查Selenium的日志查浏览器控制台的JS错误还是查Network面板里的XHR三层抽象叠在一起问题定位路径被拉长了3倍。requests则完全不同。它就是一个纯粹的HTTP客户端你发什么它就发什么你收什么它就收什么。配合bs4BeautifulSoup做HTML解析lxml做底层加速bs4默认的html.parser在处理腾讯那种嵌套极深、标签不规范的HTML时解析速度慢、容错率低而lxml能自动修复缺失的闭合标签且解析速度快3~5倍整套栈就像一把瑞士军刀小巧、锋利、可靠。我做过对比测试对同一个群列表页面含200个群requestslxml解析耗时平均为127ms而SeleniumChrome从启动到拿到page.source平均耗时2.8秒且失败率高达18%主要卡在JS加载超时。对于需要批量处理多个QQ号的场景这个差距就是几分钟和几小时的区别。所以技术选型不是追求“新”而是追求“稳”不是堆砌“酷”而是回归“用”。3. 核心细节解析与实操要点3.1 登录态提取手把手教你从Chrome里“抠”出5个关键字段这是整个流程中最容易卡住的环节也是后续所有操作成败的前提。别担心它比你想的简单但有几个极易忽略的细节我用自己踩过的坑来告诉你第一步确保你是在“干净”的浏览器环境里操作不要用你日常上网的Chrome主窗口新开一个“无痕模式”窗口CtrlShiftN或者干脆用Firefox避免Chrome扩展干扰。为什么因为很多广告拦截插件如uBlock Origin会主动屏蔽腾讯域名下的某些Cookie导致你复制出来的skey是空的或者qrsig被篡改。我第一次失败就是因为忘了关AdGuard。第二步访问正确入口并完成扫码在无痕窗口中直接访问https://qun.qq.com/不是qun.qq.com带www的也不是user.qzone.qq.com。页面右上角会出现“登录”按钮点击后选择“扫码登录”。拿出手机QQ对准二维码扫描务必等待手机端显示“登录成功”并自动关闭网页而不是扫完码就切走。这一步是为了确保所有Cookie都被完整写入。第三步精准定位并复制5个字段按F12打开开发者工具 → 切到Application选项卡 → 左侧边栏展开Cookies → 点击qun.qq.com注意不是www.qun.qq.com也不是qun.qq.com下面的其他子域名。此时右侧会列出所有Cookie。你需要找的是以下5个必须一字不差地复制它们的“Value”列内容字段名典型值示例为什么必须常见陷阱qrsigv2Qx...长度约120字符扫码凭证有效期最短通常2小时用于校验扫码合法性容易和qrsig前面的ptqr混淆注意看Name列ptwebqq6a7b...长度约32字符Web端会话ID是后续所有API请求的“门牌号”值里可能含%符号复制时务必包含不要URL解码skeyod...长度约20字符加密签名密钥用于生成bkn防跨站攻击令牌值开头一定是如果复制出来是空的说明没登录成功superkeye1f2...长度约32字符高权限密钥部分群管理接口必需有些账号没有此字段可留空但qq_count_detail.py会提示p_skeyzYxw...长度约40字符用于生成bkn的另一种密钥优先级低于skey如果skey存在p_skey可选两者都为空则无法运行提示复制时右键点击Value列 → “Copy value”不要双击后手动拖选避免多复制空格或换行符。粘贴到文本编辑器后检查每行末尾是否有看不见的空格有则删掉。第四步格式化为脚本可读的字典qq_count_detail.py期望的输入是一个Python字典形如cookies { qrsig: v2Qx..., ptwebqq: 6a7b..., skey: od..., superkey: e1f2..., p_skey: zYxw... }你可以直接把这个字典粘贴到脚本顶部的COOKIES {...}变量里也可以新建一个config.py文件单独存放然后在脚本里from config import COOKIES。后者更安全避免误提交敏感信息到Git。3.2qq_count.py的探测逻辑与结果解读这个脚本的核心就一个函数check_qq_existence(qq_number)。它的执行流程如下构造搜索URLhttps://qun.qq.com/cgi-bin/qun_mgr/search_group?gcst0end20kw{qq_number}sort0这里kw参数就是你要搜索的QQ号st和end控制分页默认只查前20条sort0表示按相关性排序。发送GET请求并解析响应requests.get(url, timeout10)然后用json.loads()解析返回的JSON。关键字段是result数组。结果判定逻辑- 如果response.status_code ! 200直接报错“网络请求失败请检查网络或腾讯接口是否变更”- 如果json_data.get(result)为空列表[]则判定为“QQ号未找到任何关联群”返回{exists: False, group_count_estimate: 0}- 如果json_data.get(result)非空则统计其长度返回{exists: True, group_count_estimate: len(result)}。这里的关键是理解group_count_estimate的含义。它不是“该QQ号加入了多少群”而是“有多少个群的名称或简介里包含了这个QQ号数字”。例如搜索QQ号123456789返回结果里可能有- 群名“123456789的摄影交流群” → 精确匹配- 群名“2023届123456789班” → 模糊匹配- 简介“管理员QQ123456789有问题请私聊” → 内容匹配。所以如果你搜一个活跃的QQ号返回group_count_estimate: 15这很合理但如果你搜一个从未建过群、也从不在群简介留联系方式的QQ号返回0也完全正常。它不是一个精确计数器而是一个“存在性雷达”。我在测试时发现一个注册于2005年的老QQ号虽然早已不用但因为当年在多个班级群里留过QQ号qq_count.py依然能搜到7个关联群这恰恰证明了它的“考古价值”。3.3qq_count_detail.py的群列表拉取与结构化解析这才是重头戏。它的核心是调用腾讯官方的群列表接口https://qun.qq.com/cgi-bin/qun_mgr/get_group_list。这个接口要求极高必须携带完整的登录态和正确的Headers否则一律返回{ec: -3000, error: invalid request}无效请求。Headers构造是成败关键headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://qun.qq.com/member.html, Origin: https://qun.qq.com, X-Requested-With: XMLHttpRequest }其中Referer和Origin必须严格匹配少一个斜杠都不行。User-Agent建议用最新版Chrome的避免被识别为爬虫。X-Requested-With是告诉服务器“这是一个AJAX请求”腾讯后端会据此放行。请求体data的构造更复杂data { bkn: self._get_bkn(), # 这是核心必须动态计算 gcode: , # 群代码留空表示获取全部 gc: , # 同上 st: page_start, end: page_end, sort: 0 }bkn也叫gtk是腾讯的防跨站攻击令牌计算公式是bkn hash33(skey or p_skey)其中hash33是一个特定的哈希算法不是MD5不是SHA1。SJT-code目录下的hash33.py就实现了这个算法。它的原理是取skey字符串的每个字符ASCII码按hash hash * 33 ascii_val迭代计算。这个值必须每次请求都重新计算且必须和你当前使用的skey完全对应否则服务器直接拒绝。分页拉取与去重逻辑腾讯接口默认每页返回20条但总群数可能上千。脚本采用“滚动分页”策略先请求st0, end20拿到result数组长度如果长度等于20说明还有下一页再请求st20, end40以此类推直到某次返回长度小于20即为最后一页。同时脚本内置了去重机制每拉取一页会检查新群ID是否已在all_groups列表中存在避免因网络抖动导致重复请求同一页面而产生脏数据。结构化字段解析接口返回的原始JSON中每个群对象包含数十个字段但脚本只提取最关键的4个-gc→ 群ID数字如123456789-gn→ 群名称字符串已自动去除前后空格和不可见字符-mf→ 成员总数数字-cr→ 创建时间戳毫秒级如1609459200000脚本会自动转换为YYYY-MM-DD HH:MM:SS格式。这些字段被组装成标准字典最终写入JSON文件结构清晰开箱即用。4. 实操过程与核心环节实现4.1 环境准备与依赖安装一行命令搞定整个项目对Python环境要求极低仅支持Python 3.7及以上版本因为dataclasses在3.7才成为标准库。推荐使用venv创建隔离环境避免污染系统Python# 1. 创建并激活虚拟环境 python -m venv qq_env source qq_env/bin/activate # Linux/Mac # 或 qq_env\Scripts\activate.bat # Windows # 2. 安装依赖requirements.txt已预置 pip install -r requirements.txt # 3. 验证安装应看到版本号无报错 python -c import requests, bs4, lxml; print(OK)requirements.txt内容极其精简requests2.31.0 beautifulsoup44.12.2 lxml4.9.3我锁定了具体版本号是因为requests 2.32.0引入了一个新的SSL验证机制在某些老旧系统上会导致CERTIFICATE_VERIFY_FAILED错误而bs4 4.13.0对lxml的依赖声明有变更可能导致解析异常。这些细节都是我在三台不同配置的机器Win10/Ubuntu 22.04/macOS Sonoma上反复验证后确定的“黄金组合”。4.2qq_count.py首次运行5秒内获得答案假设你要检测的QQ号是123456789操作如下# 进入项目根目录 cd Tb7BvJj7I7gu2DP7ndf0-master-4c28bf9315e4b280dcaa54e223cc4f458e38e154 # 直接运行无需任何配置 python qq_count.py 123456789你会立即看到类似输出[INFO] 正在探测 QQ号: 123456789... [INFO] 请求URL: https://qun.qq.com/cgi-bin/qun_mgr/search_group?gcst0end20kw123456789sort0 [INFO] 探测结果: {exists: True, group_count_estimate: 8} [INFO] 结果已保存至 ./output/qq_123456789_count.json打开生成的./output/qq_123456789_count.json内容就是那个字典。整个过程从敲下回车到看到结果通常不超过5秒。这就是轻量级探测的价值——快、准、无负担。4.3qq_count_detail.py深度执行从登录态到JSON文件的全流程这是重头戏我们以QQ号123456789为例走一遍完整流程Step 1准备登录态字典如前所述在qq_count_detail.py文件顶部找到COOKIES {...}变量将你从Chrome里复制的5个字段粘贴进去。确保格式正确无语法错误。Step 2配置目标QQ号与输出路径在同一文件中找到TARGET_QQ 123456789这一行修改为你的真实QQ号。再找到OUTPUT_DIR ./output可按需修改为绝对路径如/home/user/qq_groups。Step 3执行脚本python qq_count_detail.pyStep 4观察实时日志关键脚本会打印详细的执行日志这是你判断进度和排查问题的唯一依据[INFO] 开始拉取 QQ号 123456789 的群列表... [INFO] 计算 bkn: 1234567890abcdef... [INFO] 请求第 1 页 (0-20): https://qun.qq.com/cgi-bin/qun_mgr/get_group_list [INFO] 第 1 页返回 20 条群数据 [INFO] 请求第 2 页 (20-40): https://qun.qq.com/cgi-bin/qun_mgr/get_group_list [INFO] 第 2 页返回 20 条群数据 [INFO] 请求第 3 页 (40-60): https://qun.qq.com/cgi-bin/qun_mgr/get_group_list [INFO] 第 3 页返回 15 条群数据最后一页 [INFO] 共拉取 55 个群去重后 55 个 [INFO] 结构化数据已保存至 ./output/qq_123456789_groups.jsonStep 5验证JSON文件内容打开./output/qq_123456789_groups.json你会看到一个标准的JSON数组每个元素长这样{ group_id: 987654321, group_name: Python数据分析实战营, member_count: 427, create_time: 2022-03-15 14:22:08 }字段命名清晰时间格式统一可直接用Excel的“从JSON导入”功能打开或用pandas.read_json()载入分析。4.4SJT-code目录那些你可能永远用不到但关键时刻救命的参考代码这个目录的名字有点神秘其实它就是“Solution Just in Time”即时解决方案的缩写里面存放的是我在开发过程中遇到的、需要临时破解的小难题的代码片段。它不是主程序的一部分但却是保证主程序健壮性的幕后功臣。hash33.py实现了腾讯bkn令牌的计算。核心函数get_hash33(skey)只有12行但它是整个qq_count_detail.py能跑起来的基础。没有它所有请求都会被服务器拒之门外。decrypt_qqmsg.py一个废弃的尝试。早期我想解析群消息记录里的加密字段如msg_id发现腾讯用了自研的RC4变种。这个脚本实现了基础解密逻辑但后来发现群列表接口根本不需要它就搁置了。不过如果你未来想拓展消息分析功能它就是起点。parse_qun_html.py当腾讯某次前端重构导致get_group_list接口暂时不可用时我写的备用方案——直接解析https://qun.qq.com/member.html页面的HTML。它用lxml的XPath精准定位群列表DOM节点虽然慢一点但胜在稳定。README.md里提到了这个“降级模式”就是源于此。这些代码的存在不是为了炫技而是为了告诉你任何一个可靠的工具背后都站着无数个“备胎方案”。当主路被堵你知道还有另一条小径可以抵达终点。5. 常见问题与排查技巧实录5.1 “Invalid request”错误90%的问题都出在这里这是qq_count_detail.py最常见的报错形式通常是[ERROR] 请求失败: {ec: -3000, error: invalid request}别慌这几乎100%不是代码问题而是你的请求“长得不像一个合法的浏览器请求”。按以下顺序逐一排查检查项如何验证解决方案1. Cookie是否过期在Chrome开发者工具的Application → Cookies里看qrsig和skey的Expires / Max-Age列。如果显示“Session”说明已失效。重新扫码登录重新复制。qrsig有效期最短2小时内必过期。2. Headers是否完整在Chrome Network面板里找到get_group_list请求点开Headers对比Request Headers和脚本里headers字典的键名、值是否完全一致尤其注意大小写和空格。复制Network里的完整Headers粘贴到脚本里替换掉旧的headers字典。3. bkn计算是否正确在脚本里临时加一行print(DEBUG bkn:, self._get_bkn())再在Network里找到同一次请求的Form Data看bkn字段值是否一致。不一致检查你传给_get_bkn()的skey字符串是否包含了多余的空格或换行符。用strip()清理。4. Referer是否匹配Network里Referer值是https://qun.qq.com/member.html而你的脚本里写成了https://qun.qq.com/。严格复制Network里的Referer值一个字符都不能差。注意invalid request错误绝不会出现在qq_count.py里因为它根本不发带登录态的请求。所以一旦看到这个错直接锁定qq_count_detail.py。5.2 “Connection timed out”不是网络问题而是IP被限流现象脚本卡在[INFO] 请求第 X 页...十几秒后报错requests.exceptions.Timeout。这不是你家宽带坏了而是腾讯的反爬机制把你这个IP暂时“冷静”了。真相腾讯对get_group_list接口有严格的QPS每秒查询率限制。实测阈值是3次请求/秒。如果你的脚本没有加延时连续高速请求大概在第5~8页时就会触发限流后续所有请求都会超时。解决方案在qq_count_detail.py的_fetch_page函数里在requests.post()之前加上一行time.sleep(0.5) # 每次请求间隔0.5秒远低于3QPS阈值这个0.5秒是我经过200次压力测试后确定的“黄金值”既能避开限流又不会让总耗时变得难以忍受拉取500个群总耗时约4分钟。如果你的网络特别好可以尝试0.3如果经常超时就调到0.7。记住慢有时候就是最快的捷径。5.3 JSON文件为空或只有[]数据解析失败的典型表现现象脚本运行显示“成功”但生成的JSON文件内容是空数组[]。这说明请求成功了但解析失败了。根本原因腾讯接口返回的JSON结构发生了微小变更。比如某次更新后result字段名变成了results或者gn群名字段被移到了info子对象里。快速诊断法1. 在Chrome Network面板里找到任意一次成功的get_group_list请求2. 点开Response标签页复制全部JSON文本3. 粘贴到在线JSON格式化网站如json.cn展开看顶层结构4. 对照qq_count_detail.py里解析json_data[result]和item[gn]的代码看字段名是否还存在。修复步骤- 如果result变成了results改代码groups json_data.get(results, [])- 如果群名在item[info][name]里改代码group_name item.get(info, {}).get(name, 未知群名)- 修改后用你复制的那段JSON做单元测试python -c import json; djson.loads(你的JSON); print(d[results][0][info][name])确认能正确取出值。提示README.md里专门有一个章节叫“接口变更应对指南”里面列出了过去一年腾讯接口的7次主要变更及对应的代码修复补丁。这不是文档而是活的历史。5.4 导出的群名乱码如Python\\u6570\\u636e\\u5206\\u6790编码问题的优雅解决现象JSON文件里群名显示为\uXXXX这样的Unicode转义序列而不是中文。这是因为Python的json.dumps()默认ensure_asciiTrue会把非ASCII字符转义。一劳永逸的修复在qq_count_detail.py的save_to_json函数里找到json.dump(...)那一行改为with open(filepath, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2)关键是ensure_asciiFalse和encodingutf-8这两个参数。加了它们中文就原样输出了。这个小改动能让你的JSON文件直接用记事本打开所见即所得。6. 使用边界与法律合规再强调最后我想用最直白的语言把这件事说透。这个工具它不是一个可以帮你“监控竞争对手所有QQ群”的商业情报利器它不是一个能让你“批量导出陌生人QQ群列表”的社工武器它更不是一个可以绕过腾讯安全策略、无限次调用接口的“超级外挂”。它只是一个放大镜把你自己的眼睛放到你自己的QQ账号数据上看得更清楚一点它只是一个记事本把你手动在网页上一页页翻看、一条条抄录的群信息自动化地、结构化地、安全地记在你自己的电脑硬盘上。腾讯《QQ软件许可协议》第3.2条明确规定“用户不得利用本软件从事任何侵犯他人合法权益、违反法律法规或违背社会公序良俗的行为。” 我们所有的设计都在恪守这条底线-数据不出本地所有JSON文件只写入你指定的./output目录脚本里没有任何一行代码会尝试requests.post(https://your-server.com)-操作需授权qq_count_detail.py的首行注释就写着“WARNING: This script requires YOUR OWN valid login cookies. Do not use others’ credentials.”-用途受约束README.md开篇第一句话就是“Intended for personal account audit or data organization WITH EXPLICIT AUTHORIZATION ONLY.”仅限个人账号自查或已获明确授权的数据整理。我见过太多人因为一时好奇用这类工具去查朋友的群、查同事的群、甚至查前男友/女友的群。结果呢轻则对方收到“您的账号在异地登录”的安全提醒引发误会重则被腾讯风控系统标记为“异常行为”导致账号被临时冻结。技术没有善恶但使用者的选择决定了它的温度。所以请把它当作一把手术刀而不是一把砍刀。用它来整理你自己的数字遗产用它来归档你自己的社群资产用它来审计你自己的账号安全。当你把工具的每一次使用都建立在“知情、同意、可控”的基础上你收获的就不仅是55个群的列表更是对数字世界的一份敬畏和一份清醒。我个人在实际使用中发现最实用的场景其实是“断舍离”。每年年底我会运行一遍qq_count_detail.py把导出的JSON导入Excel按“创建时间”排序把三年没发过言、成员数跌破50、群名里还带着“2020招生”字样的群一个个移出。清理完QQ的“我的群聊”页面清爽了手机通知也少了心里反而更轻松了。技术的终极目的或许不是占有更多而是留下更少却更值得留下的东西。本文还有配套的精品资源点击获取简介提供两个Python脚本qq_count.py先检测目标QQ号是否存在、是否活跃并初步判断其关联群组数量qq_count_detail.py在登录态有效前提下抓取该QQ号实际加入的所有群聊ID、群名称、成员总数和创建时间等字段结果以结构化JSON格式保存到本地。运行需安装requests、beautifulsoup4、lxml依赖手动获取的登录凭证如Cookie或扫码后提取的session不支持免登录批量查询。配套README.md详细说明环境配置、执行步骤及常见错误排查方法SJT-code目录含协议解析与解密参考代码。所有数据仅存储于本地便于后续导入Excel或数据库做进一步整理分析。使用前请确保操作符合腾讯《QQ软件许可协议》及国家相关法律法规仅限个人账号自查或已获明确授权的数据整理场景。本文还有配套的精品资源点击获取
QQ号群组探测工具：验证账号有效性并导出全部加入群信息
发布时间：2026/6/5 23:51:03
本文还有配套的精品资源点击获取简介提供两个Python脚本qq_count.py先检测目标QQ号是否存在、是否活跃并初步判断其关联群组数量qq_count_detail.py在登录态有效前提下抓取该QQ号实际加入的所有群聊ID、群名称、成员总数和创建时间等字段结果以结构化JSON格式保存到本地。运行需安装requests、beautifulsoup4、lxml依赖手动获取的登录凭证如Cookie或扫码后提取的session不支持免登录批量查询。配套README.md详细说明环境配置、执行步骤及常见错误排查方法SJT-code目录含协议解析与解密参考代码。所有数据仅存储于本地便于后续导入Excel或数据库做进一步整理分析。使用前请确保操作符合腾讯《QQ软件许可协议》及国家相关法律法规仅限个人账号自查或已获明确授权的数据整理场景。1. 项目概述这不是“爬虫”而是一套账号自查工具链你有没有过这样的经历手头有一批老QQ号想确认哪些还活着、哪些早被弃用或者刚接手一个运营多年的QQ号想快速摸清它到底加了多少群、哪些群还在活跃、哪些群名都改得面目全非了又或者在做家庭数字资产整理时需要把长辈那个“8848”开头的老QQ号里散落的几十个兴趣群、同学群、家族群一次性拉出来归档这时候市面上那些打着“一键导出全部QQ群”的GUI工具要么早已失效要么暗藏风险——弹窗广告、静默上传、甚至偷偷调用远程服务。而这个项目从设计第一天起就锚定在一个非常朴素但关键的定位上本地化、可审计、零外联、强可控的个人账号信息自查工具。它不叫“QQ群爬虫”也不叫“群组采集器”它的名字就是“QQ号群组探测工具”。两个脚本分工明确qq_count.py是你的“探针”负责轻量级打点——输入一个QQ号它不登录、不抓群详情只通过腾讯公开的轻量接口比如群搜索预检、好友关系链反射、历史消息缓存标识等判断该号码是否注册、是否在线过、是否曾加入过群聊、大概关联多少个群注意是“关联数”不是“精确数”这是合规边界的关键设计而qq_count_detail.py才是真正的“显微镜”但它必须在你亲手完成登录验证之后才能启动——它不会自动扫码、不会模拟点击、不会绕过滑块验证它只接收你手动提供的、当前有效的登录态凭证比如浏览器开发者工具里复制的完整Cookie字符串或扫码成功后Network面板中抓到的ptwebqq、skey、qrsig等关键字段组合然后基于这个真实有效的身份向腾讯服务器发起标准的、与官方客户端行为一致的API请求逐页拉取“我的群聊”列表并结构化解析每一条返回数据。关键词里的“QQ群列表”、“Python脚本”、“登录态抓取”其实已经精准概括了它的技术内核和使用范式。它不是黑箱所有逻辑都在源码里它不越界所有请求都带着你本人的真实身份它不持久所有数据只写入你本地硬盘上的JSON文件连一次HTTP POST到第三方服务器都没有。我用这套工具帮朋友整理过三代人的QQ账号遗产也用来审计过自己十年前注册的十几个小号——最深的体会是真正的效率从来不是靠“全自动”而是靠“全透明”和“全可控”。当你清楚知道每一行代码在做什么、每一个请求发给谁、每一个响应来自哪里排查问题才不会抓瞎复现结果才不会玄学更重要的是心里才真正踏实。2. 核心设计思路与方案选型解析2.1 为什么坚持“手动登录态”而不是搞自动扫码或OCR识别这是整个项目设计哲学的基石。很多初学者看到“需要手动获取登录态”第一反应是“太麻烦了能不能自动化”——这恰恰是踩坑的开始。我试过三种主流路径方案A全自动扫码登录基于PILOpenCV识别二维码理论上可行但实测下来腾讯的扫码页面更新极其频繁去年还是纯白底黑码今年加了动态水印、背景噪点、甚至会根据IP触发不同样式。更致命的是扫码成功后的跳转逻辑不统一有时跳回https://qun.qq.com/有时跳到https://user.qzone.qq.com/有时还会弹出二次验证。一套OCR模型很难长期稳定覆盖。我维护过三个月平均每周要修两次图像预处理逻辑投入产出比极低。方案B模拟Web登录填账号密码滑块验证这条路直接被堵死。腾讯的登录页早已全面接入tcaptcha腾讯防水墙其滑块轨迹检测不仅看鼠标移动路径还会采集设备指纹、Canvas渲染特征、WebGL参数、甚至键盘敲击时序。我用Selenium跑过上千次成功率不到7%且每次失败都会触发风控导致IP被临时限制。这不是技术难度问题而是平台方明确的反自动化策略。方案C手动提取有效登录态当前采用方案这才是符合现实约束的最优解。你只需要打开Chrome访问qun.qq.com用手机QQ扫码登录一次然后按F12打开开发者工具切到Application → Cookies把qrsig、ptwebqq、skey、superkey、p_skey这五个核心字段的值完整复制下来粘贴进脚本配置即可。整个过程耗时不超过90秒且一次登录态有效期通常在3~7天取决于账号安全等级。它的优势在于100%可靠你用浏览器能访问的页面脚本就能访问零风控风险所有请求都携带你真实的、由腾讯服务器签发的凭证和你在浏览器里点“我的群聊”按钮发出的请求完全一致可审计性强你可以随时在Network面板里对照脚本发出的每个请求确认URL、Headers、Payload是否与浏览器一致学习成本低不需要懂OCR、不需要研究滑块算法只要会按F12就行。所以“手动”不是妥协而是对平台规则的尊重是对自身操作安全的负责更是对工具长期可用性的投资。2.2 为什么qq_count.py只做“存在性关联数”探测而不直接拉群列表这个问题直指合规红线。我们来拆解一下腾讯官方接口的权限分层接口类型调用条件返回数据粒度是否需登录态合规风险https://qun.qq.com/cgi-bin/qun_mgr/get_group_list必须登录态群ID、群名、成员数、创建时间、群公告摘要是低官方开放接口https://qun.qq.com/cgi-bin/qun_mgr/search_group无需登录态群ID、群名、成员数估算、简介片段否中大量调用易被限流https://r.qun.qq.com/friend/https://qun.qq.com/cgi-bin/qun_mgr/get_friend_list需登录态好友昵称、QQ号、最后上线时间是低https://qun.qq.com/cgi-bin/qun_mgr/get_group_info单群需登录态群公告全文、管理员列表、入群时间是低qq_count.py的设计严格限定在第二行——即无需登录态的群搜索接口。它的工作原理是构造一个模糊搜索词如QQ号本身作为关键词向腾讯群搜索接口发起请求解析返回的JSON中result数组的长度这个长度就是该QQ号“可能关联”的群数量上限。注意这里返回的群列表并非该QQ号实际加入的群而是所有群名、简介中包含该QQ号数字串的群比如群名叫“2023届8848班”简介里写了“联系人123456789”那么搜索“123456789”就会命中这个群。因此它返回的是一个“上界估计值”而非精确值。这种设计有三个好处1.完全规避登录依赖用户无需任何前置操作输入QQ号就能立刻得到反馈2.天然具备容错性即使该QQ号已注销只要历史上有群用过它的数字仍可能被搜到这对“查老号”场景反而更友好3.绝对合规所有请求都是公开、无认证的GET和你在网页端搜索群聊的行为完全一致不存在任何协议违规。而qq_count_detail.py则必须走第一行接口因为它要获取的是你账号“真实加入”的群列表这属于个人隐私数据腾讯绝不会对未登录用户开放。两者的分工本质上是用技术手段在“能做什么”和“该做什么”之间划出了一道清晰的、可验证的边界。2.3 为什么选择requests bs4 lxml而不是Selenium或Playwright这是一个关于“重量级”与“轻量级”的权衡。很多人一上来就想用浏览器自动化觉得“万能”。但在这个场景下它会带来三重负担资源开销大启动一个Chromium实例内存占用动辄500MBCPU持续占用而我们的核心任务只是发几个HTTP请求、解析几段JSON和HTML。用坦克去打蚊子既慢又笨重。稳定性差浏览器版本一升级XPath/CSS Selector就可能失效页面JS加载顺序稍有变化document.readyState complete的判断就可能出错更别说腾讯页面里那些动态插入的script标签经常让page.content()拿到的HTML和Network里看到的原始响应对不上。调试困难当请求失败时你是该去查Selenium的日志查浏览器控制台的JS错误还是查Network面板里的XHR三层抽象叠在一起问题定位路径被拉长了3倍。requests则完全不同。它就是一个纯粹的HTTP客户端你发什么它就发什么你收什么它就收什么。配合bs4BeautifulSoup做HTML解析lxml做底层加速bs4默认的html.parser在处理腾讯那种嵌套极深、标签不规范的HTML时解析速度慢、容错率低而lxml能自动修复缺失的闭合标签且解析速度快3~5倍整套栈就像一把瑞士军刀小巧、锋利、可靠。我做过对比测试对同一个群列表页面含200个群requestslxml解析耗时平均为127ms而SeleniumChrome从启动到拿到page.source平均耗时2.8秒且失败率高达18%主要卡在JS加载超时。对于需要批量处理多个QQ号的场景这个差距就是几分钟和几小时的区别。所以技术选型不是追求“新”而是追求“稳”不是堆砌“酷”而是回归“用”。3. 核心细节解析与实操要点3.1 登录态提取手把手教你从Chrome里“抠”出5个关键字段这是整个流程中最容易卡住的环节也是后续所有操作成败的前提。别担心它比你想的简单但有几个极易忽略的细节我用自己踩过的坑来告诉你第一步确保你是在“干净”的浏览器环境里操作不要用你日常上网的Chrome主窗口新开一个“无痕模式”窗口CtrlShiftN或者干脆用Firefox避免Chrome扩展干扰。为什么因为很多广告拦截插件如uBlock Origin会主动屏蔽腾讯域名下的某些Cookie导致你复制出来的skey是空的或者qrsig被篡改。我第一次失败就是因为忘了关AdGuard。第二步访问正确入口并完成扫码在无痕窗口中直接访问https://qun.qq.com/不是qun.qq.com带www的也不是user.qzone.qq.com。页面右上角会出现“登录”按钮点击后选择“扫码登录”。拿出手机QQ对准二维码扫描务必等待手机端显示“登录成功”并自动关闭网页而不是扫完码就切走。这一步是为了确保所有Cookie都被完整写入。第三步精准定位并复制5个字段按F12打开开发者工具 → 切到Application选项卡 → 左侧边栏展开Cookies → 点击qun.qq.com注意不是www.qun.qq.com也不是qun.qq.com下面的其他子域名。此时右侧会列出所有Cookie。你需要找的是以下5个必须一字不差地复制它们的“Value”列内容字段名典型值示例为什么必须常见陷阱qrsigv2Qx...长度约120字符扫码凭证有效期最短通常2小时用于校验扫码合法性容易和qrsig前面的ptqr混淆注意看Name列ptwebqq6a7b...长度约32字符Web端会话ID是后续所有API请求的“门牌号”值里可能含%符号复制时务必包含不要URL解码skeyod...长度约20字符加密签名密钥用于生成bkn防跨站攻击令牌值开头一定是如果复制出来是空的说明没登录成功superkeye1f2...长度约32字符高权限密钥部分群管理接口必需有些账号没有此字段可留空但qq_count_detail.py会提示p_skeyzYxw...长度约40字符用于生成bkn的另一种密钥优先级低于skey如果skey存在p_skey可选两者都为空则无法运行提示复制时右键点击Value列 → “Copy value”不要双击后手动拖选避免多复制空格或换行符。粘贴到文本编辑器后检查每行末尾是否有看不见的空格有则删掉。第四步格式化为脚本可读的字典qq_count_detail.py期望的输入是一个Python字典形如cookies { qrsig: v2Qx..., ptwebqq: 6a7b..., skey: od..., superkey: e1f2..., p_skey: zYxw... }你可以直接把这个字典粘贴到脚本顶部的COOKIES {...}变量里也可以新建一个config.py文件单独存放然后在脚本里from config import COOKIES。后者更安全避免误提交敏感信息到Git。3.2qq_count.py的探测逻辑与结果解读这个脚本的核心就一个函数check_qq_existence(qq_number)。它的执行流程如下构造搜索URLhttps://qun.qq.com/cgi-bin/qun_mgr/search_group?gcst0end20kw{qq_number}sort0这里kw参数就是你要搜索的QQ号st和end控制分页默认只查前20条sort0表示按相关性排序。发送GET请求并解析响应requests.get(url, timeout10)然后用json.loads()解析返回的JSON。关键字段是result数组。结果判定逻辑- 如果response.status_code ! 200直接报错“网络请求失败请检查网络或腾讯接口是否变更”- 如果json_data.get(result)为空列表[]则判定为“QQ号未找到任何关联群”返回{exists: False, group_count_estimate: 0}- 如果json_data.get(result)非空则统计其长度返回{exists: True, group_count_estimate: len(result)}。这里的关键是理解group_count_estimate的含义。它不是“该QQ号加入了多少群”而是“有多少个群的名称或简介里包含了这个QQ号数字”。例如搜索QQ号123456789返回结果里可能有- 群名“123456789的摄影交流群” → 精确匹配- 群名“2023届123456789班” → 模糊匹配- 简介“管理员QQ123456789有问题请私聊” → 内容匹配。所以如果你搜一个活跃的QQ号返回group_count_estimate: 15这很合理但如果你搜一个从未建过群、也从不在群简介留联系方式的QQ号返回0也完全正常。它不是一个精确计数器而是一个“存在性雷达”。我在测试时发现一个注册于2005年的老QQ号虽然早已不用但因为当年在多个班级群里留过QQ号qq_count.py依然能搜到7个关联群这恰恰证明了它的“考古价值”。3.3qq_count_detail.py的群列表拉取与结构化解析这才是重头戏。它的核心是调用腾讯官方的群列表接口https://qun.qq.com/cgi-bin/qun_mgr/get_group_list。这个接口要求极高必须携带完整的登录态和正确的Headers否则一律返回{ec: -3000, error: invalid request}无效请求。Headers构造是成败关键headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://qun.qq.com/member.html, Origin: https://qun.qq.com, X-Requested-With: XMLHttpRequest }其中Referer和Origin必须严格匹配少一个斜杠都不行。User-Agent建议用最新版Chrome的避免被识别为爬虫。X-Requested-With是告诉服务器“这是一个AJAX请求”腾讯后端会据此放行。请求体data的构造更复杂data { bkn: self._get_bkn(), # 这是核心必须动态计算 gcode: , # 群代码留空表示获取全部 gc: , # 同上 st: page_start, end: page_end, sort: 0 }bkn也叫gtk是腾讯的防跨站攻击令牌计算公式是bkn hash33(skey or p_skey)其中hash33是一个特定的哈希算法不是MD5不是SHA1。SJT-code目录下的hash33.py就实现了这个算法。它的原理是取skey字符串的每个字符ASCII码按hash hash * 33 ascii_val迭代计算。这个值必须每次请求都重新计算且必须和你当前使用的skey完全对应否则服务器直接拒绝。分页拉取与去重逻辑腾讯接口默认每页返回20条但总群数可能上千。脚本采用“滚动分页”策略先请求st0, end20拿到result数组长度如果长度等于20说明还有下一页再请求st20, end40以此类推直到某次返回长度小于20即为最后一页。同时脚本内置了去重机制每拉取一页会检查新群ID是否已在all_groups列表中存在避免因网络抖动导致重复请求同一页面而产生脏数据。结构化字段解析接口返回的原始JSON中每个群对象包含数十个字段但脚本只提取最关键的4个-gc→ 群ID数字如123456789-gn→ 群名称字符串已自动去除前后空格和不可见字符-mf→ 成员总数数字-cr→ 创建时间戳毫秒级如1609459200000脚本会自动转换为YYYY-MM-DD HH:MM:SS格式。这些字段被组装成标准字典最终写入JSON文件结构清晰开箱即用。4. 实操过程与核心环节实现4.1 环境准备与依赖安装一行命令搞定整个项目对Python环境要求极低仅支持Python 3.7及以上版本因为dataclasses在3.7才成为标准库。推荐使用venv创建隔离环境避免污染系统Python# 1. 创建并激活虚拟环境 python -m venv qq_env source qq_env/bin/activate # Linux/Mac # 或 qq_env\Scripts\activate.bat # Windows # 2. 安装依赖requirements.txt已预置 pip install -r requirements.txt # 3. 验证安装应看到版本号无报错 python -c import requests, bs4, lxml; print(OK)requirements.txt内容极其精简requests2.31.0 beautifulsoup44.12.2 lxml4.9.3我锁定了具体版本号是因为requests 2.32.0引入了一个新的SSL验证机制在某些老旧系统上会导致CERTIFICATE_VERIFY_FAILED错误而bs4 4.13.0对lxml的依赖声明有变更可能导致解析异常。这些细节都是我在三台不同配置的机器Win10/Ubuntu 22.04/macOS Sonoma上反复验证后确定的“黄金组合”。4.2qq_count.py首次运行5秒内获得答案假设你要检测的QQ号是123456789操作如下# 进入项目根目录 cd Tb7BvJj7I7gu2DP7ndf0-master-4c28bf9315e4b280dcaa54e223cc4f458e38e154 # 直接运行无需任何配置 python qq_count.py 123456789你会立即看到类似输出[INFO] 正在探测 QQ号: 123456789... [INFO] 请求URL: https://qun.qq.com/cgi-bin/qun_mgr/search_group?gcst0end20kw123456789sort0 [INFO] 探测结果: {exists: True, group_count_estimate: 8} [INFO] 结果已保存至 ./output/qq_123456789_count.json打开生成的./output/qq_123456789_count.json内容就是那个字典。整个过程从敲下回车到看到结果通常不超过5秒。这就是轻量级探测的价值——快、准、无负担。4.3qq_count_detail.py深度执行从登录态到JSON文件的全流程这是重头戏我们以QQ号123456789为例走一遍完整流程Step 1准备登录态字典如前所述在qq_count_detail.py文件顶部找到COOKIES {...}变量将你从Chrome里复制的5个字段粘贴进去。确保格式正确无语法错误。Step 2配置目标QQ号与输出路径在同一文件中找到TARGET_QQ 123456789这一行修改为你的真实QQ号。再找到OUTPUT_DIR ./output可按需修改为绝对路径如/home/user/qq_groups。Step 3执行脚本python qq_count_detail.pyStep 4观察实时日志关键脚本会打印详细的执行日志这是你判断进度和排查问题的唯一依据[INFO] 开始拉取 QQ号 123456789 的群列表... [INFO] 计算 bkn: 1234567890abcdef... [INFO] 请求第 1 页 (0-20): https://qun.qq.com/cgi-bin/qun_mgr/get_group_list [INFO] 第 1 页返回 20 条群数据 [INFO] 请求第 2 页 (20-40): https://qun.qq.com/cgi-bin/qun_mgr/get_group_list [INFO] 第 2 页返回 20 条群数据 [INFO] 请求第 3 页 (40-60): https://qun.qq.com/cgi-bin/qun_mgr/get_group_list [INFO] 第 3 页返回 15 条群数据最后一页 [INFO] 共拉取 55 个群去重后 55 个 [INFO] 结构化数据已保存至 ./output/qq_123456789_groups.jsonStep 5验证JSON文件内容打开./output/qq_123456789_groups.json你会看到一个标准的JSON数组每个元素长这样{ group_id: 987654321, group_name: Python数据分析实战营, member_count: 427, create_time: 2022-03-15 14:22:08 }字段命名清晰时间格式统一可直接用Excel的“从JSON导入”功能打开或用pandas.read_json()载入分析。4.4SJT-code目录那些你可能永远用不到但关键时刻救命的参考代码这个目录的名字有点神秘其实它就是“Solution Just in Time”即时解决方案的缩写里面存放的是我在开发过程中遇到的、需要临时破解的小难题的代码片段。它不是主程序的一部分但却是保证主程序健壮性的幕后功臣。hash33.py实现了腾讯bkn令牌的计算。核心函数get_hash33(skey)只有12行但它是整个qq_count_detail.py能跑起来的基础。没有它所有请求都会被服务器拒之门外。decrypt_qqmsg.py一个废弃的尝试。早期我想解析群消息记录里的加密字段如msg_id发现腾讯用了自研的RC4变种。这个脚本实现了基础解密逻辑但后来发现群列表接口根本不需要它就搁置了。不过如果你未来想拓展消息分析功能它就是起点。parse_qun_html.py当腾讯某次前端重构导致get_group_list接口暂时不可用时我写的备用方案——直接解析https://qun.qq.com/member.html页面的HTML。它用lxml的XPath精准定位群列表DOM节点虽然慢一点但胜在稳定。README.md里提到了这个“降级模式”就是源于此。这些代码的存在不是为了炫技而是为了告诉你任何一个可靠的工具背后都站着无数个“备胎方案”。当主路被堵你知道还有另一条小径可以抵达终点。5. 常见问题与排查技巧实录5.1 “Invalid request”错误90%的问题都出在这里这是qq_count_detail.py最常见的报错形式通常是[ERROR] 请求失败: {ec: -3000, error: invalid request}别慌这几乎100%不是代码问题而是你的请求“长得不像一个合法的浏览器请求”。按以下顺序逐一排查检查项如何验证解决方案1. Cookie是否过期在Chrome开发者工具的Application → Cookies里看qrsig和skey的Expires / Max-Age列。如果显示“Session”说明已失效。重新扫码登录重新复制。qrsig有效期最短2小时内必过期。2. Headers是否完整在Chrome Network面板里找到get_group_list请求点开Headers对比Request Headers和脚本里headers字典的键名、值是否完全一致尤其注意大小写和空格。复制Network里的完整Headers粘贴到脚本里替换掉旧的headers字典。3. bkn计算是否正确在脚本里临时加一行print(DEBUG bkn:, self._get_bkn())再在Network里找到同一次请求的Form Data看bkn字段值是否一致。不一致检查你传给_get_bkn()的skey字符串是否包含了多余的空格或换行符。用strip()清理。4. Referer是否匹配Network里Referer值是https://qun.qq.com/member.html而你的脚本里写成了https://qun.qq.com/。严格复制Network里的Referer值一个字符都不能差。注意invalid request错误绝不会出现在qq_count.py里因为它根本不发带登录态的请求。所以一旦看到这个错直接锁定qq_count_detail.py。5.2 “Connection timed out”不是网络问题而是IP被限流现象脚本卡在[INFO] 请求第 X 页...十几秒后报错requests.exceptions.Timeout。这不是你家宽带坏了而是腾讯的反爬机制把你这个IP暂时“冷静”了。真相腾讯对get_group_list接口有严格的QPS每秒查询率限制。实测阈值是3次请求/秒。如果你的脚本没有加延时连续高速请求大概在第5~8页时就会触发限流后续所有请求都会超时。解决方案在qq_count_detail.py的_fetch_page函数里在requests.post()之前加上一行time.sleep(0.5) # 每次请求间隔0.5秒远低于3QPS阈值这个0.5秒是我经过200次压力测试后确定的“黄金值”既能避开限流又不会让总耗时变得难以忍受拉取500个群总耗时约4分钟。如果你的网络特别好可以尝试0.3如果经常超时就调到0.7。记住慢有时候就是最快的捷径。5.3 JSON文件为空或只有[]数据解析失败的典型表现现象脚本运行显示“成功”但生成的JSON文件内容是空数组[]。这说明请求成功了但解析失败了。根本原因腾讯接口返回的JSON结构发生了微小变更。比如某次更新后result字段名变成了results或者gn群名字段被移到了info子对象里。快速诊断法1. 在Chrome Network面板里找到任意一次成功的get_group_list请求2. 点开Response标签页复制全部JSON文本3. 粘贴到在线JSON格式化网站如json.cn展开看顶层结构4. 对照qq_count_detail.py里解析json_data[result]和item[gn]的代码看字段名是否还存在。修复步骤- 如果result变成了results改代码groups json_data.get(results, [])- 如果群名在item[info][name]里改代码group_name item.get(info, {}).get(name, 未知群名)- 修改后用你复制的那段JSON做单元测试python -c import json; djson.loads(你的JSON); print(d[results][0][info][name])确认能正确取出值。提示README.md里专门有一个章节叫“接口变更应对指南”里面列出了过去一年腾讯接口的7次主要变更及对应的代码修复补丁。这不是文档而是活的历史。5.4 导出的群名乱码如Python\\u6570\\u636e\\u5206\\u6790编码问题的优雅解决现象JSON文件里群名显示为\uXXXX这样的Unicode转义序列而不是中文。这是因为Python的json.dumps()默认ensure_asciiTrue会把非ASCII字符转义。一劳永逸的修复在qq_count_detail.py的save_to_json函数里找到json.dump(...)那一行改为with open(filepath, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2)关键是ensure_asciiFalse和encodingutf-8这两个参数。加了它们中文就原样输出了。这个小改动能让你的JSON文件直接用记事本打开所见即所得。6. 使用边界与法律合规再强调最后我想用最直白的语言把这件事说透。这个工具它不是一个可以帮你“监控竞争对手所有QQ群”的商业情报利器它不是一个能让你“批量导出陌生人QQ群列表”的社工武器它更不是一个可以绕过腾讯安全策略、无限次调用接口的“超级外挂”。它只是一个放大镜把你自己的眼睛放到你自己的QQ账号数据上看得更清楚一点它只是一个记事本把你手动在网页上一页页翻看、一条条抄录的群信息自动化地、结构化地、安全地记在你自己的电脑硬盘上。腾讯《QQ软件许可协议》第3.2条明确规定“用户不得利用本软件从事任何侵犯他人合法权益、违反法律法规或违背社会公序良俗的行为。” 我们所有的设计都在恪守这条底线-数据不出本地所有JSON文件只写入你指定的./output目录脚本里没有任何一行代码会尝试requests.post(https://your-server.com)-操作需授权qq_count_detail.py的首行注释就写着“WARNING: This script requires YOUR OWN valid login cookies. Do not use others’ credentials.”-用途受约束README.md开篇第一句话就是“Intended for personal account audit or data organization WITH EXPLICIT AUTHORIZATION ONLY.”仅限个人账号自查或已获明确授权的数据整理。我见过太多人因为一时好奇用这类工具去查朋友的群、查同事的群、甚至查前男友/女友的群。结果呢轻则对方收到“您的账号在异地登录”的安全提醒引发误会重则被腾讯风控系统标记为“异常行为”导致账号被临时冻结。技术没有善恶但使用者的选择决定了它的温度。所以请把它当作一把手术刀而不是一把砍刀。用它来整理你自己的数字遗产用它来归档你自己的社群资产用它来审计你自己的账号安全。当你把工具的每一次使用都建立在“知情、同意、可控”的基础上你收获的就不仅是55个群的列表更是对数字世界的一份敬畏和一份清醒。我个人在实际使用中发现最实用的场景其实是“断舍离”。每年年底我会运行一遍qq_count_detail.py把导出的JSON导入Excel按“创建时间”排序把三年没发过言、成员数跌破50、群名里还带着“2020招生”字样的群一个个移出。清理完QQ的“我的群聊”页面清爽了手机通知也少了心里反而更轻松了。技术的终极目的或许不是占有更多而是留下更少却更值得留下的东西。本文还有配套的精品资源点击获取简介提供两个Python脚本qq_count.py先检测目标QQ号是否存在、是否活跃并初步判断其关联群组数量qq_count_detail.py在登录态有效前提下抓取该QQ号实际加入的所有群聊ID、群名称、成员总数和创建时间等字段结果以结构化JSON格式保存到本地。运行需安装requests、beautifulsoup4、lxml依赖手动获取的登录凭证如Cookie或扫码后提取的session不支持免登录批量查询。配套README.md详细说明环境配置、执行步骤及常见错误排查方法SJT-code目录含协议解析与解密参考代码。所有数据仅存储于本地便于后续导入Excel或数据库做进一步整理分析。使用前请确保操作符合腾讯《QQ软件许可协议》及国家相关法律法规仅限个人账号自查或已获明确授权的数据整理场景。本文还有配套的精品资源点击获取
相关文章
如何在Windows上轻松安装APK文件？APK-Installer完整教程
如何在Windows上轻松安装APK文件？APK-Installer完整教程 【免费下载链接】APK-Installer An Android Application Installer for Windows 项目地址: https://gitcode.com/GitHub_Trending/ap/APK-Installer 想在Windows电脑上直接安装安卓应用，又…
Anthropic语义压缩层消失：大模型可解释性与可控性的范式迁移
1. 项目概述：这不是一次普通更新，而是一次架构级“蒸发”“Anthropic Just Shipped the Layer That’s Already Going to Zero”——这个标题一出现，我在 Slack 群里就看到三位同行同时发了同一个表情：一个倒计时归零的数字“0”。…
DICOM文件里除了CT图像，还藏了哪些信息？一个Tag解读指南
DICOM文件里除了CT图像，还藏了哪些信息？一个Tag解读指南当你第一次打开DICOM文件时，映入眼帘的可能是熟悉的CT灰度图像。但就像一座冰山，可见的部分只是整体的一小角。那些隐藏在二进制数据中的元数据标签（Tag…
手把手教你用安信可NF-02-PA/PE模组（Si24R1）替换NRF24L01，附完整驱动移植与功耗实测
实战指南：安信可NF-02-PA/PE模组（Si24R1）替代NRF24L01全流程解析在嵌入式无线通信领域，NRF24L01系列模块曾长期占据主流地位，但随着供应链波动和技术迭代，越来越多的开发者开始寻找性能相当、成本更优的国产…
拒绝高昂维护费！资深开发者教你如何用低成本方案，将小程序/App运营成本降低90%（附避坑指南）
在移动互联网时代，拥有自己的小程序、Web 网站或 Android App 已经是许多商家和中小企业的刚需。然而，很多老板在咨询了一圈外包公司后，往往会被高昂的报价和后期繁琐的服务器维护费劝退。作为一名拥有多年一线开发经验的独立开发者ÿ…
为何VMware上云之路充满挑战？
引言：为何VMware上云之路充满挑战？ 随着企业数字化转型的深入，将本地VMware虚拟化环境迁移上云已成为降本增效、提升业务敏捷性的关键举措。然而，这条迁移之路并非坦途，从技术选型、成本评估到数据迁移、应用适配&…
Python 列表（List）与元组（Tuple）详解
Python 列表（List）与元组（Tuple）详解核心区别一句话总结：列表可变，元组不可变。这一差异决定了它们各自的应用场景和性能特性。在 Python 中，列表（List）和元组࿰…
VLM-MPC 双层架构实战，用模型预测控制解决大模型幻觉问题
从“大脑”到“小脑”：VLM-MPC 如何重构自动驾驶决策闭环 在自动驾驶技术的演进历程中，我们长期面临着一个棘手的矛盾：大语言模型（LLM）及其多模态变体（VLM）拥有惊人的常识推理与场景理解能力&am…
别再只盯着Grafana了！用Docker 5分钟搞定Prometheus+Node Exporter监控你的Linux服务器
5分钟容器化部署：用PrometheusNode Exporter打造轻量级Linux监控系统每当服务器突然卡顿或宕机时，你是否还在手忙脚乱地连SSH查日志？传统监控方案往往需要复杂的配置和漫长的学习曲线，而今天我要分享的这套方案，只需Do…
Windows下免安装凸轮轮廓生成工具：支持多种从动件与运动规律的本地化计算与DXF导出
本文还有配套的精品资源，点击获取 简介：专为机械设计场景打造的便携式凸轮设计辅助工具，运行在Windows平台，无需安装、不写注册表、不联网，双击主程序即可启动。提供直动/摆动两类从动件类型（尖顶、滚子…
DeepPCB数据集：3步构建高精度PCB缺陷检测AI系统
DeepPCB数据集：3步构建高精度PCB缺陷检测AI系统 【免费下载链接】DeepPCB A PCB defect dataset. 项目地址: https://gitcode.com/gh_mirrors/de/DeepPCB 还在为PCB（印刷电路板）缺陷检测项目找不到高质量数据集而烦恼吗？面…
Aimmy完全指南：5分钟掌握免费AI瞄准辅助工具，提升游戏操作体验
Aimmy完全指南：5分钟掌握免费AI瞄准辅助工具，提升游戏操作体验 【免费下载链接】Aimmy Universal Second Eye for Gamers with Impairments (Universal AI Aim Aligner (AI Aimbot) - ONNX/YOLOv8 - C#) 项目地址: https://gitcode.com/gh_mirrors/ai/…
Win10/Win11下Realtek 8188GU网卡驱动感叹号？别急着扔，试试这个手动安装的野路子
Realtek 8188GU网卡驱动故障深度修复指南：从原理到实战当设备管理器里那个顽固的黄色感叹号挥之不去，而你已经尝试了所有"标准操作"——Windows自动更新、第三方驱动工具、甚至重启大法——却依然无济于事时，是时候换个思路了。这篇…
AnolisOS 8.8安装源配置踩坑实录：从‘设置基础软件仓库时出错’到成功联网的保姆级指南
AnolisOS 8.8安装源配置实战指南：从诊断到解决方案的全流程解析当你在安装AnolisOS 8.8时遇到"设置基础软件仓库时出错"的提示，这通常意味着系统无法访问或识别安装源。这个问题看似简单，但背后可能涉及网络配置、镜像选择、启动参…
基于树莓派Pico的反应速度测试游戏：从GPIO编程到状态机实战
1. 项目概述与核心思路最近在整理工作室的电子元件，翻出来几个闲置的街机按钮和一块树莓派Pico，灵机一动，决定做个简单又有趣的反应速度测试游戏。这个项目非常适合想入门嵌入式开发的朋友，它不涉及复杂的传感器和通信协议&#x…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…