真正落地的兼容方案必须用<source>多格式兜底+明确type声明+iOS/Android的JS补丁；单src或省略type会导致Safari/iOS黑屏、canplay不触发、duration为NaN。
video 和 audio 是 HTML 中唯二真正能直接播放音视频的原生标签，其他如 source、track 必须嵌套其中才生效。只写 video 或 audio 标签加 src 属性，在 Safari（尤其 iOS）、旧版 Android WebView 上大概率黑屏或静默失败。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
为什么 source 总是不加载？
浏览器按顺序解析 source，遇到第一个 type 匹配且 HTTP 状态码为 200 的资源就停用后续所有 source；其余全部跳过。
-
type值必须与服务器实际返回的Content-Type完全一致：写audio/mp3但服务端发audio/mpeg，Safari 直接忽略该source -
src返回 404 或跨域被拦，浏览器不报错，只在 Network 面板里能看到状态码 -
source写在video或audio外部，或放在controls属性之后（必须紧贴开始标签后、结束标签前）
video 和 audio 的 autoplay 为什么经常失效？
autoplay 不是“写了就播”，而是“写了 + 满足策略 + 用户无交互时才可能播”。
- Chrome、Firefox、Safari 全部要求同时存在
muted才允许静音自动播放 - iOS Safari 还额外要求页面已获得用户手势授权（比如用户点过任意区域），否则即使
autoplay muted也静默失败 - 有声自动播放基本不可行，放弃
autoplay无muted的组合 - 如需有声播放，只能等用户首次交互后调用
play()，且必须处理 Promise 拒绝：video.play().catch(e => console.warn('play rejected:', e))
多格式兜底为什么不能省略 type？
浏览器不会解包判断 MP4 是否含 H.264 编码，也不会猜 MP3 文件是否带 AAC 封装。它只按 type 做 MIME 类型匹配。
- 省略
type时，Chrome 可能碰巧加载成功，但 Safari（尤其 iOS）直接跳过该source，导致canplay不触发、duration为NaN -
audio推荐写type="audio/mpeg"（不是audio/mp3），video推荐双源：<source src="v.mp4" type="video/mp4"></source><source src="v.webm" type="video/webm"></source> - 多个
source但没写type，浏览器会逐个发起 404 请求，直到超时
iOS 和 Android 在 currentTime 设置上的关键差异
iOS WebKit 对生命周期控制极严：未触发 canplay 前设置 currentTime 无效；loadstart 和 loadeddata 触发不稳定。Android（尤其低版本 WebView）压根不抛 canplay，但 play 事件相对可靠。
- 设置播放位置必须分平台：iOS 等
canplay事件后再设currentTime；Android 可直接设currentTime后调play() - 监听播放完成别只靠
ended，iOS 下有时不触发，建议结合timeupdate+ 判断currentTime >= duration - 0.1
真正落地的兼容方案，从来不是堆属性，而是：每个 source 带严格匹配的 type、autoplay muted 仅作静音兜底、用户交互后才尝试有声播放、平台差异逻辑必须显式分离。这些细节漏掉任何一个，都可能让播放器在某个设备上彻底空白。
