浏览器不提供直接发送短信的api，是出于安全、隐私、跨平台兼容性和用户体验的考虑。1. 安全与隐私风险：恶意网站可能滥用该功能发送垃圾短信或窃取联系人信息；2. 跨平台差异大：不同系统短信机制不统一，难以标准化；3. 用户控制权缺失：自动发送会剥夺用户对操作的确认权。实际做法是使用 sms: uri scheme 触发设备原生短信应用预填内容，如通过 标签或 javascript 设置 window.location.href 实现点击跳转，但需用户手动发送且无法获取发送状态。此外，web share api 可间接实现内容分享至短信应用，而真正发送短信通常依赖服务器端调用第三方短信服务api完成。使用 sms: uri 时常见限制包括兼容性差异、内容长度与编码问题、无法获知发送结果、仅支持单一收件人及桌面端无响应等。
说实话，在浏览器里直接通过BOM（Browser Object Model）来“操作”短信API，这事儿本身就有点误解。因为出于安全和隐私的考虑，现代浏览器是不会提供一个让你直接从网页端发送短信的API的。想象一下，如果真有这样的API，那各种垃圾短信、钓鱼信息岂不是满天飞了？这绝对是浏览器厂商和用户都无法接受的。
所以，我们通常说的在网页中与短信功能交互，其实是利用了URI Scheme，也就是通过特定的链接格式，来引导用户的设备打开其原生的短信应用，并预填充好收件人或内容。这并不是真正意义上的“编程发送”，更像是一种“意图触发”。
解决方案
要实现这种“触发”效果，最直接、最广泛支持的方式就是使用 sms: URI Scheme。这有点像 mailto: 链接用于邮件一样。
发送短信给指定号码
当用户点击这个链接时，如果他们的设备支持 sms: 协议（几乎所有智能手机都支持），就会自动打开设备的短信应用，收件人会被预填充为 +1234567890，短信内容则会预填充为 你好，这是一个测试短信。。用户只需要点击发送按钮即可。
如果你想通过 JavaScript 动态地触发这个行为，可以使用 window.location.href：
// 假设你有一些逻辑来获取电话号码和短信内容
const phoneNumber = '+9876543210';
const messageBody = '这是通过JavaScript触发的短信。';
// 注意：URL编码很重要，特别是当短信内容包含特殊字符时
const encodedMessageBody = encodeURIComponent(messageBody);
// 构造完整的URI
const smsUri = `sms:${phoneNumber}?body=${encodedMessageBody}`;
// 触发跳转
window.location.href = smsUri;
// 实际应用中，你可能把它放在一个事件监听器里
// document.getElementById('sendSmsButton').addEventListener('click', () => {
// window.location.href = smsUri;
// });这种方法的核心在于，它始终需要用户的明确干预——用户必须手动点击发送按钮来完成短信的发送。网页本身无法知道短信是否真的被发送了，也没有任何回调机制来获取发送状态。这是一种设计上的必然，为了保护用户。
为什么浏览器不直接提供发送短信的API？
这问题问得挺好的，也是很多人初次接触时会有的疑问。在我看来，主要原因有这么几点，而且都是硬性门槛：
首先，是安全和隐私的巨大风险。试想一下，如果一个恶意网站能够不经用户同意就直接发送短信，那会发生什么？你的手机可能会被用来发送垃圾广告、诈骗信息，甚至通过高额短信费让你蒙受经济损失。更糟糕的是，如果它能访问你的联系人列表，那隐私泄露就更严重了。浏览器作为用户与互联网交互的门户，其核心职责之一就是保护用户的安全和隐私，这种直接的API显然与此原则相悖。
其次，跨平台和设备差异性。短信功能在不同的操作系统（iOS、Android、Windows Phone等）和设备上的实现方式差异很大。浏览器API通常追求的是标准化和跨平台一致性。要设计一个能完美兼容所有这些底层差异的短信发送API，其复杂度和维护成本都会非常高，而且很可能无法提供一致的用户体验。
再者，用户体验的不可控性。如果网页能直接发送短信，用户可能会频繁收到来自各种网站的未经授权的短信，这会严重破坏用户的上网体验。浏览器设计哲学中很重要的一点就是给予用户控制权，而直接发送短信显然剥夺了这种控制。
所以，与其说浏览器“不提供”，不如说它是“故意不提供”，这是深思熟虑后的结果。它把最终的控制权交给了用户，通过触发原生应用的方式，让用户在发送前有最终的确认机会。
除了URI方案，还有其他在网页中与短信交互的方式吗？
除了我们上面提到的 sms: URI方案，如果你的目标是真正的“发送”短信，而不是仅仅触发用户操作，那么在纯前端的浏览器环境中，答案基本上是“没有”。但如果我们把视野放宽一点，考虑到整个Web应用生态，还是有一些间接或更高级的方案：
一个值得提的是 Web Share API。虽然它不是专门用来发送短信的，但它允许Web应用程序调用操作系统提供的共享功能。这意味着你可以通过这个API，让用户选择将一段文本分享到他们设备上的任何应用，包括短信应用。这比 sms: URI更灵活，因为它不强制用户使用短信，而是提供了一个选择列表。
// 检查浏览器是否支持Web Share API
if (navigator.share) {
document.getElementById('shareSmsButton').addEventListener('click', async () => {
try {
await navigator.share({
title: '分享一个消息',
text: '这是我想分享给你的内容。',
// url: 'https://example.com' // 也可以分享一个URL
});
console.log('内容已尝试分享');
} catch (error) {
console.error('分享失败:', error);
}
});
} else {
console.log('Web Share API 不受支持，请使用 sms: URI 方案。');
}这依然是用户触发的分享行为，不是自动发送。
另一个重要的，但这不是BOM范畴内的，是通过服务器端API发送短信。这才是目前绝大多数Web应用实现短信通知、验证码等功能的标准做法。你前端页面通过 AJAX 请求把需要发送短信的信息（比如手机号、内容）发送到你的后端服务器，然后后端服务器调用第三方短信服务提供商（比如 Twilio、Nexmo、阿里云短信、腾讯云短信等）的API来发送短信。这种方式完全绕过了浏览器端的限制，因为短信的发送动作是在你的服务器上完成的，服务器有权限与外部服务进行通信。这虽然不是“BOM中操作”，但却是实际项目中解决“网页发送短信”需求的主要途径。
至于浏览器内部，一些非常实验性的API或者特定平台的Web应用可能会有更深度的集成，比如某些PWA（Progressive Web Apps）在特定操作系统上可能会获得一些额外的能力，但这通常需要用户明确的安装和授权，并且兼容性远不如URI方案。所以，对于大多数通用Web开发而言，直接操作短信API是不现实的。
使用短信URI方案时，有哪些常见的兼容性问题和限制？
尽管 sms: URI方案是目前最靠谱的浏览器端触发短信的方式，但它也并非完美无缺，有一些坑和限制是需要注意的：
首先，兼容性差异。虽然基本功能各家都支持，但在细节上，不同操作系统（iOS、Android）和不同版本的短信应用对 sms: URI的处理可能会有细微差异。例如，&body= 参数在某些旧设备或特定短信应用中可能不支持，或者对内容长度有限制。有些系统可能对 ? 和 & 的解析更严格。
其次，预填充内容的长度限制和编码问题。短信内容 body 的长度通常是有限制的，太长的内容可能会被截断。更常见的问题是字符编码。虽然 encodeURIComponent 是标准做法，但如果短信内容包含一些特殊字符（比如表情符号、生僻字），在某些设备或短信应用中可能会出现乱码。测试时需要覆盖多种场景。
再者，无法获取发送状态。这是最核心的限制。一旦你触发了 sms: URI，控制权就完全交给了操作系统。你的网页无法知道用户是否真的打开了短信应用，是否成功发送了短信，甚至用户可能直接取消了发送。这意味着你不能依赖这种方式来做任何需要确认发送结果的业务逻辑。
还有，收件人数量的限制。sms: URI通常只支持一个收件人。如果你尝试用逗号或分号分隔多个号码，在某些系统上可能只会识别第一个，或者干脆报错。要发送给多个人，用户需要在短信应用里手动添加。
最后，桌面浏览器的行为。在桌面浏览器上点击 sms: 链接，通常不会有任何反应，或者会提示“无法打开此类型的链接”。这是因为桌面操作系统通常没有内置的短信应用（或者集成度不高），所以这种功能主要针对移动设备。如果你在桌面端也提供了这个功能，最好能有相应的提示或备用方案。
所以，在使用 sms: URI时，要清楚它的定位：它是一个方便用户快速跳转到短信应用的工具，而不是一个可以编程控制短信发送的API。在设计用户体验时，要考虑到这些限制，并提供清晰的指引。
