推荐用 canvas 加载预加载的等间隔图片序列实现 Y 轴圆柱展开式 360 度旋转，避免 three.js 过度设计和移动端 touch 惯性、跳变等问题，上线前须校验图片尺寸、命名连续性及曝光一致性。
用 canvas + 图片序列实现最可控的 360 度旋转
纯 HTML 无法直接实现 360 全景旋转，必须配合 JavaScript 控制图片序列帧。核心思路是：把商品从不同角度拍成一组等间隔图片（比如每 10° 一张，共 36 张），然后用 canvas 或 img 标签按需切换。
推荐用 canvas，因为能精确控制帧率、支持拖拽惯性、避免 img 闪动和预加载空白问题。
- 图片命名建议统一格式：
product_00.jpg、product_01.jpg…product_35.jpg，方便用String.padStart(2, '0')拼路径 - 务必提前用
new Image()预加载全部图片，否则拖拽时会卡顿或显示上一帧 - 鼠标拖拽逻辑别直接绑定
mousemove，要用requestAnimationFrame节流，否则在低配设备上掉帧明显
three.js 加载 TextureLoader 做球面贴图？不推荐
有人想用 three.js 把 36 张图拼成球面全景，这在技术上可行，但对商品展示是过度设计——它本质是模拟“站在球心看内表面”，用户视角变形大，边缘拉伸严重，且操作灵敏度难调。电商场景下，用户要的是“像转实物一样稳、准、快”，不是沉浸式 VR。
真正适合的方案是“圆柱展开”式旋转：只绕 Y 轴匀速转图集，保持商品比例不变。
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 若坚持用
three.js，必须禁用OrbitControls的缩放和俯仰，只保留rotateY，否则用户一碰就歪 -
TextureLoader默认异步加载，单张失败会导致整个序列中断，得自己加onError回退到占位图 - 打包后
three.js基础库约 120KB，而纯 canvas 方案可压到 5KB 以内
移动端 touch 事件处理的三个硬伤
PC 端靠鼠标拖拽很直观，但手机端 touch 行为完全不同：touchstart/touchmove/touchend 缺少原生惯性、容易触发页面滚动、手指抬起瞬间常有位置跳变。
- 必须在
touchstart里调用event.preventDefault()，否则 iOS Safari 会默认滚动页面 - 别用
touchmove的clientX直接算角度，要减去初始 touch 的偏移量，否则手指一斜就乱转 - touchend 后建议加一个
setTimeout启动简易惯性（比如按松手前速度衰减 30%/帧），否则体验像“磁吸式停顿”，非常反直觉
图片序列生成和尺寸一致性是上线前最容易翻车的环节
前端代码写完，90% 的线上问题出在素材本身：角度不均、背景不一致、尺寸有微小差异（比如 799×799 和 800×800 混用）、某张图曝光不足导致切换时突然变暗。
交付前必须用脚本批量校验：
- 用
identify -format '%wx%h %f' *.jpg（ImageMagick）确认所有图等宽高等比例 - 用 Python 脚本检查文件名序号是否连续（
set(range(36)) == set([int(f.split('_')[1].split('.')[0]) for f in files])） - 人工快速过一遍 GIF 预览：把 36 张图合成临时 GIF，一眼就能看出卡顿点在哪一帧
没人会为一张图重拍，但前端得兜住——比如某帧缺失，就用邻帧插值补一张，而不是让旋转停在黑屏上。
