飞美1、什么是块级作用域块级作用域是指变量或函数的作用范围被限制在代码块（用 {} 包裹的区域）内，仅在该代码块

1、什么是块级作用域

块级作用域是指变量或函数的作用范围被限制在 代码块（用 {} 包裹的区域） 内，仅在该代码块及嵌套的子代码块中可访问，外部无法访问。

核心特点

代码块触发：由 {} 界定，常见场景包括 if 语句、for 循环、while 循环、switch 语句、函数体，以及独立的 {} 块。
变量隔离：块内声明的变量不会泄露到外部，避免全局污染和变量名冲突。
支持关键字：ES6 中通过 let 和 const 声明块级作用域变量，var 不支持（var 是函数级作用域或全局作用域）。

常见场景示例

1. if 语句块

javascript

运行

if (true) {
  let blockVar = "块级变量";
  const blockConst = "块级常量";
  var funcVar = "函数级变量"; // var 不受块级限制
}

console.log(blockVar); // 报错：blockVar is not defined（块外不可访问）
console.log(blockConst); // 报错：blockConst is not defined
console.log(funcVar); // 输出："函数级变量"（var 提升为全局/函数级）

2. for 循环块

javascript

运行

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0); // 输出：0、1、2（每次循环的 i 是独立块级变量）
}

for (var j = 0; j < 3; j++) {
  setTimeout(() => console.log(j), 0); // 输出：3、3、3（var 声明的 j 是全局变量，循环结束后为 3）
}

3. 独立代码块

javascript

运行

{
  let独立块变量 = "独立块内";
}
console.log(独立块变量); // 报错：独立块变量 is not defined

与函数级作用域的区别

函数级作用域：由 function 界定，var 声明的变量作用范围是整个函数（或全局），即使嵌套在块内也会提升。
块级作用域：由 {} 界定，let/const 声明的变量仅在块内有效，不会提升到块外。

关键注意点

let/const 不存在变量提升：块内声明前访问会触发 “暂时性死区（TDZ）”，直接报错。
const 必须初始化且不可修改：声明时需赋值，且后续不能重新赋值（引用类型内部属性可改）。
块级作用域可嵌套：内层块可访问外层块的变量，外层块无法访问内层块的变量。特性 | var | let | const | | ----------- | ---------------------- | --------------- | --------------- | | 作用域 | 函数作用域或全局作用域 | 块级作用域 | 块级作用域 | | 变量提升 | 是（初始值为 undefined） | 是（但存在暂时性死区） | 是（但存在暂时性死区） | | 重复声明 | 允许 | 不允许 | 不允许 | | 全局声明时 | 会成为全局对象（如 window）的属性 | 不会成为全局对象的属性 | 不会成为全局对象的属性 | | 是否需要初始化 | 否 | 否 | 是

2、作用域有哪些

JavaScript 中的作用域主要分为 4 类核心类型，按作用范围从窄到宽依次为：块级作用域、函数级作用域、模块作用域、全局作用域，不同作用域决定了变量 / 函数的可访问范围和生命周期。

1. 块级作用域（Block Scope）

核心定义：变量作用范围限制在 {} 包裹的代码块内，仅块内及嵌套子块可访问。
声明关键字：ES6 新增，通过 let、const 声明。
常见场景：if 语句、for 循环、switch 语句、独立 {} 块、函数体嵌套块。
关键特性：无变量提升，存在 “暂时性死区（TDZ）”，变量不会泄露到块外。

2. 函数级作用域（Function Scope）

核心定义：变量作用范围限制在声明它的函数内部，函数外部无法访问。
声明关键字：主要通过 var 声明，函数参数也属于函数级作用域。
常见场景：函数体内声明的 var 变量、函数声明（函数名本身作用于函数级）。
关键特性：变量提升（函数内任意位置声明的 var 会提升到函数顶部），函数嵌套时内层可访问外层，外层不可访问内层。

3. 模块作用域（Module Scope）

核心定义：ES6 模块（.mjs 文件或 type="module" 的脚本）中，变量的作用范围限制在当前模块内。
声明方式：模块内直接声明的变量（无论 let/const/var）默认属于模块作用域。
访问规则：模块内变量默认私有，需通过 export 导出，其他模块通过 import 才能访问。
关键特性：独立于全局作用域，避免全局污染，同一模块多次导入仅执行一次。

4. 全局作用域（Global Scope）

核心定义：最顶层的作用域，变量可在代码中任何位置访问。
声明方式：
- 全局作用域中直接声明的 var 变量、函数声明；
- 未通过任何关键字声明（隐式声明）的变量（不推荐）。
关键特性：生命周期与程序一致，容易造成变量名冲突，应尽量避免过多全局变量。
浏览器环境中，全局变量会挂载到 window 对象上；Node.js 环境中挂载到 global 对象上。

补充：词法作用域（Lexical Scope）

核心定义：又称 “静态作用域”，是作用域的 “查找规则”，而非独立作用域类型。
核心规则：变量的访问范围由代码编写时的嵌套结构决定，而非运行时的执行上下文。
示例：内层函数可访问外层函数的变量，无论内层函数在何处执行，查找范围始终基于定义时的嵌套关系。

要不要我帮你整理一份 各类作用域的特性对比表，清晰呈现声明方式、访问规则、使用场景的差异？

3、先var后let会报错吗？反过来呢

在同一作用域内，先使用 var 声明变量，再用 let 声明同名变量会报错；而 先 let 后 var 声明同名变量也会报错。核心原因是：ES6 规定，同一作用域内不允许对同一变量进行重复声明，无论使用 var、let 还是 const，只要变量名重复就会触发语法错误（SyntaxError）。

