你在 H5 上开发调试，图表渲染完美、主题切换丝滑。打包发到微信小程序和 App 上一看，图表区域整块白，主题切换点了没反应。
现象
一个环形图组件在 H5 端显示完全正常，在微信小程序和原生 App 上整块空白，什么都没有。同时，主题切换功能也只在 H5 上生效，非 H5 端点了没有反应。
代码是同一套，行为却完全不同。最气人的是：本地开发时你在浏览器里看得好好的，直到打包到真机上才发现——而这时候改动成本已经很高了。
补充一个观察细节：这类问题在编译期不会有任何警告。框架不会因为你在非 H5 端用了 v-html 就报错，编译照样通过、打包照样成功，只有真机运行时才表现为空白——这也是它特别容易漏到线上的原因。
根因
这是跨端框架的平台差异导致的，具体有两个机制。
第一个是 v-html。 在多个跨端框架里，v-html 只在 H5 平台生效，因为在 H5 上它最终会操作真实 DOM 的 innerHTML。而在小程序和 App 端，渲染出来的不是浏览器 DOM，是各自平台的原生组件 / 渲染层，压根没有 innerHTML 这个概念，v-html 的内容自然就不会被渲染。如果你的 SVG 图表是用 v-html 塞进去的，非 H5 端就是空白。
第二个是 document 之类的 DOM API。 document.querySelector、document.documentElement.setAttribute 这些在小程序和 App 环境里不存在，会直接报错（或者被框架静默吞掉）。如果主题切换是通过往 document 上挂属性、加 class 来实现的，非 H5 端就完全不工作。
两个问题本质相同：代码依赖了只有浏览器才有的能力，而跨端框架的其他端并不提供这些能力。
往深一层说，小程序和 App 的渲染模型是"数据驱动"的：逻辑层和渲染层分离，逻辑层把数据传给渲染层，由平台的原生组件负责画出来。而 H5 用的是浏览器的 DOM 模型。v-html、document 这类 API 都是围绕"直接操作 DOM"设计的，在数据驱动的模型里没有对应物，所以无法翻译过去。
解决
图表方面，非 H5 平台改用平台支持的方案。
一是用 canvas 画（各端都有 canvas 组件），配合条件编译：
<!-- #ifndef H5 -->
<canvas canvas-id="ring" id="ring" />
<!-- #endif -->
<!-- #ifdef H5 -->
<div v-html="svgString"></div>
<!-- #endif -->
二是用纯 CSS 绘制（conic-gradient 之类），适合简单的环形 / 进度效果。
三是用框架生态里已经做了跨端适配的图表库——这是最省事的，但要注意选库时确认它明确支持你要发布的那些端。
主题切换方面，改用框架提供的跨端方案。
一是条件编译，针对不同端写不同的实现（如上）； 二是用全局状态管理来存当前主题，各端从状态里读，而不是从 DOM 上读； 三是用**组件属性（props）**把主题传下去，让每个组件自己知道自己该用什么色值。
核心思路是：不要从"环境"里读状态（DOM 是环境的一部分），而是从"应用状态"里读。这样一来，同一套状态逻辑在哪个端都能跑。
延伸与预防
核心认知：能在浏览器跑，不等于能在所有端跑。
开发跨端项目时，建立一个禁忌清单：不用 v-html、不用 document、不用 window、不用只在浏览器存在的 API。如果实在要用，必须用条件编译包起来，并且保证非 H5 分支有等价实现（不是留空）。
更靠谱的做法是：开发期间就把小程序开发者工具打开，每写一个功能在两个端都看一眼，而不是等发布前一测才发现。跨端项目的 bug 有很强的"端特异性"，只在浏览器里测等于只测了一半。
最后可以加一道自动化防线：在流水线里加一步静态检查，扫描源码里是否出现了 v-html / document / window 等标记，一旦命中就提示"这里可能需要条件编译"。人工约束容易忘，用工具把它变成流程的一部分才可靠。