如何修改JS代码解决Gmail嵌套MIME结构下PDF附件获取的无限循环问题

问题分析 #

当前代码在处理嵌套MIME结构的邮件时，会错误选中带有子parts的application/pdf容器部分（该部分虽标记为PDF且带有attachmentId，但实际是包裹其他内容的容器），导致后续无法正确获取有效PDF附件数据，影响递归逻辑的正确性。

修改方案 #

需要调整findPdfPart函数的判断逻辑，确保只返回叶子节点的PDF附件（即没有子parts、同时满足MIME类型和attachmentId条件的部分）：

修改后的代码片段 #

// Function to find PDF part in message structure
function findPdfPart(part) {
    // 优先遍历子parts，先查找嵌套结构深层的附件
    if (part.parts) {
        for (const subpart of part.parts) {
            const found = findPdfPart(subpart);
            if (found) return found;
        }
    }
    
    // 子parts中未找到时，再检查当前part是否为符合条件的叶子节点附件
    if (part.mimeType === 'application/pdf' && part.body && part.body.attachmentId && !part.parts) {
        return part;
    }
    
    return null;
}

修改说明 #

• 调整递归顺序：先遍历当前part的子parts，优先获取嵌套结构深层的附件，避免误选顶层的容器部分。
• 增加叶子节点校验：在原有MIME类型和attachmentId的判断基础上，添加!part.parts条件，确保返回的是无嵌套子部分的真实附件节点，排除仅作为容器的PDF标记部分。

若遇到极少数特殊邮件（带有子parts的PDF部分确实为有效附件），可移除!part.parts条件，但保留先遍历子parts的逻辑，确保优先获取最底层的附件内容。

内容的提问来源于stack exchange，提问作者Eswar