1. 先 `var` 后 `let` 会报错

javascript

运行

function test() {
  var a = 1;
  let a = 2; // 报错：SyntaxError: Identifier 'a' has already been declared
}

原因：var 声明会被提升到作用域顶部，而 let 不允许在同一作用域内对已存在的变量（无论通过何种方式声明）再次声明，因此即使 var 在前，let 在后也会冲突。

2. 先 `let` 后 `var` 也会报错

javascript

运行

function test() {
  let a = 1;
  var a = 2; // 报错：SyntaxError: Identifier 'a' has already been declared
}

原因：let 声明的变量会绑定当前作用域，形成 “暂时性死区（TDZ）”，同一作用域内 var 无法重复声明已被 let 绑定的变量，无论声明顺序如何，重复声明都会触发错误。

关键总结

同一作用域内：var、let、const 不能声明同名变量，否则直接报错（语法错误，代码无法运行）。

不同作用域内：允许同名变量（因作用域隔离），例如：

javascript

运行

{
  var a = 1; // 函数/全局作用域
  {
    let a = 2; // 内层块级作用域，与外层 a 不冲突
  }
}

本质上，这是 ES6 为了避免变量声明混乱（尤其是 var 的提升特性导致的问题）而设计的规则，let/const 严格禁止重复声明，即使与 var 混合使用也不例外。

3、声明提升是到哪里？函数有声明提升吗？

声明提升（Hoisting）是 JavaScript 引擎在代码执行前的 “预编译” 阶段，将变量或函数的声明部分 “移动” 到其所在作用域顶部的行为（注意：这是逻辑上的提升，实际代码并未物理移动）。

一、声明提升到哪里？

变量或函数的声明提升范围由其作用域决定：

全局作用域中声明的变量 / 函数，提升到全局作用域顶部；
函数作用域中声明的变量 / 函数，提升到当前函数作用域顶部；
块级作用域中，let/const 声明的变量存在 “提升” 但有特殊行为（见下文）。

二、不同声明方式的提升规则

1. `var` 变量提升

提升内容：变量声明被提升到作用域顶部，赋值部分不提升。

示例：

javascript

运行

console.log(a); // 输出：undefined（声明已提升，赋值未执行）
var a = 1;

// 等价于预编译后：
var a; // 声明提升到作用域顶部
console.log(a); // undefined
a = 1; // 赋值留在原地执行

2. `let`/`const` 变量的 “提升特殊性”

是否提升：从规范角度，let/const 声明也会被提升到块级作用域顶部，但存在暂时性死区（TDZ） —— 在声明语句之前访问变量会直接报错，而非返回 undefined。

示例：

javascript

运行

console.log(b); // 报错：ReferenceError（处于暂时性死区）
let b = 2;

// 逻辑上：
let b; // 声明提升到块级作用域顶部（但未初始化）
console.log(b); // 访问时处于 TDZ，报错
b = 2; // 赋值执行

3. 函数声明提升

函数有声明提升，且提升优先级高于变量提升。
提升内容：整个函数声明（包括函数体）都会被提升到作用域顶部。

示例：

javascript

运行

foo(); // 输出："函数执行"（函数声明已提升）
function foo() {
  console.log("函数执行");
}

// 等价于预编译后：
function foo() { // 整个函数声明提升到作用域顶部
  console.log("函数执行");
}
foo();

4. 函数表达式（非声明）无提升

若函数通过变量赋值定义（函数表达式），则仅变量声明提升，函数体不提升。

示例：

javascript

运行

bar(); // 报错：bar is not a function（变量提升但未赋值函数）
var bar = function() {
  console.log("函数表达式");
};

// 等价于预编译后：
var bar; // 变量声明提升
bar(); // 此时 bar 是 undefined，调用报错
bar = function() { ... }; // 赋值留在原地

三、关键总结

提升范围：声明提升到当前作用域顶部（全局 / 函数 / 块级，取决于声明位置）。
函数声明：有提升，且优先级高于变量提升（函数声明会覆盖同名变量声明，但不覆盖赋值）。
特殊情况：
- var 提升后默认值为 undefined；
- let/const 提升后存在暂时性死区，提前访问报错；
- 函数表达式仅变量部分提升，函数体不提升。

例如，函数声明与变量声明的优先级冲突：

javascript

运行

console.log(foo); // 输出：[Function: foo]（函数声明优先提升）
var foo = "变量";
function foo() {}

// 预编译后逻辑：
function foo() {} // 函数声明提升
var foo; // 变量声明提升（被函数声明覆盖，无实际效果）
console.log(foo); // 函数

4、a._proto_和a.的this为啥不一样

a.__proto__ 中方法的 this 与 a 自身方法的 this 为什么不同。这本质上与 this 的绑定规则 和 原型链的查找机制 有关。

核心原因：`this` 指向调用者，而非定义位置

无论是对象自身的方法，还是原型链（__proto__）上的方法，this 的指向只取决于 “谁调用了这个方法” ，与方法定义在对象自身还是原型上无关。但实际场景中，两者的 this 可能看似不同，往往是因为调用方式或方法定义方式导致的。

示例分析

假设存在对象 a 及其原型上的方法：

javascript

运行

// 定义原型对象
const proto = {
  protoMethod() {
    console.log('protoMethod 的 this:', this);
  }
};

// 创建对象 a，原型指向 proto
const a = {
  ownMethod() {
    console.log('ownMethod 的 this:', this);
  }
};
a.__proto__ = proto; // 设置 a 的原型为 proto

