Gmail 앱 비밀번호, IMAP, API: 세 가지 접근 방법과 각각 언제 사용해야 하는지

最常见的Gmail问题其实不是Gmail的问题。客户端或脚本拿到了账户密码，连接却被拒绝，于是顺理成章地认为是密码错了。其实不是。Google早已不再接受邮件客户端使用账户密码，它要求的是应用专用密码。

应用专用密码，以及一个没人提的前提

应用专用密码是在账户内生成的一组独立凭据，供某个客户端代替登录密码使用。关于它有三件事，几乎能解释所有“怎么不行”的搜索：

• 不开启两步验证，就无法创建。这是大多数问题的答案。没有第二重验证的账户，根本不会显示生成应用专用密码的选项，所以人们找的页面压根不存在。先开启两步验证，选项就会出现。
• 只显示一次。生成、展示，之后无法再找回。丢了就只能重新生成，而不是去查。
• 显示时带空格，输入时不带。十六个字符分成四组。有些客户端能处理空格，有些不能，光这一点就足以解释相当一部分明明密码正确却失败的情况。

它们是在Google账户的安全设置里生成的，不在Gmail自身的设置里，这也是人们找不到页面的另一个原因。

如果你买了一个账户，商品描述里提到应用专用密码，那串字符就是填进客户端的东西。账户的登录密码在那里不管用，反复尝试只会招来你不想要的额外验证。

三种接入方式

网页登录

浏览器、密码、如果有的话再加一个第二重验证。对人来说没问题，对脚本来说就很糟糕。通过网页流程自动登录会遇到验证码、陌生设备提示，有时还有手机验证，因为这个流程正是被监控来识别这种模式的。当脚本“登不进去”但凭据正确时，通常就是这个错配造成的。

IMAP和SMTP

邮件协议，所有邮件客户端和邮件库都在用。需要上面说的应用专用密码。最适合读取收件箱、等待某封邮件或发送邮件，而无需自己搭建任何东西。

实用设置：IMAP走993端口配SSL，SMTP走587端口配STARTTLS，用户名用完整邮箱地址。注意，有些账户的IMAP访问默认是关闭的，需要在Gmail自己的设置里开启，这和应用专用密码是两回事，当凭据确认无误时值得检查一下。

Gmail API

一个正经的编程接口，通过OAuth2访问。你需要注册项目、配置OAuth客户端、完成一次授权流程，之后程序就使用拿到的令牌。

相比IMAP有两个实打实的好处：权限是范围化的，可以只给程序只读权限而不是完全控制；拿到的是结构化消息数据，不用自己解析原始邮件。也有两个实打实的代价：配置确实更费事，而且授权页面根据你申请的内容有自己的审核规则。

适合用于你正在构建和维护的东西。如果只是从收件箱里读个验证码，IMAP才是匹配的答案。

一句话选择

• 人查邮件：网页，或任何走IMAP的客户端。
• 脚本读消息：IMAP加应用专用密码。配置最少，到处都能用。
• 你在开发的软件：API，为了范围化权限和结构化数据。
• 脚本驱动网页界面：别。你遇到的阻力是刻意设计的，不会消失。

买邮箱时这意味着什么

商品描述里有两个字段对应上面的内容，而且它们不是一回事。

包含应用专用密码意味着两步验证加生成的活儿已经干完了，你可以立刻连接客户端。OAuth2交付走的是API路线，这时完整性才是关键：一个刷新令牌如果没有配对的客户端ID和密钥，当前访问令牌过期后就会永久失效。这个失败发生在保修期早已结束之后，所以检查的重点不是“现在能不能连”，而是“我能不能完成一次刷新”。

价格方面值得知道：在整个邮箱目录里，协议访问是最便宜的属性之一，而验证类属性如两步验证和短信验证是最贵的，分别约为中位价的三倍和近三倍。访问很便宜；被验证不便宜。

Gmail列表，可按应用专用密码和OAuth2标签筛选，在Gmail货架上。