我做了很多年系统开发也一直有整理旧账号的习惯。前几天翻邮箱时看到一封两年前的注册确认信才想起自己在一个早就没用的社区论坛留过邮箱。那之后我一直在想一个问题除了这些能想起来的地方我的邮箱到底还散落在哪些平台如果要一份清单有没有办法不一个个去试密码找回就能知道大概范围然后我遇到了 holehe。这个由 megadose 维护的开源命令行工具可以在终端里输入一个邮箱然后检查它在哪些网站上注册过账号。工具本身非常简单但用了一段时间之后我的感受是它真正解决的不是“查一下某个人”而是把“我到底在互联网上暴露了多少登录入口”这个模糊问题变成一份可以定期复查的资产清单。这篇文章我想从功能、用法、结果解读、自动化边界和合规风险几个方面把它讲透。1. 先理解 holehe 到底解决的是哪类问题1.1 一个邮箱背后往往是一堆没人记得的注册记录过去十年我们用邮箱注册过论坛、SaaS 工具、购物网站、视频站点、在线课程平台。账号一多就会出现两种情况要么因为长期不用密码可能是十几年前的弱口令要么这个平台本身已经停止维护数据库是否泄露你也不清楚。问题在于很多平台不会主动通知你“你的账号还活着”也不会告诉你“你的密码可能曾经出现在泄露事件里”。你真正缺少的是一个不依赖记忆的、可执行的检查入口。holehe 做的事情就是把这个入口搬到终端里。它不是去搜索页面而是针对每个站点模拟一个非常轻量的请求去判断这个邮箱是否在该平台已经注册过。整个过程不需要密码不需要验证邮箱收到的邮件也不需要真的登录目标平台。这也是它的核心定位邮箱与网络服务账号关联性的快速探测工具。它不是数据泄露搜索引擎也不声称能拿到所有平台的注册关系。1.2 为什么这个问题过去不好解决想弄清自己的邮箱注册过哪些平台通常有几条路但都不太行。第一条路靠邮箱搜索。你在 Gmail 或 QQ 邮箱里搜索“注册”、“欢迎”、“验证”能找回一部分历史邮件。但很多平台注册时并不会发一封永久保留的邮件有些注册后立刻删了有些用的是第三方登录有些是早期服务邮件早就清理掉了。这个方案注定不完整。第二条路逐个到目标网站试密码找回。这个成本极高你首先得记得自己可能注册过哪些网站然后还要面对验证码、找回流程、账号被锁定的风险。即使你只试十个平台也得花掉半天。第三条路用密码管理器或浏览器的已存账密去盘点。这个方法有参考价值但前提是你过去一直用同一套密码管理器。对于大多数普通用户和很多技术人来说历史资产本来就是分散的。holehe 的思路完全不同。它用不着你在每个站点留下行为痕迹而是直接利用这些站点提供的密码找回或注册接口通过响应差异判断邮箱是否被占用。你把同一个邮箱交给他它一次性对几十个站点发起探测然后把“已注册 / 未注册 / 未知”的状态列出来。速度比人工检查快得多而且它可以反复跑适合定期复查。1.3 它对普通用户和开发者的意义不一样对普通用户来说holehe 可能是一个“查一次就清一次账号”的小工具。你跑完一轮看到哪些旧平台还有你的邮箱然后决定是去注销还是改密码问题就结束了。对开发者、安全研究和隐私保护场景来说holehe 更像是一个资产梳理组件。你可以把它嵌入到自己的邮箱巡检脚本里定期输出每个邮箱的注册平台清单然后和泄露情报库、密码管理记录做交叉比较来判断某个平台的注册信息是否已经过时是否存在继续保留的必要。所以我的关键判断是holehe 不是用来“偷查别人”的它最实用的场景是“自我暴露面梳理”。你把工具跑一遍本质上是把一个抽象的隐私风险翻译成一个个具体的处置动作。2. 安装和最小使用从拉取到第一条结果2.1 环境准备与项目获取holehe 是一个 Python 实现的开源命令行工具项目地址在 GitHub 上仓库名为megadose/holehe。使用之前最简单的准备是确认你的机器上有 Python 3 环境并且能够正常访问 GitHub 和依赖下载源。常见做法有两种。第一种直接 clone 仓库然后在项目目录里运行git clone https://github.com/megadose/holehe.git cd holehe python3 -m pip install -r requirements.txt python3 holehe.py youexample.com第二种如果项目提供了 PyPI 安装包也可以尝试用 pip 安装到全局或虚拟环境python3 -m pip install holehe holehe youexample.com这里要提醒一句不同版本、不同分支的使用方式可能有差异。我建议你先以项目仓库 README 里的说明为准不要盲目相信任何博客里的固定命令包括这一篇。如果你想保持环境干净可以在 clone 之后先创建一个虚拟环境python3 -m venv venv source venv/bin/activate python3 -m pip install -r requirements.txt这样依赖不会污染你的系统 Python后面升级工具或清理时也更方便。2.2 第一次运行建议先跑一个真实但不敏感的数据安装好之后先用一个你自己常用的邮箱跑一遍不要一开始就拿别人的邮箱或工作邮箱做实验。原因有两个第一你要先熟悉它的输出格式这时候用真实数据最直观第二未经授权扫描他人邮箱无论在法律上还是平台规则上都可能踩线。最小运行命令很简单python3 holehe.py youexample.com命令输出一般会按站点逐行显示状态。不同版本的显示字符可能略有不同但常见的含义是[]表示该平台存在对应账号也就是“已注册/被使用”[-]表示该平台没有检测到对应账号[?]表示无法判断可能是平台需要验证码、网络异常或反爬策略拒绝。你第一次跑完大概率会发现有些平台的结果是[]有些是[-]还有一部分是[?]。不要急着下结论。[]并不代表这个账号一定对你有风险只说明邮箱和该平台之间存在关联记录[?]也不代表工具不行有很多站点因为接口限制本来就无法给出稳定判断。我用一个表格整理一下常见的状态理解输出状态常见含义建议动作[]检测到该邮箱在此平台已有账号判断该平台是否仍在使用若不使用则尽快处理[-]未检测到账号仍不能 100% 保证从未注册过只是接口没有给出注册信号[?]无法判断可以考虑手动访问一次或忽略该平台超时/无响应站点可能反爬或网络不可达降低频率稍后重试不必继续硬跑2.3 常用参数先看全量再按需过滤如果你只想知道哪些平台有账号不希望看到一堆“未注册”的干扰信息可以尝试--only-used参数。但在刚上手时我不建议一上来就用它。原因很简单你首先需要了解工具的覆盖范围和状态分布尤其是那些[?]的平台。如果直接过滤掉[-]你可能会误以为剩余结果就是全部实际上很多站点因为验证码或接口限制根本没有进入判断阶段。更合理的做法是第一次全量输出把结果保存下来再根据需求过滤。常见参数可以这样组合使用python3 holehe.py youexample.com --only-used --output result.txt--output会把结果写入文件方便后续整理。不同版本支持的参数会变化建议运行下面命令查看当前版本帮助python3 holehe.py --help我习惯先跑一轮全量把原始输出存成raw-日期.txt再用--only-used生成一份精简清单。这样即使后面发现某个平台状态解释有差异我还可以回到原文件里对照。注意不要因为工具体量小就忽略了版本差异。我遇到过因为 Python 版本和依赖版本不匹配工具直接无法启动的情况先跑--help是最快的环境自检动作。3. 结果怎么读正确理解“注册/未注册/失败”三类状态3.1 不要把一个轻量探测当成法院判决holehe 并不是逐一登录这些网站然后看到你的账号页面。它的判断逻辑通常是利用各平台“注册检查”或“密码找回”接口的响应差异。当你在注册页输入一个邮箱网站往往会返回“该邮箱已被注册”或“该邮箱可以使用”当你在密码找回页输入邮箱很多平台也会给出“如果该邮箱存在我们已发送重置链接”之类的提示。工具要做的就是在这些接口上掷出请求然后根据返回内容判断邮箱是否被占用。这本质上是一种“旁路探测”思路而不是对数据库的权威查询。因此结果天然存在误差。我举个例子。有些平台为了防枚举无论邮箱是否注册都会返回同样的提示。这种情况下holehe 可能不会把它判为错误而是直接归为[?]。有些平台则因为接口返回格式变化工具需要更新才能匹配。所以看到[-]不代表你过去一定没注册过看到[?]也不必焦虑。3.2 最值得关注的是 “已注册但你已经不用” 的旧资产跑完一轮之后真正需要人工介入的是那些结果为[]且你内心已经判定“不再使用”的平台。这类账号之所以有风险不是因为它们存在而是因为它们长期无人维护。很多旧平台可能仍保留着你早期的密码哈希如果这个平台后来发生数据泄露而你当时又用了和邮箱主密码相同或相似的密码影响就会连锁扩散。更麻烦的是有些平台你早已忘记账号但它们可能还绑定了手机号、备用邮箱甚至第三方登录。所以结果里出现[]时我建议你把平台拆成三类仍然长期使用比如微信、GitHub、公司邮箱这类账号要确保密码独立且开启多因素认证。偶尔使用但不是必需这类账号可以先去确认是否能正常登录然后考虑修改密码或换绑主邮箱。已经确定不用的不要犹豫按平台流程注销。如果平台没有真正注销入口那就把密码改成随机字符串同时解绑手机号、备用邮箱和第三方登录。3.3 结果要保存也要定期重跑邮箱和平台的关联关系不是一成不变的。你今天注册了一个新平台明天可能又因为某个服务的账号整合产生新的关联记录。反过来有些平台注销后可能在接口层面就不再返回“已注册”状态有些平台因为业务下线记录消失。因此为了把握趋势最好把每次结果按日期保存下来。我给自己定的节奏是每季度跑一次个人主要邮箱每次输出保存到本地文本文件。文件名带上邮箱别名和日期比如alice-main-20250628.txt。只有当连续两次结果出现明显变化时我才会去核对具体平台。这个操作看似简单但价值不小。它让你从“被动发现账号泄露”转为“主动维护账号资产”这是隐私管理和安全习惯里很关键的一步。4. 自动化与批量不能只是脚本跑得越快越好4.1 可以让工具处理多个邮箱但要控制节奏如果你像我一样手上有两个或三个常用邮箱可能希望批量执行而不是一个邮箱跑完再敲一次命令。批量执行在技术上不难可以用一个简单的 shell 循环for email in aliceexample.com bobexample.com; do python3 holehe.py $email --only-used --output ${email%$*}-$(date %Y%m%d).txt sleep 10 done这里故意加了一个sleep 10不是多余的动作。holehe 会向很多目标平台发送请求如果连续高频运行很容易触发网站的反爬策略。网站方对枚举类请求一直很敏感尤其是在密码找回和注册接口上。控制频率既是为了避免自己的 IP 被临时限制也是为了不给目标平台造成无谓的压力。当然更稳妥的做法是不要用 shell 循环硬跑而是写一个 Python 脚本对每个邮箱、每个用例设置延迟并记录哪些站点出现超时或验证码。这类脚本不用太复杂核心就是“慢一点 留日志”。4.2 把输出整理成可读的资产清单工具默认的输出是按行展示适合人眼扫读但不太适合长期管理。我建议跑完之后把结果整理成结构化格式比如 CSV 或 Markdown 表格。你可以根据自己的习惯处理。比较省事的路径是保存工具输出再用一个小脚本读取并转换。我不建议一上来就做一个漂亮的仪表盘因为工具本身的结果变化和误差太多过早追求可视化反而会让人过度信任那些状态标记。批量处理的目标是让你能够回答三个问题我的每个邮箱在多少平台有账号这些账号里哪些已经长期不用了和上一次运行相比新增了哪些注册关系消失了哪些能回答这三个问题批量自动化就已经有价值了不需要堆砌更多复杂功能。4.3 不要试图把它变成一台全自动扫描器这里我必须把边界说清楚。holehe 本身是一个合法的 OSINT/辅助工具但“合法工具”和“合法使用”是两件事。未经允许批量扫描他人邮箱或者拿它去枚举一个平台的用户邮箱是否注册不仅可能违反目标网站的服务条款在特定场景下还可能构成对个人信息的侵害。我理解技术人看到命令行工具时会很兴奋觉得功能不够可以自己加模块不够可以自己写甚至想把它包装成内部服务给团队跑一批邮件列表。这种想法看起来很“自动化”但至少在三个层面有问题法律风险如果你处理的邮箱不属于你也没有获得授权这个行为的性质就变了。平台风险高频请求会触发封禁导致你的出口 IP 被拉黑甚至影响同网络里的其他服务。数据误判批量结果如果被直接用于“此人是否在某平台有账号”的判断错误率会很高最终误导决策。所以如果要做自动化我建议把它限制在“自己的邮箱资产巡检”范围内并且主动做小流量、低频率、带日志的设计。提醒如果输出里大量出现[?]不要为了提高成功率而盲目缩短请求间隔。这时候更该检查是不是已经触发了反爬或者某些站点本身就对这类探测不友好。5. 落地合规与风险边界哪些场景适合用哪些不适合5.1 它适合检查自己的历史注册痕迹holehe 最适合的场景是梳理个人历史注册痕迹。比如你想知道某个旧邮箱在哪些平台注册过用它可以快速建一个候选清单。拿这个清单去和密码管理器里的记录比对你就能知道自己过去到底有多少“重复密码”风险。再比如你在做入职后的资产交接需要确认自己是否把公司邮箱注册过外部 SaaS 工具用它可以快速摸底避免留下未清理的企业账号。这些都是围绕“自己或授权数据”展开的合规场景。工具的价值在于降低盘点成本让你把注意力放到后续处置上而不是在搜索邮件堆里浪费几个小时。5.2 它不适合用来做“他人画像”我见过一些技术群讨论拿到一个邮箱能不能用 holehe 查一下这个人在哪些平台注册过以此判断对方身份信息。我必须直接说这个用法非常危险。一个邮箱关联的平台往往能反推出身份、偏好、行为习惯这是不折不扣的个人敏感信息。未经授权查询、存储、转述这些信息不是“技术研究”而是对他人隐私的越界。即使你有正当原因需要核验某个邮箱是否属于目标平台用户也应该通过正式的授权渠道或法律程序而不是用旁路探测绕开平台规则。因此我把“不适用场景”列得更具体一些适用场景不适用场景检查自己的邮箱注册过哪些平台用他人邮箱做账户探测对已授权的数据资产做定期盘点对陌生邮箱做批量画像安全研究人员在授权范围内验证枚举风险绕过平台反制措施后批量采集个人隐私自检和账号清理将结果用于骚扰、追踪、误解或威胁这个表格不是套话而是每个愿意长期用这类工具的人都应该有的基本边界感。5.3 “能探测到”不等于“一定准确”“查不到”也不等于“没有”另一个风险边界是结果可信度。很多人第一次跑完 holehe容易陷入两种极端看到[]就觉得天塌了看到[-]就觉得高枕无忧。实际上它只是一个基于公开接口的探测工具既不是密码管理器导出数据也不是泄露数据库查询结果更不是平台官方给出的“用户关系证明”。你真正需要做的是把结果当作一个线索而不是结论。在决定执行注销、改密码、解绑手机号这类动作之前最好再打开对应平台用正常的找回流程或登录流程确认一次。工具帮你缩小搜索范围但不能替你完成最终的账号处置。这也是我反复强调的一个判断holehe 的长期价值不在于让你“快一点知道结果”而在于让“账号资产梳理”这个动作变得可重复、可记录、可对比。真正重要的始终是对结果的解读和后续动作。6. 我建议的邮箱暴露面检查三步法6.1 第一步先盘出你真正需要巡检的邮箱清单不要一上来就到处找工具先想清楚你要保护哪些邮箱。很多人会忽略这一步只拿当前最常用的邮箱跑一遍。但实际上你过去可能用过好几个邮箱包括旧工作邮箱、大学邮箱、临时注册邮箱。一个邮箱一旦从你的日常生活中退出它反而更容易被忽视而旧邮箱往往承载着更早期的注册关系风险不一定更低。所以第一步动作是列清单。把你能想起的所有邮箱地址写下来再通过历史邮件、密码管理器、网购记录、简历投递记录确认这份清单是否完整。不需要追求一次就精确但要为每个邮箱标记一个“用途角色”比如主邮箱、购物邮箱、旧工作邮箱、临时注册邮箱。6.2 第二步用一个稳定的流程执行首次扫描接下来对每个邮箱执行一次 holehe 检查。这里的“稳定流程”包括三个方面。第一记录环境信息。用哪台机器、哪个工具版本、什么时间跑的、网络出口大概是什么环境都记录下来。这样后续排查问题时有据可依。第二控制输出范围。每个邮箱先跑全量再生成--only-used的简化结果。文件命名建议带上邮箱别名和日期比如work-old-20250628.txt。第三标记异常站点。把大量返回[?]或超时的站点单独记到一个文件里。不要急着重试先等一下再考虑是否需要人工访问确认。这一步的目标是得到一份“当前暴露面的基线数据”。以后你再跑都可以和这份基线对比看新增了哪些平台消失了哪些平台。6.3 第三步按“保留 / 修改 / 注销”三类做处置拿到基线后逐一对[]的平台做分类。保留你仍在正常使用并且这个平台本身值得信任。处理方式是确认密码强度开启多因素认证最好让这个平台不再使用和其他站点重复的密码。修改你偶尔使用但担心密码旧了可以去设置里修改密码、解绑不用的手机号、清理第三方授权。注销你确定不再使用去平台的注销或关闭账号入口处理。如果平台没有注销只有“删除账号”或“禁用账号”那就照做并把密码改成随机值。处理完后保留一份“已完成处置平台”清单。以后复跑时如果某个已经注销的平台又出现在结果里你就要引起警觉这可能是平台数据没有真正删除也可能是你的邮箱被某个新的注册流程错误关联了。6.4 常见问题排查链路如果过程中遇到异常我建议按下面的顺序排查而不是一上来就重装工具。先看现象是命令无法启动、输出为空、全部未注册、还是大量超时再看输入邮箱格式是否正确是否包含多余空格网络环境是否正常再看环境Python 版本是否满足要求依赖是否完整有没有因为系统权限导致工具无法创建临时文件再看参数是否用了不兼容的参数有没有把--output写到没有权限的目录再看目标站点是否有个别平台本身处于维护状态或者已经下线服务最后看工具版本本地仓库是否过旧有无已知 issue 和更新这套排查链路本质上和排查任何命令行工具没有区别但它对 holehe 尤其重要。因为工具依赖外部站点的接口行为外部一变化结果就跟着变。你只有先确认本地环境是干净的才能把问题归因到工具或目标平台。写在最后工具会被绕过但资产意识不会过时holehe 这类工具出现之后确实让“查邮箱注册痕迹”变得容易了。但工具越容易用越需要你带着判断去用。我不希望你把它当成“查别人账号”的奇技淫巧也不希望你因为一次结果不完美就放弃它。我更希望你能通过它建立起一个属于自己的、可持续执行的账号资产盘点习惯。这个习惯听起来很小但在越来越多平台要求绑定手机、验证邮箱、授权第三方登录的今天它其实是保护个人边界的一种基本功。从实操上说你先做一件事就够了选一个自己最常用的邮箱跑第一次全量检查把结果存下来然后挑一个已经不用但列在结果里的平台完成注销或密码重置。这一套动作走完你就不会再把 holehe 当成一个玩具而是真正把它用成了数据资产管理的入口。
