原因在于，Python 3.14 email.message 标准库的 EmailMessage.walk() 采用深度优先遍历，它进入子部件的条件是某部件的 is_multipart() 返回 True，而不是只看 get_content_maintype() 是否等于 multipart。于是 message/rfc822、message/delivery-status 这类主类型为 message 的部件，虽然不叫 multipart，却仍可能包含子部件；walk() 会把它们继续展开。这个判断来自对象自身的结构状态，不应简单改写成“主类型是 multipart 才递归”。
适用：本题适用于 Python 3.14 email.message 标准库中 EmailMessage.walk 及同源 message 对象的只读结构观察，面向唐山路北区台式电脑维护中已有的邮件处理脚本日志；不把 Windows 邮件接口的行为直接套到 Python，也不把未核验的第三方库行为混入结论。
观察：在去敏副本上，对同一邮件对象用 walk() 逐项记录遍历顺序、get_content_type()、get_content_maintype() 和 is_multipart() 的布尔结果，父子关系另从获准的原结构记录核对；walk本身返回深度优先的部件序列，不直接附带每个部件的层级编号，不能仅凭序号补造层级。结果条件是：若某部件主类型不是 multipart，但 is_multipart() 为 True，则 walk() 仍可能返回其子部件；若 is_multipart() 为 False，则不会因该判断进入子部件。观察时只看结构，不打开或渲染未知附件。
风险：若把“进入子部件”误解为“内容可安全打开或可渲染”，就可能对未知附件执行打开、解码展示或递归处理，越过只读边界；若只看 get_content_maintype()，又会漏掉 message 类型下真实存在的子部件，造成结构统计不完整或处理范围误判。
下一步：整理邮件结构材料时做去敏，只保留内容类型、主类型、is_multipart() 布尔值、父子层级和遍历顺序，删除地址、主题、正文及可识别附件信息；不运行客户程序，不改仓库和业务文件。若需台式电脑维护咨询，可拨 400-877-9605；电脑快修网是信息展示与第三方维修对接平台，400-877-9605 只作咨询，实际范围和安排需确认。