1. 直接通过 `a` 调用时，`this` 相同

无论是调用自身方法还是原型链上的方法，只要通过 a 调用，this 都指向 a：

javascript

运行

a.ownMethod(); // ownMethod 的 this: { ownMethod: ... } → 指向 a
a.protoMethod(); // protoMethod 的 this: { ownMethod: ... } → 指向 a

原因：方法调用时，this 绑定到调用者（a），无论方法在自身还是原型上。

2. 为什么会觉得 “不一样”？

可能的场景：将原型方法单独提取出来调用，导致 this 指向改变（如指向 window 或 undefined）。

javascript

运行

// 提取原型方法，单独调用
const func = a.protoMethod; 
func(); // 浏览器中输出：protoMethod 的 this: Window（非严格模式）

此时 func 是独立函数调用，this 指向全局对象（浏览器中是 Window，严格模式下是 undefined），与通过 a 调用时的 this（a 本身）不同。
但这不是因为方法在原型上，而是调用方式变了（从对象调用变成了函数独立调用）。

3. 特殊情况：箭头函数

如果原型上的方法是箭头函数，this 会绑定到定义时的上下文（而非调用者），这可能导致与对象自身方法（普通函数）的 this 不同：

javascript

运行

const proto = {
  protoArrow: () => {
    console.log('protoArrow 的 this:', this); // 指向定义时的上下文（如 Window）
  }
};

const a = {
  ownArrow: () => {
    console.log('ownArrow 的 this:', this); // 同样指向定义时的上下文
  }
};
a.__proto__ = proto;

a.ownArrow(); // ownArrow 的 this: Window
a.protoArrow(); // protoArrow 的 this: Window

箭头函数没有自己的 this，其 this 继承自定义时的外层作用域，与调用者无关。这种情况下，无论方法在自身还是原型上，this 都可能相同（如都指向全局），但这是箭头函数的特性，并非原型导致的差异。

总结

正常情况下（方法为普通函数，通过对象调用）：a 自身的方法和 a.__proto__ 上的方法，this 都指向 a（调用者），没有区别。
差异的根源：若原型方法被单独调用（脱离对象），或方法是箭头函数，this 指向会改变，但这与 “方法在原型上” 无关，而是由调用方式或函数类型决定。

简单说：this 的指向只看 “谁调用”，不看 “方法在哪定义（自身还是原型）”。

5、b.xxx=a.xxx是怎么影响b的this，为什么

当执行 b.xxx = a.xxx 时，本质是将 a 的 xxx 方法复制给 b 作为 b 的一个属性。此时 b.xxx 调用时的 this 指向会受 调用方式 影响，核心规则是：函数的 this 指向调用它的对象（即 “调用者”） 。

具体分析

假设 a.xxx 是一个普通函数（非箭头函数）：

javascript

运行

const a = {
  name: 'a',
  xxx() {
    console.log(this.name);
  }
};

const b = {
  name: 'b'
};

// 将 a 的 xxx 方法赋值给 b 的 xxx 属性
b.xxx = a.xxx;

1. 当 `b.xxx()` 调用时，`this` 指向 `b`

javascript

运行

b.xxx(); // 输出：'b'

原因：方法 xxx 此时作为 b 的属性被调用，调用者是 b，因此 this 绑定到 b。
虽然 xxx 函数最初定义在 a 上，但函数的 this 与 “定义位置” 无关，只与 “调用时的所有者” 有关。

2. 对比 `a.xxx()` 调用时的 `this`

javascript

运行

a.xxx(); // 输出：'a'

此时调用者是 a，因此 this 指向 a。

3. 若单独调用 `b.xxx` 函数（脱离 `b`），`this` 指向全局对象

javascript

运行

const func = b.xxx;
func(); // 浏览器中输出：undefined（非严格模式下 this 指向 Window，Window.name 可能为空）

原因：函数独立调用时，this 指向全局对象（浏览器中是 Window，严格模式下是 undefined），与 a 或 b 无关。

为什么会这样？

JavaScript 中函数的 this 是动态绑定的，其指向由调用时的上下文决定，而非定义时的上下文：

当函数作为对象的属性被调用时（obj.method()），this 指向该对象（obj）。
b.xxx = a.xxx 仅仅是将函数的引用复制给 b，函数本身的代码没有变化，但它的 “调用者” 变成了 b，因此 this 自然指向 b。

特殊情况：箭头函数

若 a.xxx 是箭头函数，this 不会因调用者变化而改变，因为箭头函数的 this 是定义时绑定的（继承自外层作用域）：

javascript

运行

const a = {
  name: 'a',
  xxx: () => {
    console.log(this.name); // this 指向 a 定义时的外层作用域（如 Window）
  }
};

const b = { name: 'b' };
b.xxx = a.xxx;

b.xxx(); // 输出：undefined（Window.name 通常为空）
a.xxx(); // 同样输出：undefined

此时无论通过 a 还是 b 调用，this 都指向箭头函数定义时的外层作用域（与 a、b 无关）。

总结

b.xxx = a.xxx 会让 b 拥有 xxx 方法的副本，调用 b.xxx() 时，this 指向 b（因为 b 是调用者）。
核心原因：普通函数的 this 绑定于调用时的对象，与函数最初定义的对象无关。

6、浏览器的js为啥会阻塞渲染，为啥这么设计，小程序有这个问题吗？如何解决的？

浏览器中的 JavaScript 会阻塞渲染，本质与浏览器的 单线程模型 和 任务调度机制 有关。以下从原因、设计逻辑、小程序的情况及解决方案展开说明：

