浏览器无硬件解码能力选择api，play()不感知解码路径；适配依赖格式选型（mp4/h.264优先）、profile/level校验、mse可控干预及外部监控手段判断硬解是否生效。
浏览器不提供“根据硬件解码能力选择播放函数”的 API，play() 本身无感知、无适配逻辑；所谓“适配”，其实是通过格式选型、加载策略和 fallback 控制，让浏览器更大概率走硬解路径。
video.src 赋值前必须校验编码格式与 profile
硬解是否启用，第一步就卡在视频源是否被系统级解码器支持。Chrome 在 Windows 上对 H.264 的 Main Profile Level 4.0 以下基本全硬解，但若你给的是 H.265/HEVC Main 10@L5.1，Intel 第 10 代以前核显会静默回落软解——play() 完全不知情。
- 优先用
<source></source>按兼容性从高到低排列：mp4（H.264 + AAC）→webm（VP9）→ 不要放mkv或mov - 避免用 FFmpeg 盲转：把 ProRes 录制的 MOV 直接转 MP4 但保留
Apple ProRes视频轨，浏览器仍会报MEDIA_ERR_SRC_NOT_SUPPORTED - 用
ffprobe -v quiet -show_entries stream=codec_name,width,height,profile,level video.mp4验证关键字段，特别是profile和level
不要依赖 play().catch() 捕获硬解失败
play() 报错只反映播放触发失败（如策略拦截、无 src），不反映解码路径。硬解失败时浏览器通常静默降级为软解，画面照播，只是 CPU 占用飙升——你根本收不到错误。
- 真要判断硬解是否生效，得靠外部手段：
chrome://media-internals里查video_decoder_name是否含hardware_accelerated: true - Windows 下看任务管理器 → GPU → “Decoder” 使用率；macOS 看 Activity Monitor 里
VideoProc进程；Linux 跑vainfo确认 VAAPI 就绪 - 别在
play().then()里写“硬解成功”日志——它只表示播放已启动，跟解码方式无关
自定义播放器中 MSE 是唯一可控入口
原生 <video></video> 对硬解完全黑盒，但用 MediaSource + SourceBuffer（即 MSE）可间接影响：部分浏览器（如 Chrome）对 MSE 加载的 avc1.640028（H.264 High Profile Level 4.0）更倾向启用硬解，而直接 src 赋值同规格文件反而可能软解。
- 仅当需动态切换清晰度或做 DRM 时才上 MSE；普通单文件播放没必要绕路
- 使用
hls.js或dashjs时，它们内部已封装 MSE，但硬解与否仍取决于分片编码参数，不是库本身决定的 - MSE 初始化后调用
video.play()，依然受自动播放策略限制，该静音还得静音，该手势触发还得手势触发
真正容易被忽略的点是：硬解能力不是布尔开关，而是连续光谱。同一台机器播 1080p H.264 可能硬解，换成 4K AV1 就软解；同一个 MP4 文件，在 Chrome 里硬解，在 Safari 里可能因 HEVC 支持差异直接拒播。所有“适配”动作，本质都是在向浏览器的媒体管道提交一份它大概率能硬件处理的作业，而不是命令它“必须硬解”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
