浏览器默认拦截自定义协议链接（如myapp://、weixin://），在click事件触发前就中止跳转，因此click监听器无效；可行拦截点为mousedown/pointerdown或touchstart，并需调用e.preventDefault()阻止默认行为。
为什么 click 事件监听器对自定义协议链接无效
浏览器默认会拦截并终止以 myapp://、weixin:// 等开头的链接跳转，且不触发 click 事件——这是安全策略，不是 bug。你在编辑器里给 <a href="myapp://open?id=123"> 绑 addEventListener('click', ...)，根本收不到事件，因为页面还没来得及响应就被中止了。
真正可行的拦截点只有两个：用户点击前（主动阻止）或链接被拒绝后（被动兜底）。前者靠 mousedown 或 pointerdown，后者靠 beforeunload + 定时检测（不推荐），或更稳妥的 blur + 延迟判断。
-
mousedown比click更早触发，能抢在浏览器拦截前执行逻辑 - 必须调用
e.preventDefault()，否则仍会走默认协议处理流程 - 注意移动端要同时监听
touchstart，iOS Safari 对mousedown支持不稳定
如何用 contenteditable 区域识别并重写自定义协议链接
编辑器若基于 contenteditable，不能依赖 DOM 结构静态扫描 —— 用户可能正在输入中途，<a> 标签尚未闭合，或文本中混有未转义的冒号斜杠（如 “见 myapp://xxx”）。必须结合光标位置与上下文解析。
核心思路是：监听 input 和 selectionchange，在光标附近提取候选字符串，用正则匹配协议模式，再验证是否构成完整可点击单元（比如前后是空白或标点）。
立即学习“前端免费学习笔记（深入）”；
- 推荐正则：
/[a-z][a-z0-9+-.]*://[^\s]+/i，比简单写死myapp://更健壮 - 不要直接替换 DOM，先用
document.execCommand('insertHTML', false, ...)插入带data-protocol属性的封装标签，保留原始文本语义 - 避免高频触发：用
requestIdleCallback或节流（300ms）包裹解析逻辑，否则拖慢打字响应
window.open() 调用自定义协议时为何返回 null 且无错误提示
这是最常踩的坑：window.open('myapp://open?id=123') 在绝大多数现代浏览器中会静默失败，返回 null，控制台也不报错。它不像 HTTP 链接会跳转或弹出新窗口，而是被协议白名单机制直接丢弃。
真正有效的触发方式只有两种：一是原生 <a href="myapp://..."> 点击（经前述 mousedown 拦截后可控重发），二是使用 location.href = 'myapp://...'（但会卸载当前页）。
- 绝对不要依赖
window.open()的返回值做成功判断 —— 它永远不可靠 - 想确认协议是否唤起成功？只能靠客户端回调（如 App 注册
myapp://callback?status=ok）或超时 fallback - Android Chrome 72+ 引入了
navigator.canLaunchUrl()（实验性 API），但兼容性差，仅作参考
编辑器中如何安全降级未安装应用的自定义协议链接
用户点了 myapp:// 却没装 App，浏览器通常卡住几秒后静默失败。你得在超时前主动跳转到下载页或 Web 版入口，但这个“超时”不能拍脑袋定 —— iOS 唤起延迟普遍比 Android 长，且不同 App 启动耗时差异大。
实用方案是双阶段检测：先用 visibilitychange 监听页面是否失焦（说明唤起已发起），再设 2500ms 计时器；若期间页面重新聚焦或计时结束，就执行降级。
- 监听
document.addEventListener('visibilitychange', ...)，document.hidden === true是唤起发生的强信号 - 降级跳转前务必检查
document.hasFocus()，防止重复触发（比如用户切回页面又切走） - 不要用
alert()或弹窗打断流程 —— 移动端会中断唤起，且体验极差
协议转换不是纯前端能闭环的事，关键在于把“唤起尝试”和“失败兜底”的边界划清楚，而不是试图让浏览器替你判断 App 是否存在。