一、为什么浏览器的 JS 会阻塞渲染？

浏览器的主线程（Main Thread）是单线程的，负责处理 JavaScript 执行、HTML 解析、CSS 解析、布局（Layout） 、绘制（Paint） 、合成（Composite） 等核心任务。这些任务在主线程中 串行执行，即同一时间只能处理一个任务。

当 JavaScript 执行时：

若 JS 任务耗时较长（如复杂计算、同步 DOM 操作），主线程会被占用；
后续的渲染任务（如布局、绘制）必须等待 JS 执行完成才能开始；
因此，JS 执行期间，页面无法更新，表现为 “阻塞渲染”。

举例：

javascript

运行

// 耗时 1 秒的 JS 任务
function block() {
  const start = Date.now();
  while (Date.now() - start < 1000) {} // 阻塞主线程 1 秒
}

block();
// 以下 DOM 更新会在 1 秒后才执行
document.body.style.backgroundColor = 'red';

上述代码中，block 函数执行时，主线程被占用，背景色修改的渲染任务需等待 1 秒后才会执行，导致页面 1 秒内无变化。

二、为什么这么设计？

这种 “JS 阻塞渲染” 的设计是 权衡性能与逻辑一致性 的结果：

DOM 操作的原子性：JS 可以直接操作 DOM（如添加 / 删除节点、修改样式），而渲染依赖 DOM 和 CSSOM。若 JS 执行与渲染并行，可能导致渲染结果基于 “不完整的 DOM 状态”（如 JS 正在修改 DOM，同时浏览器在渲染），引发视觉错乱。
避免资源竞争：单线程模型下，JS 执行和渲染任务串行，可避免多线程同时操作 DOM 导致的冲突（如两个线程同时修改同一个元素的样式），减少复杂的同步机制。
历史与兼容性：早期浏览器设计受限于硬件性能和技术复杂度，单线程模型实现简单且能满足基本需求，后续为兼容现有代码，未彻底推翻这一模型，而是通过 Web Workers 等机制补充多线程能力。

三、小程序有这个问题吗？

小程序也存在 JS 阻塞渲染的问题，但表现和原因与浏览器略有不同：

小程序的线程模型：主流小程序（如微信、支付宝）采用 双线程架构：
- 逻辑层：运行 JS 代码（业务逻辑、数据处理），独立线程；
- 渲染层：负责页面渲染（类似浏览器主线程的渲染工作），另一个独立线程。两层通过 数据通信 同步（如逻辑层修改数据后，通过桥接机制通知渲染层更新）。
阻塞原因：若逻辑层的 JS 任务耗时过长（如复杂计算），会阻塞逻辑层向渲染层发送更新指令，导致渲染层无法及时收到新数据，表现为页面卡顿。此外，小程序的 JS 执行仍受单线程限制（逻辑层是单线程），长任务会阻塞所有后续逻辑（包括事件响应、数据更新）。

四、如何解决 JS 阻塞渲染的问题？

核心思路：减少主线程（或逻辑层）的工作量，将耗时任务移至后台线程，避免长时间占用。

1. 浏览器端解决方案：

拆分长任务：将耗时 JS 拆分为多个小任务，用 setTimeout、requestIdleCallback 或 Promise 分段执行，避免单次阻塞超过 50ms（人眼可感知的延迟阈值）。例：

javascript

运行

// 拆分循环任务
const data = new Array(100000).fill(0);
let index = 0;

function process() {
  // 每次处理 1000 条，避免长时间阻塞
  while (index < data.length && index < 1000) {
    // 处理数据...
    index++;
  }
  if (index < data.length) {
    setTimeout(process, 0); // 让出主线程，允许渲染
  }
}
process();

使用 Web Workers：将 CPU 密集型任务（如大数据计算、文件解析）移至 Web Workers 执行，主线程仅处理渲染和交互，两者通过消息通信。例：

javascript

运行

// 主线程
const worker = new Worker('data-processor.js');
worker.postMessage(largeData); // 发送数据给 Worker
worker.onmessage = (e) => {
  console.log('处理结果：', e.data); // 接收结果，不阻塞渲染
};

// data-processor.js（Worker 线程）
self.onmessage = (e) => {
  const result = heavyComputation(e.data); // 耗时计算
  self.postMessage(result);
};

优化 DOM 操作：避免频繁修改 DOM（如批量操作时用 DocumentFragment），减少重排 / 重绘；优先使用 transform、opacity 等仅触发合成的属性。
异步加载非关键 JS：用 <script async> 或 <script defer> 加载非首屏必要的 JS，避免阻塞 HTML 解析和渲染。

2. 小程序端解决方案：

使用 Worker 线程：主流小程序支持 “Worker 线程”（如微信小程序的 Worker），将耗时计算移至 Worker，逻辑层专注于处理交互和数据同步。例（微信小程序）：

javascript

运行

// 主线程（page.js）
const worker = wx.createWorker('workers/processor.js');
worker.postMessage(largeData);
worker.onMessage((res) => {
  console.log('处理结果：', res);
});

// workers/processor.js（Worker 线程）
Worker.postMessage = function(res) {
  const result = heavyComputation(res);
  self.postMessage(result);
};

优化数据通信：小程序逻辑层与渲染层的数据传递有性能开销，避免频繁发送大数据，可合并更新或使用 setData 局部更新。
避免同步阻塞 API：优先使用异步 API（如 wx.request 异步请求），避免同步 API（如某些文件读取的同步方法）阻塞逻辑层。

