HTML仅负责展示推荐结果，不参与推荐逻辑；其作用是通过语义化标签（如）渲染后端或轻量JS计算出的配件数据，关键在结构规范、可访问性及边界兼容处理。
HTML 本身不负责推荐逻辑，只负责展示推荐结果
“配件智能推荐”不是 HTML 能干的事——HTML 是结构标记语言，没有计算、判断、数据关联能力。所谓“搭配购买更优惠”，背后依赖的是后端算法（比如基于商品类目、订单共现、规则引擎）或前端 JS 的轻量级匹配（如预置规则表），HTML 只管把推荐出来的 product-id、价格、优惠文案这些内容按需渲染出来。
常见错误现象：TypeError: Cannot read property 'recommend' of undefined 或页面空着不显示推荐位——大概率是 JS 没加载成功，或后端接口返回空/格式错，但开发者误以为改几个 div class 就能“启动推荐”。
- 真实使用场景：商品详情页底部、购物车侧边栏、结算页“你可能还需要”区块
-
HTML层只需预留语义化容器，比如<section aria-label="搭配推荐"></section>，别用<div id="rec-module"> 这种无意义 ID <li>兼容性影响：不用 JS 动态插入时，可服务端直出静态推荐 HTML，首屏更快；但无法个性化，所有用户看到一样</li> <h3>如何用 HTML + 少量 JS 实现基础搭配推荐（无后端）</h3> <p>适合小站、MVP 阶段或离线演示：把搭配关系硬编码在前端，用 <code>data-属性驱动展示逻辑。示例：某蓝牙耳机商品页，想自动显示对应充电盒、收纳包：
立即学习“前端免费学习笔记（深入）”；
<article data-sku="earbuds-pro"> <h1>Pro 耳机</h1> <div class="rec-container" data-for="earbuds-pro"></div> </article> <script type="application/json" id="rec-rules"> { "earbuds-pro": [ {"id": "case-pro", "name": "Pro 充电盒", "price": "199", "discount": "20"}, {"id": "bag-mini", "name": "迷你收纳包", "price": "59", "discount": "10"} ] }</script>- 关键点：用
data-for关联商品与推荐规则，比 class 名匹配更可靠 - 别直接写
document.write()或拼接字符串 DOM —— 用innerHTML或insertAdjacentHTML更可控 - 注意 XSS：如果推荐文案来自用户输入（比如商品名含
<script></script>），必须做textContent赋值或 HTML 转义
“更优惠”文案的 HTML 实现要点
优惠信息不是装饰，它直接影响点击率和转化。HTML 层要确保语义清晰、样式可访问、结构利于 SEO。
- 用
<strong></strong>包裹核心数字，比如<strong>立省 20 元</strong>，别只靠颜色或 font-size 区分 - 避免纯图片文案：不要把“搭配购省 30%”做成
<img src="save30.png" alt="HTML怎么实现配件智能推荐_HTML“搭配购买更优惠”模块【介绍】" >，屏幕阅读器读不出 - 价格对比要显式标注原价/折后价：
<del>¥299</del> <ins>¥249</ins>，而不是只写“¥249（优惠中）” - 如果优惠有门槛（如“满 299 减 50”），必须用
aria-describedby关联说明文字，否则视障用户无法获知条件
容易被忽略的边界情况
上线后才发现问题，往往卡在这些细节上：
- 移动端横屏时，推荐卡片宽度溢出，原因是用了固定
width: 300px，应改用max-width: 100%+flex-wrap - 用户禁用 JS 后，推荐区留白或显示“加载中…”——应在 HTML 中默认放一个无 JS 版本，比如静态热门配件列表
-
data-sku值含特殊字符（如SKU#A-2024!?），JS 查询时没做正则转义，导致匹配失败 - 多个推荐模块共存时，用
document.querySelector('.rec-container')只取到第一个，要用querySelectorAll遍历
真正难的不是写出推荐 HTML，而是让每一条推荐都对得上用户当前上下文——SKU 是否有库存、地域是否支持配送、优惠券是否叠加生效……这些全在 HTML 视野之外。
- 关键点：用
