网页往手机发消息，网页最直接的发信方式是短信网关。Twilio、手机阿里云短信、网页腾讯云短信都提供HTTP API，发信你在服务器端发一个POST请求，手机运营商的网页网关就把短信推到用户手机上。这个链路稳定、发信到达率高，手机但每条短信要花钱，网页国内大约0.045元一条。发信验证码场景基本都走这条路，手机因为它不依赖用户装任何App。网页

不想花钱也有办法。发信邮件到短信的手机网关曾经流行过一阵，比如美国的号码可以拼成 number@carrier.com 这种格式，发邮件就等于发短信。国内三大运营商早就不开放这个口子了，所以这条路现在基本只在美国有点用。我试过给T-Mobile的网关发邮件，延迟从几秒到几分钟不等，偶尔还会丢，拿来报警不靠谱。

真正在开发者圈子里流行的是推送。网页端用 Notification API 配合 Service Worker，手机端用 Firebase Cloud Messaging（FCM）或者厂商自己的通道。流程是这样的：网页调用后端接口，后端拿着设备token去请求FCM，FCM再通过系统级的长连接把消息塞到手机上。整个过程用户无感，不需要打开浏览器，锁屏也能弹通知。Chrome在安卓上支持得很好，iOS从16.4开始也支持Web Push了，前提是用户把网页添加到主屏幕。

我去年做过一个监控面板，服务器一挂就推送到手机。代码不复杂，前端注册Service Worker拿到endpoint，存到数据库；后端用 web-push 这个npm包，配上VAPID密钥就能发。实测安卓上延迟不到一秒，iPhone上大概两到三秒，偶尔会被系统省电策略压住。这个方案免费，但依赖谷歌的FCM服务，国内安卓机没有谷歌框架就收不到，得换厂商推送或者自己搭长连接。

自己搭长连接是另一条路。WebSocket或者SSE（Server-Sent Events）都能让网页和服务器保持一条常开的通道，服务器有消息直接推过来。但网页一关，连接就断了，手机浏览器在后台也会杀连接。所以纯WebSocket方案只适合网页开着的时候用，比如网页版聊天工具。要想关掉网页还能收，必须借助Service Worker或者原生App。

还有一类取巧的做法：用Telegram Bot、钉钉机器人、企业微信机器人。网页后端往机器人的Webhook发一条消息，机器人再推到你手机上的App。这个方案几乎零成本，配置五分钟搞定，缺点是消息会经过第三方服务器，敏感内容不适合。我自己的服务器报警就走Telegram Bot，稳定用了两年多，比短信便宜，比邮件快。

选哪种，看你的场景。验证码、支付通知这种要求到达率和合规性的，老老实实买短信。内部报警、个人提醒，机器人或者Web Push够用。需要双向通信、实时性高的，WebSocket加原生壳。没有银弹，每种方案都有它适合的边界。