最稳妥方案是用 JS 控制标签页显隐：通过 data-tab 属性匹配按钮与内容区，首次加载默认激活首个标签；必须添加 tabindex、aria-controls 等无障碍属性；异步加载需防重复请求与状态错乱；移动端滑动仅需基础 touch 事件检测。
用 dataset + click 事件控制标签页显隐最稳妥
纯 CSS 实现（比如用 :target 或 input[type=radio]）在商品详情页容易失控：URL 锚点会干扰页面滚动，单选按钮难以与后端模板或 React/Vue 组件对齐，而且无法响应式更新内容。直接用 JS 控制更可控。
核心思路是给每个标签按钮加 data-tab 属性，对应内容区也加相同值的 data-tab，点击时只显示匹配的内容块，其他隐藏。
- 标签按钮写成
<button type="button" data-tab="desc">商品详情</button> - 内容区用
<div data-tab="desc">...</div>，初始加style="display: none"或统一用类名控制 - 监听按钮
click，用event.target.dataset.tab取目标 tab 名，再用querySelectorAll('[data-tab]')批量切换显隐 - 记得首次加载时默认激活第一个标签，否则页面空白
tabindex 和 aria-controls 不是可选项，是电商无障碍刚需
很多开发只让标签“能点”，但忽略屏幕阅读器用户——他们靠键盘 Tab 切换焦点，靠 Enter 触发。没加 tabindex="0" 的 div 或 span 标签根本无法聚焦；没配 aria-controls，读屏软件不知道这个按钮控制哪块内容。
- 每个标签按钮必须是可聚焦元素：
<button tabindex="0" aria-controls="tab-desc"></button> - 对应内容区加
id="tab-desc"，且设role="tabpanel"和aria-labelledby="对应按钮ID" - 激活态要同步更新
aria-selected="true"和aria-hidden="false"，未激活的设为false - 别用
display: none隐藏非活跃面板——它会让读屏器彻底忽略内容；改用visibility: hidden; position: absolute; clip: rect(0 0 0 0)
切换时内容异步加载？小心重复请求和 loading 状态错乱
商品详情页的“规格参数”“售后保障”“买家评价”这些标签常按需加载，但直接在 click 里发请求容易出问题：用户快速连点两次，“评价”请求发了两遍；或者第一次失败后第二次又点，loading 状态没重置。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 点击后立刻禁用按钮：
button.disabled = true，并加loading类显示转圈图标 - 用
AbortController控制请求生命周期，切换标签前调abort()中止上一个未完成请求 - 内容加载成功后，先清空旧 DOM 再插入新内容，避免残留事件监听器或定时器
- 错误状态要可恢复：显示“加载失败”+“重试”按钮，而不是卡死
移动端滑动切换标签？别自己写手势，用 touchstart/touchend 就够用
有些团队想搞左右滑动切标签，结果陷入手势方向判断、速度阈值、防误触等泥潭。其实电商详情页标签数量通常 ≤5，手指滑动意义不大，真要支持也只需基础位移检测。
- 记录
touchstart的clientX，在touchend读取结束位置，差值绝对值 > 30px 才视为有效滑动 - 只响应水平滑动：
Math.abs(dx) > Math.abs(dy)，避免误判上下滚动 - 滑动后仍要触发一次对应按钮的
click，保证逻辑统一，不要另起一套状态管理 - 不推荐用第三方库（如 Hammer.js）——多 20KB JS，只为一个滑动手势不值得
标签页真正的难点不在切换动画，而在于状态同步：URL hash 是否要变、浏览器前进后退是否要还原、服务端渲染时首屏该展示哪个标签。这些比“怎么切”重要得多，但常被跳过。