总结

JS 阻塞渲染的根源是 单线程模型下的任务串行执行，设计上是为了保证 DOM 操作与渲染的一致性。浏览器和小程序均受此问题影响，但可通过 拆分任务、使用 Worker 线程、优化 DOM / 数据操作 等方式缓解，核心是让主线程（或逻辑层）保持 “轻量”，优先处理渲染和交互任务。

7、为啥选择flutter而不是uniapp，uiapp有啥性能瓶颈，可以怎么监测，如何解决问题

选择 Flutter 还是 UniApp 取决于项目需求（如性能要求、跨平台范围、开发效率等）。两者的核心差异体现在技术架构上：Flutter 是 自绘 UI 框架（直接操作渲染引擎），而 UniApp 基于 WebView / 原生渲染混合架构（依赖各平台原生组件或 Web 渲染）。以下从选择原因、UniApp 性能瓶颈、监测及解决方案展开分析：

一、为什么选择 Flutter 而非 UniApp？

性能更接近原生Flutter 跳过平台原生组件，通过 Skia 引擎直接绘制 UI，渲染链路更短，动画流畅度（尤其是复杂交互、高频刷新场景）优于 UniApp。对于游戏、图表密集型应用、高性能交互页面（如手势操作），Flutter 优势明显。
跨平台一致性更强Flutter 的 UI 组件完全自绘，在 iOS、Android、Web、桌面端表现高度一致，无需为不同平台适配样式。而 UniApp 依赖平台原生组件（如微信小程序的 view、text）或 WebView 渲染，不同平台可能存在样式 / 行为差异（需写条件编译代码兼容）。
更接近原生开发体验Flutter 使用 Dart 语言，语法类似 Java/JavaScript，支持强类型和 AOT 编译（发布时编译为机器码），运行效率高。而 UniApp 基于 JavaScript（弱类型），依赖 JIT 解释执行（小程序端有部分编译优化），在复杂业务逻辑下可能出现性能损耗。
生态更聚焦原生体验Flutter 官方提供丰富的 Material/Cupertino 组件，社区插件更倾向于原生能力集成（如相机、传感器）。UniApp 生态更侧重快速开发和多端覆盖（尤其是小程序），但深度原生能力需依赖第三方 SDK 或原生插件，集成复杂度较高。

二、UniApp 的性能瓶颈（核心原因与场景）

UniApp 的性能瓶颈主要源于其 混合渲染架构 和 JavaScript 执行模型，常见场景包括：

1. 渲染性能瓶颈

WebView 渲染限制：H5 端和部分小程序（如早期微信小程序）依赖 WebView 渲染，复杂 DOM 结构（如长列表、多层嵌套）会导致重排 / 重绘耗时，滚动卡顿。
原生组件通信开销：App 端使用 nvue（原生渲染）时，JS 逻辑层与原生渲染层通过桥接通信，频繁的数据更新（如每秒多次 setData）会产生通信延迟，导致动画掉帧。
样式计算开销：UniApp 的样式解析依赖平台原生或 WebView 引擎，复杂选择器（如多层嵌套 class）、动态样式（频繁修改 style）会增加计算耗时。

2. 逻辑执行瓶颈

JavaScript 单线程限制：UniApp 的 JS 逻辑运行在单线程（类似浏览器主线程），复杂计算（如大数据处理、复杂算法）会阻塞 UI 渲染，导致页面卡顿。
setData 效率问题：小程序端更新数据必须通过 setData，其内部会触发数据深拷贝和 diff 计算，频繁调用或传递大数据（如长列表全量更新）会导致性能骤降。

3. 启动与包体积瓶颈

冷启动耗时：App 端需加载 WebView 或原生渲染引擎，且 JS 代码需解析执行，首次启动时间可能比 Flutter（AOT 编译）更长。
包体积膨胀：UniApp 依赖各平台 SDK 和渲染框架，若集成多端适配代码或大量插件，包体积可能比 Flutter 更大（Flutter 自带渲染引擎，但基础包体积也较大，需按需裁剪）。

三、UniApp 性能问题的监测方法

官方工具监测
- HBuilderX 性能分析：内置 “性能分析” 面板，可记录页面加载、setData 耗时、网络请求等指标。
- 微信小程序开发者工具：通过 “性能” 面板录制操作，查看 JS 执行时间、渲染耗时、setData 调用频率及耗时（重点关注 “长任务”）。
- UniApp 调试工具：App 端可通过 vconsole 或官方调试工具查看内存占用、页面切换耗时。
API 与埋点监测
- 使用 performance API（H5 端）或小程序的 wx.getPerformance() 记录关键操作耗时（如页面初始化、数据处理）。
- 埋点记录 setData 调用次数和传递数据大小，检测是否存在频繁或冗余更新。
实际场景测试
- 测试低端设备：在 Android 低端机型（如 2GB 内存）上测试滚动、动画等场景，更容易暴露性能问题。
- 压力测试：模拟大量数据（如 1000 条以上列表）渲染，观察帧率（目标 60fps）和内存占用。

四、UniApp 性能问题的解决方案

针对上述瓶颈，可从 渲染优化、逻辑优化、工程配置 三方面入手：

1. 渲染优化

