Web、微信小程序和跨端框架的运行边界有什么不同？

简答

H5、小程序和原生 App 的渲染器、权限模型和生命周期不同。
小程序页面不是可任意操作的浏览器文档，不能依赖 document、window 或 DOM 插件。
跨端路线分为编译到各平台组件，和共享逻辑、分别实现视图。
选型不能只看代码复用比例，还要算调试、升级、审核和适配成本。

团队希望把一个 H5 活动页快速做成微信小程序和原生 App，最容易出现的误解是“把 HTML、CSS 和 DOM 改几个标签就能复用”。不同平台的渲染器、权限模型和生命周期并不相同。跨端框架可以复用一部分组件和业务逻辑，但它不能消除平台能力、审核流程和性能模型的差异。

运行环境先决定可复用边界

普通 Web 页面运行在浏览器文档环境中，通常可以使用 DOM、CSSOM、浏览器路由和标准 Web API，但会受到同源策略、浏览器权限和跨浏览器差异影响。小程序一般由平台提供逻辑层和视图层，页面并不是一个可以任意操作的浏览器文档；组件、样式、导航和网络请求遵循平台 API，不能直接依赖 document、window 或第三方 DOM 插件。

跨端框架通常有两种路线：

编译到各平台组件：把一套声明式代码转换成 Web、小程序或原生组件，运行时更接近目标平台，但能使用的最低公约数有限。
共享逻辑、分别实现视图：复用数据模型、请求层、校验和状态机，各平台编写适合自身的 UI，代码量较多但边界清晰。

选择哪种路线要看业务是否依赖 DOM、复杂动画、原生能力、SEO 和平台特有组件。不能仅用“代码复用比例”评价方案，长期维护成本还包括调试、升级、审核和平台适配。

组件和样式不是同一套标准

Web 的布局和选择器由 CSS 标准定义，浏览器会构建 DOM 和 CSSOM。小程序通常只支持平台规定的 WXML/模板语法、样式子集和组件属性；某些 CSS 能力、伪元素、定位行为和事件模型可能不同。跨端框架即使提供相同的组件名称，也可能在属性默认值、插槽、事件冒泡和测量时机上存在差异。

不要把 Web 组件库直接复制到小程序：它们可能依赖 DOM 查询、Portal、全局事件或浏览器焦点模型。更稳妥的做法是定义跨端设计 token 和交互契约，例如颜色、间距、加载状态和错误状态保持一致，再为每个平台实现组件适配层。

网络请求和权限由平台控制

浏览器请求受 CORS、Cookie、同源策略和用户授权影响；小程序请求通常还要求把域名加入平台允许列表，并使用平台提供的请求接口。跨端请求封装应统一超时、取消、重试和错误模型，但不能假设每个平台都支持相同的 Cookie、流式响应、文件上传或 WebSocket 行为。

服务端不要只依赖前端传来的平台标识做权限判断。平台的登录凭证、用户身份和访问令牌应在服务端验证，并根据不同客户端返回明确的能力结果。若某个平台不支持流式响应或后台持续任务，应提供轮询、分段结果或稍后查看等降级路径，而不是让界面一直等待。

生命周期和页面栈不同

Web 页面通常围绕加载、可见性、卸载和历史导航组织；小程序还有应用、页面、组件和分包等生命周期，页面可能被保留在导航栈中而没有销毁。跨端代码如果把“页面隐藏”当成“资源已释放”，就会造成定时器、监听器和订阅重复注册。

业务层可以使用显式的资源状态机管理订阅：进入可见状态时创建，离开时暂停，真正销毁时释放。对于音视频、地图、WebSocket 和定位等资源，要分别确认目标平台的后台限制和恢复行为，不能只依赖框架的 unmount 或 onUnload。

设备能力需要能力检测和用户授权

相机、相册、位置、蓝牙、通知和文件访问在不同平台有不同的授权时机、拒绝状态和再次申请规则。统一 API 只能统一调用形状，不能统一用户体验。调用前应检查能力，调用时处理用户拒绝、系统关闭、设备不支持和权限被撤销等结果；权限说明要在用户理解用途后出现，不能在启动时一次申请所有权限。

JavaScript

async function choosePhoto(platform) {
  if (typeof platform?.choosePhoto !== 'function') {
    return { kind: 'unsupported' };
  }

  try {
    const files = await platform.choosePhoto({ count: 1 });
    if (!Array.isArray(files)) throw new TypeError('适配层返回格式错误');
    if (files.length === 0) return { kind: 'cancelled' };
    return { kind: 'success', file: files[0] };
  } catch (error) {
    if (error?.code === 'USER_CANCELLED') return { kind: 'cancelled' };
    if (error?.code === 'PERMISSION_DENIED') return { kind: 'denied' };
    return { kind: 'failed', error };
  }
}

示例中的 platform、PERMISSION_DENIED 和 USER_CANCELLED 都是应用自己的适配契约，不代表某个平台的真实 API 或错误码。约定适配层将用户取消映射为取消码或空数组，业务侧就能区分取消、权限拒绝和系统失败，取消时通常不需要弹错误提示。真实文件对象还应在适配层校验必需字段、大小和可读取性，不能把任意数组成员当成可上传文件。

保留原始错误仅用于受控诊断，日志应去掉临时文件路径、用户内容和凭据。不要在通用业务组件里散落各平台的错误字符串判断，也不要假设不同平台拒绝权限后都能立刻再次弹窗申请。

性能模型也不一样

浏览器页面的瓶颈可能来自主线程脚本、布局、绘制和网络；小程序还可能受到逻辑层与视图层通信、序列化数据量、分包加载和平台组件限制影响。频繁把大对象从逻辑层传到视图层，或在列表中传递整棵状态树，可能比同样的 Web 代码更慢。

跨端列表应使用稳定 key、分页或虚拟化策略，并限制单次更新的数据范围。图片要按设备尺寸提供合适资源，长列表不要把所有数据和图片一次性放入页面。性能优化前先使用目标平台的开发者工具和真实设备测量，不能只看 Web Lighthouse 分数。

发布、审核和更新方式属于架构约束

Web 可以通过服务器或静态资源发布快速回滚；小程序和 App 需要经过平台审核，热更新、远程配置和动态代码也受到平台规则约束。涉及支付、登录、内容和隐私的功能，应把审核材料、隐私声明、域名配置和版本回滚纳入交付流程。

不要把核心业务安全寄托在客户端审核或混淆代码上。客户端只负责展示和发起请求，价格、权限、库存、内容合规和重要状态必须在服务端重新校验。远程配置也要有版本、签名或白名单约束，避免配置错误把不可用功能推给全部用户。

选型时如何回答“为什么不用一套代码”

如果产品主要是内容、表单和简单列表，跨端组件方案可以减少重复开发；如果需要 SEO、复杂 DOM 编辑器或浏览器插件，Web 应优先保持原生能力；如果高度依赖系统相机、支付、蓝牙或后台任务，应评估原生或更贴近原生的方案。面试中应说明复用的是业务规则、数据模型和设计 token，哪些视图和平台能力需要独立实现，并用真实目标设备验证关键路径。