mailto协议不发送邮件，仅调用默认邮件客户端并预填字段；需严格url编码参数，支持to/cc/bcc/subject/body，多收件人用英文逗号分隔，不支持附件与自动发送。
mailto: 协议本身不发邮件，只是告诉浏览器“请调用系统默认邮件客户端，并预填字段”。它不经过服务器、不校验邮箱有效性、也不反馈是否真的发送成功——这点必须一开始就明确。
mailto 链接的正确写法与参数格式
最简形式是 href="mailto:support@example.com"，但只要加参数，就必须严格遵循 URL 查询字符串规则：第一个参数用 ? 开头，后续用 & 连接，且所有非 ASCII 字符（中文、空格、换行、标点）必须 encodeURIComponent() 编码。
常见错误包括：
- 直接拼接中文 subject 或 body，导致链接被截断或客户端解析失败
- 误用
+代替%20表示空格（+是表单application/x-www-form-urlencoded的规则，mailto不认） - body 中换行用
\n而不是%0D%0A（CR+LF），部分客户端（如 Outlook）会忽略纯\n
正确示例（TypeScript 中构造）：
const email = 'support@example.com';
const subject = encodeURIComponent('咨询订单 #12345');
const body = encodeURIComponent('客户姓名：张三\n订单状态：待发货\n联系方式：138****1234');
const mailtoLink = `mailto:${email}?subject=${subject}&body=${body}`;
多个收件人、抄送与密送的写法差异
to 参数其实可以省略，直接把邮箱写在 mailto: 后面；但 cc 和 bcc 必须显式声明，且多个地址之间用英文逗号 , 分隔（不是分号，不是顿号）。
注意点：
- 收件人列表过长（比如超过 5 个）时，某些邮件客户端（尤其是移动端 Mail app）可能只识别第一个
-
bcc在部分旧版 Outlook 中不生效，建议优先用cc或服务端发送 - 不要在
mailto:中混用to=xxx和路径后直接写邮箱，例如mailto:?to=a@b.com&to=c@d.com是无效的，应写成mailto:a@b.com,c@d.com
为什么用 <a></a> 标签而不用 form + action="mailto:"
虽然 HTML 规范允许 <form action="mailto:..."></form>，但实际中问题更多：
-
enctype="text/plain"会导致字段名和值以name=value形式平铺进 body，格式丑陋、不可控，且无法插入换行或结构化内容 - 表单提交会刷新页面（即使 target="_blank"），中断用户当前操作流
- 无法动态构造内容——表单字段名是静态的，不能根据 JS 计算结果实时生成 subject 或 body
所以更可控的做法是：用 JS 拼好完整 mailto: 链接，再绑定到一个 <a href="javascript:void(0)"></a> 上，点击时设置 location.href 或创建临时 <a></a> 并 .click()。
容易被忽略的兼容性与体验细节
看似简单，但真实项目里常踩的坑集中在这些地方：
- Mac 上 Safari 对长
body（超 2000 字符）可能截断，iOS Mail 则更敏感，建议控制在 1000 字以内 - 没有默认邮件客户端的设备（如某些 Chromebook、无 Outlook 的 Windows 纯浏览器环境）点开会报错或静默失败，无法捕获异常
- 用户可能用 Webmail（Gmail、Outlook Web）作为默认“邮件程序”，此时
mailto:会跳转到网页版，但新版 Gmail 已限制自动填充body，只保留to和subject - 如果页面本身是 HTTPS，而用户本地邮件客户端不支持安全上下文调用，极少数情况下会触发警告（虽少见，但测试时得覆盖）
真正上线前，至少要在 Windows（Outlook）、macOS（Mail）、iOS（Mail）、Chromebook（Gmail Web）上各点一次，看预填内容是否完整、换行是否生效、中文是否乱码——截图比文档管用。
