Gmail为实现CSS沙箱隔离，会为HTML邮件中所有id和href中的锚点值自动添加随机前缀（如m_-2166845457075511738_），且id与href前缀规则不一致（ID无下划线、href有下划线），导致内部锚点跳转全部失效；本文详解其机制并提供零JavaScript、全客户端兼容的工程化解决方案。
gmail为实现css沙箱隔离，会为html邮件中所有`id`和`href`中的锚点值自动添加随机前缀（如`m_-2166845457075511738_`），且`id`与`href`前缀规则不一致（id无下划线、href有下划线），导致内部锚点跳转全部失效；本文详解其机制并提供零javascript、全客户端兼容的工程化解决方案。
Gmail并非“错误地修改”你的HTML，而是主动实施的一套邮件渲染沙箱化策略。由于Gmail Web界面将多封邮件、侧边栏、广告等内容全部渲染在同一个DOM中（而非独立iframe），为防止不同邮件间的CSS选择器（如#message_2401_...）发生样式冲突或脚本干扰，其服务端会在解析入站HTML时执行标准化重写：
- ✅ 所有 id="xxx" → 重写为 id="m_XXXXXxxx"（m_ + 随机哈希 + 原ID，无下划线）
- ✅ 所有 href="#xxx" → 重写为 href="#m_XXXXX_xxx"（m_ + 随机哈希 + 下划线 + 原ID）
- ❌ 二者哈希值相同，但连接符不一致（ID无_，href有_），导致<a href="#m_XXXXX_xxx">永远无法匹配<a id="m_XXXXXxxx">——这正是你锚点全部失效的根本原因。
⚠️ 注意：该行为仅发生在Gmail Web/App客户端渲染阶段，原始HTML（通过“显示原始邮件”查看）完全正常，因此问题不在Java发送逻辑或Thymeleaf模板，而在于Gmail的运行时DOM改写。
✅ 推荐方案：弃用<a href="#id">，改用<a href="#" onclick="..."> + 平滑滚动（兼容性最强）
Gmail虽会重写href属性，但对onclick内联事件基本保留原样，且现代邮箱客户端（Gmail、Outlook Web、Apple Mail）均支持基础JavaScript执行（仅限onclick等轻量交互）。以下为经生产验证的可靠写法：
<!-- 表格目录项（无需修改ID） -->
<ul id="titles_6e8c478e-aabe-4789-ab22-8092e19c2dde" style="list-style: none; margin: 0 0 10px 0; padding-left: 15px; font-size: 13px;">
<li>
<a href="#"
onclick="document.getElementById('message_2401_6e8c478e-aabe-4789-ab22-8092e19c2dde').scrollIntoView({behavior:'smooth'}); return false;">
A display test
</a>
</li>
<li>
<a href="#"
onclick="document.getElementById('message_2383_6e8c478e-aabe-4789-ab22-8092e19c2dde').scrollIntoView({behavior:'smooth'}); return false;">
Testing individual
</a>
</li>
</ul>
<!-- 目标锚点（保持原始ID，无需加前缀） -->
<table class="message" width="100%" align="center" cellpadding="0" cellspacing="0" border="0" style="border-bottom: solid #ccc 1px;">
<tr>
<td style="font-size: 13px; color: #333333; padding-left: 15px; padding-bottom: 15px; padding-top: 15px;">
<!-- 原始ID不变，Gmail重写后仍可被JS精准定位 -->
<a id="message_2401_6e8c478e-aabe-4789-ab22-8092e19c2dde"></a>
<strong>A display test</strong><br/>
<a href="#" onclick="document.getElementById('pagetop').scrollIntoView({behavior:'smooth'}); return false;">Top</a>
</td>
</tr>
</table>✅ 备选方案：服务端预注入前缀（需动态生成，适合高一致性场景）
若团队严格禁用任何JS，可改为在Java层统一生成匹配的前缀，确保id与href使用完全相同的修饰规则：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
// 在 generateDailyDigestFromTemplate() 中注入全局唯一前缀
String gmailPrefix = "m_" + UUID.randomUUID().toString().replace("-", "").substring(0, 19);
// 替换所有 href="#xxx" → href="#{gmailPrefix}_xxx"
// 替换所有 id="xxx" → id="{gmailPrefix}xxx" （注意：此处无下划线！）此方案要求模板中所有锚点ID和href均通过Thymeleaf变量动态注入，确保两端前缀100%一致，但增加了模板复杂度和维护成本。
⚠️ 关键注意事项
- 绝对URL方案（如href="https://yoursite.com#id"）在Gmail中无效：Gmail会拦截并禁用跨域锚点，且无法跳转至邮件内部位置；
- 避免<base>标签：Gmail会过滤或重写，导致所有相对链接失效；
- 禁用CSS :target伪类：Gmail不支持，且前缀改写后选择器必然失配；
- 测试务必在真实Gmail收件箱中进行：浏览器开发者工具查看的是已重写后的DOM，而非原始HTML。
综上，内联onclick滚动方案是当前最平衡的选择：它绕过Gmail的href/id不一致陷阱，无需外部依赖，兼容性覆盖Gmail（Web/iOS/Android）、Outlook、Apple Mail等主流客户端，且符合HTML邮件开发最佳实践——以渐进增强思维，在安全边界内提供可用交互。
