mailto: 在反馈场景下基本不可用，因其依赖本地邮件客户端、长度限制严、无法校验防注入、无日志记录且移动端支持差；真要收反馈必须走后端接口。
纯前端 HTML 表单发不出反馈邮件——mailto: 是个幻觉，别信。 它依赖用户本地邮件客户端，Outlook 可能弹窗卡死，Gmail App 会直接报错，iOS Mail 常丢字段，且完全无法校验、防注入、记录日志。真要收反馈，必须走后端接口（哪怕只有一行云函数）。
为什么 mailto: 在反馈场景下基本不可用
这不是兼容性问题，是设计缺陷：
-
mailto:feedback@example.com?subject=反馈&body=内容中的body参数长度被严格限制（通常 ≤ 2KB），长反馈直接截断 - 用户没装邮件客户端？点击即失败；装了但设为默认？可能弹出陌生界面吓退用户
- 无法获取提交时间、IP、UA、Referer，你连“谁在什么时候提了什么”都查不到
-
subject和body不做 URL 编码就拼接，空格、换行、中文全乱码；做了编码又容易被某些客户端二次解码出错 - 移动端 Safari / Chrome 对
mailto:支持极差，常静默失败，用户以为点过了，其实啥都没发出去
真正可用的反馈邮件模板：HTML 邮件体怎么写才不翻车
你发给用户的“已收到反馈”或“处理中”通知邮件，才是 HTML 模板的主战场。这类邮件必须适配 Outlook、Gmail、Apple Mail、QQ 邮箱等——不是“看起来像网页”，而是“在每个客户端里都按你写的渲染”。
- Doctype 必须用
，HTML5 的 <code> 会被 Gmail 强制替换，还可能触发 Outlook 的怪异渲染模式 - 所有样式必须内联：
<td style="font-family: 'Helvetica Neue', Arial, sans-serif; font-size: 14px; line-height: 1.5em;"> —— <code><style></style>标签里的规则，90% 客户端会删掉或忽略 - 布局只用
<table>：<code><div> 和 <code><p></p>可以存在，但必须包在<td> 里；嵌套超过 4 层 <code><table> 时，部分 Android 邮箱会错位 <li>图片必须带 <code>width/height属性和alt文本，URL 用 HTTPS 绝对路径；否则 QQ 邮箱默认屏蔽，Outlook 显示“X”占位符 - 按钮不能靠
@#@#@#@#@#@#@#@#@#@0 - 密钥绝不能写死在前端代码或 HTML 模板里；必须存在环境变量中，由云函数（Vercel/Netlify）或服务器读取
- 前端提交的数据必须双重校验：前端用
required和type="email"做基础拦截，后端再用正则 + 长度 + 黑名单关键词（如Content-Type:、MIME-Version:）过滤注入 - 不要直接把用户填的
subject当邮件主题——它可能含恶意头字段；应固定主题如"【用户反馈】来自 ${domain} 的新消息"，把原始输入仅作为正文一部分 - 建议加简单限流：同一 IP 10 分钟内最多提交 3 次，防脚本刷屏；用 Redis 或内存缓存实现即可，不用上复杂方案
- 发信失败时，后端返回明确错误（如
{ error: "email_service_unavailable" }），前端提示“提交失败，请稍后重试”，而不是暴露 SMTP 错误细节
后端发信接口怎么接才不暴露密钥
你前端 POST 到 /api/submit-feedback，后端再调 SendGrid / Resend / SMTP 发邮件。关键不是“怎么发”，而是“怎么安全地发”：
最易被忽略的一点：邮件模板里所有文字颜色、字体、行高，都得手写进每个 <td> 或 <code><p></p> 的 style 属性里——没人会帮你继承父级样式，也没人会加载你的 CSS 文件。
