正确识别boundary需先从content-type头提取无引号的boundary值，构造"--boundary\r\n"和"--boundary--\r\n"两种分隔模式，统一换行符后用string_view滑动扫描；切分时须严格匹配分隔行，且仅在header结束（\r\n\r\n）后按content-length或下一合法分隔行截取body，避免二进制内容误匹配。
如何识别 boundary 并正确切分 multipart 报文
直接用 std::string::find 扫描 "--" 前缀极大概率出错——MIME boundary 本身不带前导破折号，但分隔符行必须以 "--" 开头，且后面紧接 boundary 字符串，末尾可能有 "--" 表示结束。真正可靠的切分点是完整匹配形如 "\r\n--boundary\r\n" 或开头的 "--boundary\r\n"（首段前无空行）。
常见错误：把 Content-Type: multipart/mixed; boundary="abc123" 中的 "abc123" 直接当分隔符字符串用，却忽略 RFC 2046 要求——实际分隔符行是 "--abc123"，终止段是 "--abc123--"。注意引号、空格、CRLF 换行都影响匹配。
- 先从
Content-Type头提取boundary参数值，用std::quoted（C++14+）或手动去引号 - 构造两个分隔符模式：
"--" + boundary + "\r\n"（段间）和"--" + boundary + "--\r\n"（结尾），注意结尾也可能以"\r\n"或"\n"结束，建议统一 normalize 换行为"\r\n" - 避免用
std::regex做切分——性能差且 Windows 行尾处理易出错；改用std::string_view+find手动滑动扫描更稳
如何安全提取每个 part 的 headers 和 body
每个 part 以分隔符开始，紧接着是若干 header 行（空行结束），之后才是 body。关键陷阱在于：body 可能含任意二进制数据，包括与分隔符相同的字节序列——所以不能全局搜索 boundary，只能在 header 区域结束后，按 Content-Transfer-Encoding 和 Content-Length（若有）谨慎截取。
典型误操作：看到第一个 "\r\n\r\n" 就认为 header 结束，但某些邮件客户端会在 header 值里混入换行（折叠 header），导致提前截断。RFC 5322 允许 header 折叠，即用 "\r\n[ \t]" 续行。
- header 解析必须支持折叠：读行时检测
"\r\n "或"\r\n\t"，将其前一行末尾空格合并后继续追加 - 空行判定要严格：只认
"\r\n\r\n"或"\n\n"（normalize 后统一为前者） - body 长度不能依赖内存中剩余长度——得看
Content-Length头，若无，则一直读到下一个合法分隔符（注意：该分隔符必须独占一行，前后无其他字符）
如何解码 base64 / quoted-printable 编码的附件内容
Content-Transfer-Encoding 常见值是 "base64"、"quoted-printable"、"7bit"。C++ 标准库不提供 base64 解码，需手写或引入轻量实现；quoted-printable 更麻烦——"=XX" 是十六进制字节，"="\r\n" 是软换行，且等号本身可出现在行尾表示续行。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
容易被忽略的点：base64 数据常含换行（每 76 字符一个 "\r\n"），解码前必须先移除所有空白字符（仅限 ASCII 空格、\t、\r、\n），但不能简单 erase(remove_if)——会破坏二进制边界（比如某段末尾恰好是 '='，后面紧跟换行，删掉换行可能导致 padding 错位）。
- base64 解码优先用已验证的 snippet（如 Boost.Beast 的
beast::detail::base64_decode或 cppcodec）；自己写务必处理 padding（"=="或"="）和非法字符跳过逻辑 - quoted-printable 解码必须逐行处理：遇到
"=\r\n"直接丢弃整行连接；遇到"=XX"转为字节；遇到单个"="在行尾外位置视为错误或透传（部分老邮件会这样） - 永远以
Content-Type的name或filename参数作为附件原始文件名，而非猜测扩展名
如何处理嵌套 multipart（如 multipart/alternative + multipart/mixed）
邮件正文常嵌套多层：外层 multipart/mixed，内含一个 multipart/alternative（含 text/plain + text/html），再套一个 multipart/related（HTML 引用图片）。递归解析时最易崩溃的是深度失控和循环引用（虽罕见，但恶意构造报文可能触发）。
关键限制不是“能不能递归”，而是“在哪一层停”。RFC 建议默认限制 16 层，但实际中超过 4 层就极可能是异常报文或编码错误。
- 用栈或显式 depth 计数器，每次进入新
multipart/*时depth++，超阈值（如 5）则跳过该 part，记录 warning - 每个子 part 必须重新解析自己的
Content-Type和boundary，不可复用父级 boundary - 不要假设嵌套结构——
multipart/signed或multipart/encrypted的 body 不是普通 MIME，需调用对应密码学接口，此时应停止解析并移交上层处理
真正棘手的从来不是语法解析，而是 malformed boundary（比如含控制字符）、header 值未转义的双引号、body 中意外出现的 --boundary 字符串——这些都需要 fallback 机制：当严格模式切分失败时，降级为“找最近的疑似分隔符 + 回溯检查 header 格式”策略。没有银弹，只有层层防御。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