优先使用原生渲染（nvue） ：App 端用 nvue 替代 vue 页面，减少 WebView 开销，尤其适合动画和交互密集页面（注意 nvue 语法限制，如仅支持 flex 布局）。
优化长列表：
- 使用 recycle-view（UniApp 官方长列表组件）或 vue-virtual-scroller 实现虚拟滚动，只渲染可视区域项。
- 避免列表项嵌套过深（建议不超过 3 层），减少渲染树复杂度。
减少动态样式：
- 避免频繁修改 style，优先通过 class 切换样式，利用 CSS 硬件加速（如 transform: translateZ(0)）。
- 复杂动画使用 animation 或 transition，而非 JS 定时器驱动（减少 JS 与渲染层通信）。

2. 逻辑优化

拆分 JS 长任务：
- 用 setTimeout 或 Promise 拆分复杂计算（如循环处理大数据），避免单次阻塞超过 50ms。
- App 端可使用 Worker（plus.worker）处理耗时任务，避免阻塞主线程。
优化 setData：
- 减少调用频率：合并多次 setData 为一次（如用对象批量更新）。
- 减小数据体积：只更新变化的字段（如 setData({ 'list[0].name': 'new' })），避免传递整个大对象。
- 避免在循环中调用 setData：先在内存中处理完数据，再一次性更新。
懒加载与预加载：
- 路由懒加载：通过 pages.json 配置 lazyCodeLoading: "requiredComponents"，只加载当前页面所需组件。
- 图片懒加载：使用 lazy-load 属性，滚动到可视区域再加载。

3. 工程与配置优化

减小包体积：
- 移除未使用的插件和代码（通过 HBuilderX “代码检测” 功能）。
- 图片、字体等资源使用 CDN 加载，而非打包到本地。
启动优化：
- 延迟初始化非首屏资源（如在 onReady 后加载第三方 SDK）。
- App 端开启 “启动图优化”（splashscreen 配置），减少白屏时间。
使用性能更好的第三方库：
- 数据处理用 lodash-es（树摇优化）替代全量 lodash。
- 图表渲染优先选择 u-charts（轻量）而非 ECharts（体积大，渲染重）。

总结

选择 Flutter：适合对性能、跨平台一致性要求高的场景（如原生 App、复杂交互应用），但开发成本较高，需学习 Dart 语言。
选择 UniApp：适合快速开发多端应用（尤其是小程序 + App + H5），开发效率高，但需注意规避混合架构带来的性能瓶颈。
UniApp 的性能问题可通过 原生渲染、虚拟滚动、优化 setData、拆分长任务 等方式缓解，多数场景下能满足中小应用需求；若性能要求极致（如游戏、高频动画），则 Flutter 更有优势。

8、uiapp编译出来的代码为啥和原生不完全一致

UniApp 编译后的代码与原生应用（如 Android 的 Java/Kotlin 或 iOS 的 Swift/Objective-C 代码）存在差异，核心原因是其 跨平台架构设计 决定了它无法直接生成与原生完全一致的代码。具体可从以下几个层面理解：

一、技术架构：UniApp 是 “中间层转换” 而非 “原生直接生成”

UniApp 的核心目标是 “一次编写，多端运行” ，其实现依赖 “中间抽象层” 对代码进行转换，而非直接生成各平台的原生代码：

原生应用：直接调用平台底层 API（如 Android 的 View、iOS 的 UIKit），代码与系统 SDK 紧密绑定，性能和行为完全贴合平台特性。
UniApp：通过一套统一的 Vue 语法（模板、逻辑、样式）描述 UI 和业务，编译时根据目标平台（如微信小程序、Android App、iOS App）转换为对应平台的 “可执行代码”，但这种转换是 “适配性转换” 而非 “原生等价转换”。

例如：

开发时写的 <view> 标签，在微信小程序中会被编译为小程序的 view 组件（基于小程序的原生渲染引擎）；
在 App 端（Android/iOS），若使用 WebView 渲染，会被转换为 <div>；若使用 nvue 原生渲染，会被转换为对应平台的原生控件（如 Android 的 TextView、iOS 的 UILabel），但转换逻辑由 UniApp 框架控制，而非开发者直接编写原生代码。

二、跨平台适配：必须兼容不同平台的特性限制

不同平台（如小程序、Android、iOS、H5）有各自的 渲染引擎、API 规范、权限限制，UniApp 为了实现多端兼容，编译时必须对代码进行 “妥协性处理”，导致与纯原生代码不一致：

渲染引擎差异
- 微信 / 支付宝等小程序有自己的 自定义渲染引擎（非 WebView 也非纯原生），组件行为（如事件冒泡、样式优先级）与原生控件不同，UniApp 编译到小程序时必须遵循其规范（如 bindtap 而非 onclick）。
- H5 端依赖浏览器 WebView 渲染，受限于 DOM 和 CSS 规范，与原生控件的渲染逻辑（如布局计算、动画实现）完全不同。
- App 端的 nvue 原生渲染虽然调用平台原生控件，但为了统一多端语法，会对原生控件的能力进行封装（如统一使用 flex 布局），屏蔽了部分平台特有属性（如 Android 的 match_parent、iOS 的 contentMode）。
API 能力抽象UniApp 提供的 uni.xxx 系列 API（如 uni.request、uni.navigateTo）是对各平台原生 API 的 抽象封装。例如：
- uni.request 在 H5 端对应浏览器的 fetch 或 XMLHttpRequest；
- 在微信小程序端对应 wx.request；
- 在 App 端可能对应 Android 的 OkHttp 或 iOS 的 NSURLSession。这种封装为了统一接口，必然会舍弃部分平台特有参数或行为，导致与原生直接调用 API 的效果存在细微差异。
权限与安全限制小程序和 H5 有严格的沙箱限制（如小程序不允许直接操作本地文件系统，H5 受浏览器跨域限制），UniApp 编译到这些平台时，必须遵守其安全规则，导致功能实现方式与原生 App 不同（如原生 App 可直接读写本地文件，而小程序需通过特定 API 且有路径限制）。

