SMTP需用状态机驱动的行协议解析器，而非正则或字符串分割；关键在于以\r\n为界手动提取行、维护跨调用buffer、严格区分COMMAND/DATA_BODY/RESPONSE_WAIT状态，并在DATA阶段正确处理.转义。
SMTP 交互数据不是“协议解析”，而是状态机驱动的行协议解析
直接用 std::regex 或字符串分割去“解析 SMTP 命令”会失败——SMTP 不是结构化格式（如 JSON），而是基于换行分隔、状态依赖、命令/响应成对、且允许跨行内容（如 DATA 后的邮件体）的交互式文本协议。真正要做的，是实现一个轻量级的、带状态的行读取器，而非“解析器”。
关键点：
-
SMTP通信以\r\n为唯一合法行结束符（RFC 5321 要求），\n单独出现属于非法或中间状态 - 必须区分“命令行”（客户端发）和“响应行”（服务端回），二者语法不同：
HELO domain是命令；220 mail.example.com ESMTP是响应 -
DATA命令之后的内容直到单独一行.（即"\r\n.\r\n"）才结束，期间任何\r\n都属于邮件体，不能按行切分后直接处理 - 响应码是三位数字开头（如
250、354），但可能带多行响应（以-结尾表示继续，
用 std::getline + \r\n 检测做基础行提取，但必须保留原始字节流上下文
别用 std::getline(ss, line) 默认按 \n 切——它会把 \r\n 中的 \r 留在前一行末尾或吞掉，破坏协议边界。正确做法是手动扫描 \r\n：
std::string buffer;
std::string line;
size_t pos;
while (true) {
// 假设 recv_data 是从 socket 收到的新字节（std::vector<char> 或 std::string）
buffer += recv_data;
while ((pos = buffer.find("\r\n")) != std::string::npos) {
line = buffer.substr(0, pos);
buffer.erase(0, pos + 2); // 删除 \r\n
if (line.empty()) continue; // 忽略空行（某些实现会发）
handle_smtp_line(line); // 分发给状态机
}
// buffer 末尾可能有不完整行（如只收到 "\r"），必须保留等待后续数据
break;
}
注意：
立即学习“C++免费学习笔记（深入）”；
- 不能假设一次
recv()一定返回一整行；TCP 是字节流，\r\n可能被拆在两次收包里 -
buffer必须跨调用持久化（比如作为类成员），否则会丢字节 - 若遇到
"\n\r"或纯\n，属于协议违规，可记录警告但不必崩溃（部分老旧客户端会出错）
状态机必须区分 COMMAND、DATA_BODY、RESPONSE_WAIT 三类模式
SMTP 交互本质是客户端和服务端交替主导的状态流转。C++ 中推荐用枚举 + 成员变量控制，而不是靠函数调用栈隐含状态：
enum class SmtpState {
COMMAND,
DATA_BODY,
RESPONSE_WAIT
};
SmtpState state_ = SmtpState::COMMAND;
状态切换逻辑示例：
- 收到
"DATA\r\n"→ 切换到DATA_BODY；后续所有行（包括空行）都暂存为邮件体，直到遇到"." - 收到
"QUIT\r\n"→ 发送"221 Bye\r\n"并关闭连接，无需等待响应 - 客户端侧：发完
MAIL FROM:后必须进入RESPONSE_WAIT，直到收到250或5xx才能发下一条 - 服务端侧：收到
RCPT TO:后不能立即响应，需校验邮箱格式/权限，再回250或550
漏掉状态隔离会导致：把邮件体第一行误认为新命令，或在 DATA 过程中提前响应 250 OK。
DATA 段内的 . 转义规则必须手动还原
RFC 规定：邮件体中如果某行以 . 开头，发送方必须在前面加一个额外 .（即变成 "..something"），接收方需将 ".." 开头的行还原为 "." 开头。这不是可选优化，是强制要求。
还原逻辑必须放在 DATA_BODY 状态下、写入最终邮件体之前：
if (line.length() >= 1 && line[0] == '.') {
if (line.length() >= 2 && line[1] == '.') {
// 还原 "..hello" → ".hello"
line = line.substr(1);
} else if (line == ".") {
// 结束标志，退出 DATA_BODY 状态
state_ = SmtpState::COMMAND;
break;
}
}
// 此时 line 才是真实邮件体的一行
常见坑：
- 只检查行首
"."，没处理".."转义 → 导致邮件体内容丢失首字符 - 在切分行之前就做转义还原 → 把
"Subject: ...\r\n"中的...误判为转义 - 把
"\r\n.\r\n"中的.和前后\r\n分开处理 → 状态判断失效
协议边界的严格性远高于业务逻辑——少一个 \r、多一个空格、状态切换早一帧，整个会话就可能被对方拒绝。与其堆砌抽象，不如把 \r\n、状态枚举、转义还原这三处钉死。
