imap_open连接失败主因是认证或协议配置错误：未用应用专用密码、服务器地址缺/ssl、超时过短；调试需用imap_last_error()、检查RFC2822时间戳、UTF-7文件夹编码及UID参数一致性。
imap_open 连接失败的常见原因和调试方法
连接不上邮箱服务器，90% 是认证或协议配置问题。PHP 的 imap_open 对 TLS/SSL、端口、加密方式极其敏感，不能只靠“试试看”。
- 检查服务器地址格式是否带协议前缀：
{imap.gmail.com:993/imap/ssl/novalidate-cert}—— 缺少/ssl或写成/tls会导致静默失败 - Gmail 等现代服务必须开启「应用专用密码」，直接用账户密码会返回
[AUTHENTICATIONFAILED]错误 - 连接超时默认仅 15 秒，大邮箱首次读取可能卡住，建议显式加
/timeout=60 - 用
imap_last_error()查错误比看返回值更可靠，imap_open失败时返回false，但不抛异常
读取邮件正文时如何正确解析 multipart 和编码
直接调 imap_body 拿到的是原始 MIME 内容，含 base64、quoted-printable、多段结构，不是可读文本。
- 先用
imap_fetchstructure判断结构类型：如果$part->type == 1（即TYPETEXT），再查$part->encoding值（0=7bit, 1=8bit, 2=bin, 3=base64, 4=qp） - 对 base64 内容必须用
imap_base64解码，别用 PHP 原生base64_decode—— 后者不处理换行和空格，易解错 - 中文主题或发件人名常是
=?UTF-8?B?...格式，需用imap_mime_header_decode解析，不能直接mb_convert_encoding - HTML 邮件正文常藏在
multipart/alternative的第二个子部分（纯文本在前，HTML 在后），要递归遍历$structure->parts
用 imap_append 写入邮件到指定文件夹的注意事项
imap_append 不是“发送邮件”，而是把已构造好的 RFC822 格式字符串存进 IMAP 文件夹（如 Drafts、Sent），且对时间戳、换行、文件夹名编码很挑剔。
- 时间戳必须是 RFC2822 格式，推荐用
date('r', time())，手拼字符串极易出错 - 邮件内容末尾必须有
\r\n\r\n分隔头与体，且整个字符串以\r\n结尾（不是\n），否则某些服务器（如 Dovecot）拒绝写入 - 目标文件夹名若含中文（如 “已发送”），得用
imap_utf7_encode编码，否则报[TRYCREATE] - 写入后不会自动触发收件箱索引更新，新邮件不会立刻出现在
imap_search结果里，需等服务器同步或手动imap_expunge（仅对标记删除有效）
imap_search 性能差、结果不准怎么办
在大邮箱（>1w 封）上用 imap_search($mbox, 'SINCE "1-Feb-2024"') 可能超时或漏匹配，IMAP 服务器对搜索字段的支持程度差异极大。
立即学习“PHP免费学习笔记（深入）”；
- 避免用
TEXT或BODY全文搜索，改用HEADER SUBJECT或FROM，速度提升数倍 - 某些服务器（如 Outlook.com）不支持
UNSEEN和SEEN组合搜索，需分两步：先imap_search(..., 'ALL')拿 ID 列表，再用imap_fetch_overview查 flags 字段判断已读 - 搜索结果返回的是 UID 还是序列号，取决于你打开连接时是否加了
/uid参数 —— 不加的话，后续imap_fetchbody传的 ID 会被当成序列号，容易越界 - 频繁搜索建议缓存 UID 最大值和最小值，用
UID n:m范围代替全量扫描
IMAP 协议本身没有事务和强一致性保证，同一邮箱被多个进程操作时，UID 可能跳跃、FETCH 返回空、APPEND 成功但不可见——这些不是 PHP 的 bug，是协议设计使然。关键操作后加一次 imap_check 看服务器状态，比反复重试更稳妥。