三、性能与体积权衡：无法做到原生级的精细化优化

原生应用可以针对具体平台的硬件特性（如 GPU 加速、内存管理）进行精细化优化，而 UniApp 作为跨平台框架，编译时需兼顾 “通用性” 和 “性能”，导致代码无法达到原生级的优化程度：

代码冗余：为了兼容多端，编译后的代码会包含大量条件判断（如 #ifdef MP-WEIXIN）和适配逻辑，增加代码体积，而原生代码只针对单一平台，可做到极致精简。
渲染链路更长：UniApp 的渲染需经过 “框架层解析→平台 API 调用→原生控件渲染” 的链路，比原生应用的 “直接调用原生 API” 多一层转换，即使是 nvue 原生渲染，也无法完全消除这部分开销。
动态性妥协：UniApp 依赖 JavaScript 作为逻辑层语言（动态解释执行），而原生应用多使用编译型语言（如 Kotlin、Swift，直接编译为机器码），在复杂逻辑的执行效率上存在天然差距。

四、总结：差异的本质是 “跨平台统一性” 与 “平台原生性” 的取舍

UniApp 的价值在于 降低多端开发成本，通过统一语法屏蔽平台差异，但这种 “统一” 必然以 牺牲部分原生特性和一致性 为代价。编译后的代码需要适配不同平台的渲染引擎、API 规范和安全限制，因此无法与纯原生代码完全一致。

如果追求 100% 原生一致性，需针对各平台单独开发原生应用；而 UniApp 则是在 “开发效率” 和 “原生体验” 之间做了平衡，适合对跨端需求高、原生特性依赖低的场景。

核心原因：架构的根本不同

我们可以用一个生动的比喻来理解：

原生开发：就像在 本地用当地材料和工匠盖房子。
- iOS用Swift/Objective-C和CocoaTouch框架。
- Android用Kotlin/Java和Android SDK。
- 结果是两栋用不同蓝图、不同材料、但功能和外观相似的房子。
UniApp/跨平台框架：就像用一个 万能施工队和预制板 在不同的地方盖房子。
- 你只用一套指令（Vue.js语法）告诉这个施工队怎么盖。
- 施工队到了iOS和Android工地后，用当地的“原生材料”（原生控件）组装出你想要的房子。
- 结果是两栋外观和功能很像的房子，但建筑的工艺、接缝处、以及一些细节肯定和纯本地工匠盖的不一样。

下面我们从技术层面分解这种“不一致”的具体原因：

一、渲染机制：映射而非直接调用

这是最根本的差异。

	原生开发	UniApp
原理	直接调用原生控件。你写的代码直接创建和操作 `UIView` (iOS) 或 `View` (Android)。	JavaScript映射为原生控件。你写的Vue模板，被编译成JS Bundle。运行时，UniApp框架通过渲染引擎将你的组件描述翻译成对应的原生控件。
结果	你得到的是 100%纯正的原生控件。	你得到的是 “由框架生成和管理的” 原生控件。这个映射层虽然尽力模拟，但无法100%覆盖所有原生控件的特性和行为。

例子：你写了一个 <button>，UniApp 会把它映射成 iOS 的 UIButton 和 Android 的 Button。但这两个平台上的按钮在默认阴影、点击涟漪效果、字体渲染上就有先天差异，UniApp 只能尽力统一，但无法改变它们的本质。

二、JavaScript桥接：性能与功能的权衡

UniApp的逻辑（JavaScript）和UI（原生）运行在不同的环境/线程中。

通信成本：当你的JS代码需要更新UI（比如改变一个文本），它需要通过 JS Bridge 将指令和数据序列化，传递给原生端，原生端再反序列化并执行。这个过程是异步的，有性能开销，也增加了复杂性。
能力限制：所有对原生功能的调用（如相机、GPS）都必须通过Bridge预先封装好的API。如果你需要一个非常新的、冷门的原生特性，而框架尚未封装，你就无法直接调用，必须等待框架更新或自己编写原生插件。原生开发则可以直接使用平台提供的任何最新API。

三、UI组件的抽象与统一

UniApp的目标是“一套代码，多端运行”，这意味着它必须 抽象和归一化 不同平台的UI差异。

最低公分母效应：框架提供的组件，通常是iOS和Android上都有的功能的交集。如果一个UI特性只在Android上有，而iOS上没有，UniApp可能就不会暴露这个属性，或者需要做特殊的兼容处理，导致行为与纯原生不同。
自定义组件：UniApp的自定义组件最终会被渲染为原生视图。但它的布局系统、样式系统（虽然大部分CSS支持）毕竟不是原生的布局系统（如Android的ConstraintLayout, iOS的Auto Layout），所以在复杂布局和动画上可能会有细微的差异。

四、编译与构建过程

UniApp的源码（Vue/JS）需要被编译成一个 JS Bundle。这个Bundle不是一个平台原生的二进制可执行文件，而是一个需要在 JavaScript虚拟机（如JSCore、V8）中解释执行的文件。

原生应用：代码被编译为机器码，直接由操作系统执行，效率极高。
UniApp应用：启动时需要初始化一个JS运行时环境，加载并解释执行整个JS Bundle，这导致了更长的启动时间和运行时性能开销。

具体的不一致表现（举例说明）

