.nvue和.vue文件底层渲染机制完全不同:前者走原生(weex引擎,直接生成原生控件),后者走webview;app端优先加载.nvue,h5/小程序只认.vue;二者混用需注意通信限制与样式约束。

.nvue 和 .vue 文件在 uni-app 中不是“写法不同”,而是**底层渲染机制完全不同**:一个走原生,一个走 WebView。选错文件类型,轻则样式失效、动画卡顿,重则原生组件(如 live-pusher、camera)根本调用不了。
App 平台下,.nvue 用的是 Weex 原生渲染引擎
App 端运行时,.nvue 文件会被编译成原生 UI 组件(Android 的 View / iOS 的 UIView),直接由系统绘制,不经过 WebView 层。
-
.nvue页面里所有view、text、scroll-view都对应真实原生控件,滚动、动画、长列表性能明显更好 - 但代价是:不支持
position: fixed、z-index、@keyframes、transform: rotate()等 Web 常见能力 - CSS 必须用 flex 布局,且只认
px单位;border不能简写,得拆成border-width/border-color等单独声明 - 不支持
scss/less预处理器,style标签里不能@import字体或外部 CSS
.vue 文件在 App 上靠 WebView 渲染,兼容性好但性能受限
.vue 文件本质就是标准 Vue SFC,在 App 端通过内嵌 WebView 加载 HTML+CSS+JS,和 H5 页面逻辑一致。
递归分析 Vue 项目组件依赖,从入口文件生成组件层级图,支持 Vue 2/3,输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- 支持完整 CSS(包括
position: sticky、grid、filter)、Vue 插件、Vuex、v-show、em/rem/upx单位 - 第三方 UI 库(如 uView、uni-ui)基本都只适配
.vue,直接在.nvue里引用会报错或白屏 - 但在高频交互场景(比如人脸识别拍照页、瀑布流商品列表)容易掉帧,
live-pusher的预览画面可能延迟高、触控响应滞后
pages.json 里同名页面的优先级规则必须记牢
同一个路由路径(如 /pages/index/index)下同时存在 index.vue 和 index.nvue 时:
- 发行为 App 平台:只加载
index.nvue,index.vue被完全忽略 - 发行为 H5 或小程序:只加载
index.vue,index.nvue不参与编译(H5 根本不支持.nvue) - 不能靠条件编译“自动切换”,必须手动在
pages.json里注册对应文件,否则页面空白
nvue 和 vue 混搭时,通信和跳转有硬性限制
它们之间不是普通父子组件关系,而是两个独立渲染上下文,数据无法直接共享。
- nvue → vue 跳转只能用
uni.navigateTo({ url: '/pages/xxx/xxx' }),不能用uni.$emit或 Vuex 传参 - 参数必须拼在 URL 里(
?id=123)或走uni.setStorageSync+onLoad读取 - nvue 页面中不能使用
v-show控制显隐,只能用v-if;class绑定只支持字符串或对象语法,不支持数组语法 - 如果项目开启了
app-plus.renderer: "native"全局配置,那整个 App 默认走 nvue 渲染,此时没写.nvue的页面会直接 404
.vue 页面简单改后缀就扔进 App——布局要重写、样式要拆解、事件绑定逻辑可能得换 API。尤其当涉及原生模块调用时,.vue 里写的 uni.requireNativePlugin 可能根本拿不到实例。前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!









