为何校验有效的schema json-ld邮件在Gmail中仅显示为普通消息

• 结构化数据类型无对应渲染逻辑：你嵌入的Person类型JSON-LD是Schema体系的通用基础示例，完全不在Gmail支持特殊渲染的结构化数据类型范围内。Gmail仅对绑定明确事务场景的专属类型做装饰渲染，比如快递状态、航班动态、行程预约、账单收据、活动邀约类的结构化数据，通用基础类的Schema本身就没有匹配的展示模板，就算内容合规也不会出特殊效果。
• 内嵌脚本位置不符合解析规则：当前测试报文里的application/ld+json块直接放在正文Body区域的<p>标签内，Gmail的安全净化机制会自动剥离正文区域内嵌的所有脚本类内容，仅识别放置在HTML文档<head>标签内部的同类型结构化数据。你能通过Schema校验工具的验证，是因为手动抓取了原始报文里的JSON内容，实际客户端接收时，正文区的这段脚本已经在净化环节被过滤，根本没有进入结构化识别流程。
• 邮件编码不符合解析要求：整封邮件的HTML部分采用iso-8859-15字符编码，Gmail的结构化解析管线仅对采用UTF-8编码的邮件内容做扫描，非UTF-8编码的邮件会被默认标记为低可信内容，直接跳过结构化数据识别环节。
• 测试场景触发机制不匹配：本次测试从同一个Gmail账号发件、收件，Gmail会将这类自发自收的邮件判定为用户自行留存的便签类内容，不会走正式的入站邮件结构化解析、渲染流程，哪怕内容完全合规也不会加载特殊展示样式。
• 发件人资质未达到渲染门槛：普通个人Gmail账号发送的邮件，就算使用了合规的可渲染类型结构化数据，也不会触发特殊渲染。Gmail的结构化邮件装饰功能，要求发件人所属域名完成全链路邮件可信认证（SPF、DKIM、DMARC配置全部达标），且域名所有者提前在Google服务后台完成了结构化邮件功能的注册，未备案的发件来源会被默认跳过结构化内容渲染。
• 测试客户端的功能限制：Gmail的结构化装饰渲染仅在官方网页端、官方安卓/iOS客户端生效，第三方邮件客户端（如本次测试用的Thunderbird）本身不具备Gmail端的原生结构化渲染逻辑，就算邮件内容完全合规，第三方客户端也只会以普通邮件形式展示。
• 扫描时效影响：Gmail对结构化邮件的识别不是实时触发的，全新的发件来源需要经过数小时到1天的系统扫描周期，才会触发生效对应的渲染样式，刚收到的测试邮件就算所有条件达标，也不会立刻显示装饰效果。

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