页面切换动画：
- 原生：iOS的从右向左滑入、Android的从下向上淡入是平台标准。
- UniApp：虽然可以配置，但默认会尝试统一动画效果，可能无法做到与每个平台的100%原生感觉一致。
下拉刷新：
- 原生：iOS的 UIRefreshControl 和 Android的 SwipeRefreshLayout 视觉和触感完全不同。
- UniApp：<scroll-view> 的刷新可能使用一套自定义的实现，或者在两个平台上模拟其中一种风格，导致与另一个平台的原生应用显得“格格不入”。
输入框：
- 原生：在iOS和Android上，软键盘的弹出行为、与输入框的交互、工具栏都有细微差别。
- UniApp：框架层需要处理这些差异，有时可能无法完美复制所有原生行为，比如键盘弹起时页面推起的精确高度。
性能表现：
- 在快速滚动长列表、复杂手势交互、高频动画等场景下，由于JS Bridge的通信开销，UniApp应用的流畅度很可能不如纯原生应用。

如何监测这些不一致？

并排对比：在真机上同时运行你的UniApp应用和一个功能相同的原生Demo应用，仔细观察交互、动画和视觉细节。
使用原生调试工具：
- Android Studio Profiler / Layout Inspector：查看UniApp生成的视图层级结构，与原生应用对比。
- Xcode View Debugger：同样可以检查iOS上的视图层级，看看UniApp生成了什么样的原生视图。
性能分析：使用上述工具测量FPS、内存占用和启动时间，与原生基准进行对比。

总结

UniApp编译出来的代码与原生不一致，是 “跨平台” 这个目标与 “原生体验” 之间必然存在的权衡。

它用“一致性”换来了“开发效率” ：你只需要写一套代码，就能获得两个平台大致相同的应用。
它用“抽象层”模糊了“平台细节” ：这简化了开发，但也不可避免地丢失了一些平台特有的棱角和光泽。

因此，技术选型时务必明确：

如果你的应用追求极致的性能和完美的原生体验，并且不介意维护两套代码，选择原生开发。
如果你的应用以业务逻辑和内容展示为主，追求快速开发、快速上线、成本可控，并且可以接受在UI/UX上做出细微妥协，UniApp是一个非常好的选择。

飞美

1、什么是块级作用域

核心特点

常见场景示例

1. if 语句块

2. for 循环块

3. 独立代码块

与函数级作用域的区别

关键注意点

2、作用域有哪些

1. 块级作用域（Block Scope）

2. 函数级作用域（Function Scope）

3. 模块作用域（Module Scope）

4. 全局作用域（Global Scope）

补充：词法作用域（Lexical Scope）

3、先var后let会报错吗？反过来呢

1. 先 var 后 let 会报错

2. 先 let 后 var 也会报错

关键总结

3、声明提升是到哪里？函数有声明提升吗？

一、声明提升到哪里？

二、不同声明方式的提升规则

1. var 变量提升

2. let/const 变量的 “提升特殊性”

3. 函数声明提升

4. 函数表达式（非声明）无提升

三、关键总结

4、a._proto_和a.的this为啥不一样

核心原因：this 指向调用者，而非定义位置

示例分析

1. 直接通过 a 调用时，this 相同

2. 为什么会觉得 “不一样”？

3. 特殊情况：箭头函数

总结

5、b.xxx=a.xxx是怎么影响b的this，为什么

具体分析

1. 当 b.xxx() 调用时，this 指向 b

2. 对比 a.xxx() 调用时的 this

3. 若单独调用 b.xxx 函数（脱离 b），this 指向全局对象

为什么会这样？

特殊情况：箭头函数

总结

6、浏览器的js为啥会阻塞渲染，为啥这么设计，小程序有这个问题吗？如何解决的？

一、为什么浏览器的 JS 会阻塞渲染？

二、为什么这么设计？

三、小程序有这个问题吗？

四、如何解决 JS 阻塞渲染的问题？

1. 浏览器端解决方案：

2. 小程序端解决方案：

总结

7、为啥选择flutter而不是uniapp，uiapp有啥性能瓶颈，可以怎么监测，如何解决问题

一、为什么选择 Flutter 而非 UniApp？

二、UniApp 的性能瓶颈（核心原因与场景）

1. 渲染性能瓶颈

2. 逻辑执行瓶颈

3. 启动与包体积瓶颈

三、UniApp 性能问题的监测方法

四、UniApp 性能问题的解决方案

1. 渲染优化

2. 逻辑优化

3. 工程与配置优化

总结

8、uiapp编译出来的代码为啥和原生不完全一致

一、技术架构：UniApp 是 “中间层转换” 而非 “原生直接生成”

二、跨平台适配：必须兼容不同平台的特性限制

三、性能与体积权衡：无法做到原生级的精细化优化

四、总结：差异的本质是 “跨平台统一性” 与 “平台原生性” 的取舍

核心原因：架构的根本不同

一、渲染机制：映射而非直接调用

二、JavaScript桥接：性能与功能的权衡

三、UI组件的抽象与统一

四、编译与构建过程

具体的不一致表现（举例说明）

如何监测这些不一致？

总结

1. 先 `var` 后 `let` 会报错

2. 先 `let` 后 `var` 也会报错

1. `var` 变量提升

2. `let`/`const` 变量的 “提升特殊性”

核心原因：`this` 指向调用者，而非定义位置

1. 直接通过 `a` 调用时，`this` 相同

1. 当 `b.xxx()` 调用时，`this` 指向 `b`

2. 对比 `a.xxx()` 调用时的 `this`

3. 若单独调用 `b.xxx` 函数（脱离 `b`），`this` 指向全局对象