推荐数据必须来自后端API（如/api/v1/product/recommend?sku_id=12345&scene=detail），返回结构化字段供前端渲染，禁止静态写死；DOM需语义化（section+article+h3+aria-label），图片带alt；CSS控制弹性宽度、统一宽高比、骨架屏固定4个；接口应在DOMContentLoaded后立即发起，支持场景参数动态传递。
推荐数据从哪来：别硬写死，优先走 API
静态写死 recommendList 在开发阶段看着省事，上线后根本没法换品、调权、AB 测试。真实项目里，推荐区必须依赖后端接口返回结构化数据，比如 /api/v1/product/recommend?sku_id=12345&scene=detail
- 接口至少返回
id、title、price、cover_url、sales_tip（如“已售 2.3 万”） - 前端只负责渲染，不参与推荐逻辑（相似度计算、热度衰减、用户画像匹配这些全在服务端）
- 如果临时没接口，用 mock 数据也得模拟完整字段结构，避免后续联调时发现字段缺失或类型错位（比如后端传
"price": "¥89.00"，前端却按数字解析）
DOM 结构怎么搭：语义化 + 可访问性不能丢
别用一堆 div 堆出“看起来像卡片”的区域。推荐区本质是「一组相关商品」，应该用 section 包裹，每项用 article，标题用 h3，价格用 span 加 aria-label：
<section aria-labelledby="rec-title">
<h2 id="rec-title">看了又看</h2>
<article>
<h3>无线降噪耳机 Pro</h3>
<span aria-label="价格：¥599.00">¥599.00</span>
</article>
</section>- 不要用
ul/li模拟列表——它不是导航也不是纯文本列表，语义不符，屏幕阅读器会误读 - 图片必须带
alt，哪怕只是alt="无线降噪耳机 Pro 封面"，空alt=""仅适用于纯装饰图 - 如果推荐区支持横向滚动（小屏），记得加
overflow-x: auto和-webkit-overflow-scrolling: touch，否则 iOS 上卡顿
样式和交互怎么控：宽度、间距、加载态要收口
推荐区常被塞进详情页右侧栏或底部流式布局里，宽度变化大，CSS 得有弹性：
- 卡片用
min-width: 140px防止窄屏下文字挤成一团，但不超过max-width: 220px，避免拉宽破坏整体节奏 - 图片统一
aspect-ratio: 1/1或固定宽高比，别让不同商品图高度不一导致卡片参差 - 加载时显示骨架屏（skeleton），而不是空白或转圈图标；骨架数量固定为 4 个，别随接口返回条数变，否则布局跳动
- 点击卡片跳转必须带
target="_blank"吗？不一定。电商详情页内跳转建议target="_self"，保持用户在当前标签页，避免丢失原商品上下文
为什么推荐区总被砍掉首屏权重：JS 渲染时机太晚
很多团队把推荐区交给 React/Vue 组件异步加载，结果 Lighthouse 报告里「首屏内容渲染延迟」直接扣分。真实场景中，推荐区虽非核心，但属于强关联信息，应尽可能早触达：
立即学习“前端免费学习笔记（深入）”；
- 接口请求放在页面初始化阶段（比如
DOMContentLoaded后立刻发），不要等主商品数据加载完才发起 - 如果用 SSR 或静态生成，把推荐数据预取（prefetch）进 HTML，用
data-*属性挂载，JS 初始化时直接读取，省去一次网络往返 - 别在推荐卡片里嵌视频自动播放、第三方统计脚本、未压缩的大图——这些资源会拖慢整个区块的可交互时间（TTI）
细节上最容易被忽略的是：当用户从搜索页点击进入详情页时，推荐接口的 scene 参数得动态设为 search_to_detail，而不是写死 detail，否则算法无法区分流量来源，推荐结果会越来越不准。
