真正唤起AR预览需用<a>标签，href指向HTTPS同源的.usdz或.reality文件，设rel="ar"，禁用download，服务端返回正确Content-Type；iOS仅Safari支持usdz，Android WebXR AR极不可靠。
HTML里加AR按钮，本质是唤起设备原生能力
浏览器不直接渲染AR场景，所谓“3D查看”或“AR预览”按钮，只是触发系统级API（如iOS的ARQuickLook、Android的WebXR），由OS接管后续流程。按钮本身没魔法，关键在链接格式、MIME类型和设备兼容性。
常见错误现象：click后毫无反应；点开白屏；提示“不支持此文件类型”；iOS上跳转到下载页而非预览。
- 必须用
<a>标签包裹，且href指向支持的3D模型文件（.usdz或.reality），不能是<button>或div模拟 - iOS 12+才支持
usdz，且仅Safari有效；Android需Chrome 90+ + WebXR启用，且多数机型仍无AR Quick Look等效机制 - 服务器必须返回正确的
Content-Type：对.usdz是model/vnd.usd+zip，对.reality是model/vnd.reality，否则Safari拒绝加载
写一个能真正唤起AR预览的<a>标签
不是加个onclick就行，得让浏览器识别这是“可预览的3D资源”。核心是路径合法、协议合规、属性到位。
使用场景：商品页旁放“AR摆放”按钮、装修App中预览家具、教育页面展示人体结构模型。
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
href必须是HTTPS协议下的绝对路径或同源相对路径（http://或非同源会直接失败） - 建议添加
rel="ar"属性，虽非强制但部分iOS版本会据此优化行为 - 加上
download属性会禁用AR预览，改走下载逻辑——这点极易踩坑 - 示例：
<a href="/models/chair.usdz" rel="ar">AR摆放</a>
为什么WebXR在移动端几乎不可靠
理论上navigator.xr可以启动WebXR会话，但实际落地极难。不是代码写错，而是生态断层。
性能与兼容性影响：WebXR需用户授权摄像头+运动传感器，Android碎片化严重，Pixel以外大量机型缺失底层ARCore服务支持；iOS至今未开放WebXR for AR（仅支持VR模式）。
- 调用
navigator.xr.requestSession('immersive-ar')大概率返回NotSupportedError或PermissionDenied - 即使成功，首次加载需预编译WebGL着色器，低端机卡顿明显，用户早关页面了
- 目前唯一稳定路径仍是
usdz+Safari，别在Android上强推WebXR AR入口
按钮文案和样式要暗示“系统接管”，别让用户误以为是网页内渲染
“3D查看”这种说法容易误导用户期待网页内旋转模型，结果点开却跳到新页面甚至系统App——体验割裂就来自语义偏差。
容易被忽略的地方：按钮视觉反馈必须和系统行为匹配。比如iOS上AR Quick Look有固定过渡动画，你的按钮如果做成平滑CSS缩放，反而让用户困惑“是不是没点上”。
- 文案优先用“在AR中查看”“用相机摆放”“打开AR”等明确动词短语，避开“3D”“模型”等中性词
- 图标建议复用系统风格（如iOS人形+方框组合图标），不要自定义3D立方体小图标
- 禁用
:active状态的背景色突变，Safari点击后自带灰阶压感反馈，额外样式会干扰
<a>标签，而是搞不清哪台手机、哪个系统版本、连着什么网络，才能让usdz不变成404或下载包。 
