.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 页面逻辑一致。
- 支持完整 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 时：
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- 发行为 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 可能根本拿不到实例。 
