本文详解在使用Python smtplib + MIMEText 发送HTML邮件时，为何将纯文本中的 \n 机械替换为 会导致 Outlook 渲染出意外的额外空行，并提供符合邮件客户端兼容规范的正确实践方案。
本文详解在使用python `smtplib` + `mimetext` 发送html邮件时，为何将纯文本中的 `\n` 机械替换为 `
` 会导致 outlook 渲染出意外的额外空行，并提供符合邮件客户端兼容规范的正确实践方案。
在构建自动化报告类HTML邮件（如数据表格通知）时，开发者常误以为“纯文本 → HTML”只需简单替换 \n 为 <br> 即可。但正如问题所示：当原始字符串含多处连续换行（如 "\n\n\n\n"），再统一替换成 <br><br><br><br> 后，Outlook（尤其是 Classic Outlook）会将其渲染为多个不可见的、高度叠加的空行——这正是“Title1 表格底部出现额外空白”的根本原因。
关键在于：HTML邮件不是网页，其换行语义与CSS盒模型行为严重受限。Outlook（基于MSHTML/Word渲染引擎）对 <br> 的处理极为敏感，尤其在 <font></font> 等内联容器中，连续 <br> 会被解析为多个独立换行符，而不会像现代浏览器那样合并或压缩。更隐蔽的问题是：原始Python字符串中隐含的 \n 可能来自模板拼接、print调试残留或数组格式化逻辑（如 f"{'Title1':=^60}\n" 中的 \n），这些换行在纯文本邮件中无害，但在HTML中却成为布局干扰源。
✅ 正确做法：放弃 \n → <br> 的暴力替换，改用语义化HTML结构
# ✅ 推荐：用 <pre class="brush:php;toolbar:false;"> 保留等宽格式 + CSS控制空白处理
html = f"""
<html>
<head>
<meta charset="UTF-8">
<style>
pre {{
font-family: 'Courier New', monospace;
white-space: pre; /* 严格保留空格与换行 */
margin: 0;
padding: 0;
}}
</style>
</head>
<body>
<pre class="brush:php;toolbar:false;">{text}
