小程序开发里放3D展示，三条路径怎么选
产品3D展示的网页版谈妥了，老板常会追一句：小程序里能不能也放一份？能放。只是小程序开发的环境跟浏览器差别不小，照搬网页那套多半会卡在加载和内存上。目前可行的路子主要三条，各有代价。
先看小程序环境跟网页差在哪
微信小程序没有完整的浏览器环境，DOM和多数浏览器API都不可用。3D渲染只能走两条通道：一是web-view组件里套一个普通网页，二是用canvas组件开WebGL上下文自己画。模型格式、交互方式、内存预算，都跟这两条通道直接相关。
路径一：web-view 嵌网页3D
已经做好的网页版3D，比如three.js写的配置器，用一个web-view页面包一层，小程序里就能直接打开。开发量最小，网页端更新不用重发小程序版本。
限制也实在：web-view里的页面调不到小程序的登录态和支付能力，个人主体小程序不给用web-view，页面出问题排查起来隔着两层。适合的场景很明确：3D展示偏浏览性质，跟小程序其他功能交互不多。
路径二：原生 canvas 加 WebGL
用threejs-miniprogram这类适配库，把three.js跑在小程序canvas上，交互、灯光、材质都能做。好处是3D场景跟小程序功能长在一起，用户转到一个零件就能直接触达询盘表单，体验连贯。
代价在工程量。适配库版本要盯紧，加载器、控制器得逐个验证；机型适配必须真机测试，低端安卓机内存紧张，模型一大直接白屏。遇到渲染异常，先按网页端3D打不开的排查思路过一遍（网页3D打不开先查兼容再谈降级），很多问题是共通的。
路径三：先把模型压下去
不管走哪条路，模型体积都是第一道坎。网页端五兆的GLB，小程序里往往要压到一两兆：减面、贴图压缩、Draco编码，做法跟网页端的模型轻量化是同一套（模型轻量化五个实操做法），只是体积预算要卡得更死。先压模型再谈渲染，顺序不能反。
三条路怎么选
拿不准就按这个顺序过：先确认小程序主体类型能不能用web-view；再看3D在小程序里的角色，纯展示选路径一省成本，要跟表单、会员、报价联动就选路径二；无论选哪条，路径三都躲不掉。小程序3D展示只是整个项目里的一个模块，模板、SaaS和定制的整体取舍是另一层决策（小程序开发三种模式对比），先定模式再定3D方案，顺序别乱。
相关问答
小程序里放3D模型，审核会有问题吗
正常的产品展示类3D不涉及特殊类目，一般按工具或电商类目过审。容易出问题的是web-view指向了未配置或与主体不符的域名，业务域名白名单要提前备齐。
网页版3D配置器已经做好，小程序直接复用行不行
走web-view可以整体复用，开发量最小；但小程序的登录态、支付能力接不进web-view，个人主体也不给用web-view。需要跟功能深度联动的，还是得走原生canvas那套。
小程序3D加载慢，先从哪里下手
先压模型，再查机型。低端安卓机的内存上限是主要瓶颈，减面加贴图压缩通常能解决大半；仍有问题的，考虑先加载一个首帧简化模型，让用户先看到能转的，后台再换完整版。