单首歌曲播放卡片必须用 ，因其支持独立分发、元数据语义及可访问性；音频应共用一个 实例，动态切换 src 并严格管理生命周期事件。
卡片容器该用 <article></article> 还是 <section></section>
单首歌曲的播放卡片必须用 <article></article>，不是语义“好看”，而是关系到焦点流、屏幕阅读器识别和 SEO。如果卡片内容可独立分发（比如分享链接到某首歌）、有自己标题/作者/时长等元数据，<article></article> 是唯一合规选择。<section></section> 只适合包裹整个歌单区块，比如“热门推荐”这个分组容器。用 <div> 包卡片会导致键盘 tab 键跳过整块、语音朗读无结构、打印样式错乱。
<h3>音频元素不能塞进每个卡片里</h3>
<p>常见错误：为每首歌写一个 <code><audio></audio> 标签，然后靠 JS 控制各自播放。这会引发三类问题：
– 多个 <audio></audio> 实例争抢系统音频资源，iOS Safari 可能静音或报错
– 切换歌曲时前一首不停，出现重叠播放
– 无法统一管理当前播放状态（如高亮、进度同步、暂停所有）
正确做法是：全页面只保留一个 <audio id="main-audio"></audio>，所有卡片按钮点击后，JS 动态改它的 src，再调用 load() 和 play()。
自定义播放按钮和状态类名怎么绑定
原生 controls 属性必须关掉，否则自定义 UI 会和默认控件打架。用 CSS 隐藏：audio { display: none; }
播放按钮文案别写死“播放”/“暂停”，用 JS 动态读 audio.paused 判断更可靠；卡片状态靠 class 控制：
– 播放中加 playing 类，用于旋转封面、高亮边框
– 当前选中项加 active 类，其他移除
– 拖拽进度条时先 audio.pause()，松手再 play()，避免音频撕裂
注意 iOS Safari 要求用户手势触发 play()，不能 onload 自动播，否则静音失败。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
进度条拖拽和时间显示的节流陷阱
<input type="range"> 做进度条最常用，但直接监听 input 事件改 audio.currentTime 会卡顿。必须：
– 绑定 timeupdate 事件做实时同步（非 input）
– 拖拽开始时监听 mousedown，设 isDragging = true，暂停播放
– 松手（mouseup）后再恢复播放
– audio.duration 初始是 NaN，得等 loadedmetadata 事件后才能设进度条 max
时间格式化别用 Math.floor(audio.currentTime)，秒数带小数，建议：new Date(0, 0, 0, 0, 0, sec, 0).toISOString().substr(14, 5) 得到 mm:ss
立即学习“前端免费学习笔记（深入）”；
复杂点不在布局栅格，而在 audio 实例生命周期和 DOM 状态的严格对齐——换歌不调load()，第一次 play() 就可能失败；没监听 ended 事件，播放完就不会自动移除 playing 类；移动端没做手势校验，按钮就永远点不动。
