兄弟重点搞错了，这和 V 不 Vue 没关系，就绝大部分业务而言，当你出现非自愿加载的性能问题时，先考虑业务逻辑是否有问题，其次看看是否存在 bug 。
前者你得说出来大家才好帮你判断，后者不看代码我们也帮不了你，你要实在不会排查的话，可以使用终极 debug 大法：二分注释法

1. 多查历史价格，蹲低价。
2. 关注性价比品牌（大品牌的低端 /性价比线，同配置价格便宜非常多），比如：
冰箱-容声（美的）
空调-华凌（美的）
洗衣机-统帅（海尔）、小天鹅（美的）

另外不要过分追求国外大牌 /龙头品牌，这些不是什么高端玩意儿，国内也能做的很好，不要一味的追求西门子、东芝、林内、三星这些 “高端货”

1. 当你的组件比较复杂的时候，options 的形式很难进行代码的拆分，容易写出上千行的巨型组件（ mixins 的缺点不多阐述了）。
2. 就“代码拆分难”这个点，除了容易产生巨型组件，还有“组件逻辑复用难”的问题。
3. 更好的 TypeScript 支持。

至于结构清晰这个点，仁者见仁。

简历上挂 github ，作为面试官的话我觉得只要上面存在有意义的内容，不论难度高低，都是加分项。

至于什么是有意义的，我认为包括但不限于以下这些：
学习某种技术留下的代码；
自己平时工作中抽象和提炼的代码；
一些有趣的 /有意义的 /富含创造力研究实现或 demo ；
能够实际提高生产力的工具或项目；
甚至可能没有自己的项目，但是在社区的其他项目中有贡献；

star 不是关键，但是不得不说，star 高会更引起别人点进去看的欲望。

这没啥好纠结的吧，
项目是写来学习的：你想学啥用啥。
项目是要上生产的：你最擅长啥用啥。

不必过多在意网上各种框架之间的对比，绝大多数情况下各流行框架之间相比不会有什么明显的短板，A 能干的 B 也都能干，何况你说你的业务还不难。

日经贴....为什么大家都接受不了香菜 /折耳根？我觉得很好吃啊....
香菜没有做错什么，你我也没错，只是每个人因为自己的生活环境和习惯不同（原本的技术经验 /理念不同），所以会对同样的东西会有不同看法

如果说要硬啃几何方法来实现，要么参考 fabric.js 的源码（ fabric.js 也并不完全准确），要么报出有偿金额请图形学大佬帮忙了，不然估计你问不出个结果来....

一回事啊，和叠不叠起来没关系，赋予颜色值的新 canvas 是原样把原 canvas 再绘制一遍，该什么层级还是什么层级，你要做的只是将新画布上对应点的颜色和你预先生成的颜色做对比就行，这个是画板类应用的常见处理方式

补充：假设你有一个画布，上面有一个圆一个正方形。那么你绘制的时候可以绘制两个 canvas ，一个是你正常显示的 canvas1 ，另一个 canvas 中为内部元素赋予随机颜色值，例如正方形红色，圆形绿色，然后把这个 canvas 给 display none ，我们命名为 canvas2 。最后鼠标点击的时候，获取到鼠标坐标，通过该坐标在 canvas2 中获取到对应位置的颜色值，如果是红色就代表点在正方形上，绿色就表示点在圆形上，以此类推

额，这个问题其实很常见，可以参考 konva.js 的做法，核心在于：为 canvas 中每一个元素赋一个随机的颜色（但不显示），然后通过对比鼠标点击位置像素的颜色值来判断。

网友：Angular YYDS
现实：公司让用什么你就用什么

继续上面的补充：
https://router.vuejs.org/zh/guide/essentials/dynamic-matching.html#%E5%93%8D%E5%BA%94%E8%B7%AF%E7%94%B1%E5%8F%82%E6%95%B0%E7%9A%84%E5%8F%98%E5%8C%96

你的案例在 Vue 官网上已经说得非常明白了。

@BaiLinfeng 当然呀，一般情况组件只有被载入的时候会初始化一次，例如第一次加载，例如从 v-if="false"到 v-if="true"后。各个生命周期也就是在这时候开始执行的。

1 、从上个问题和这个问题的示例就能看出来，OP 完完全全不理解 MV*，正确的做法 #5 已经说的非常非常非常清楚了。
2 、首先明确一个点：OP 绑定 key 的目的是让子组件重新渲染，以此到达重新执行生命周期的目的。且不说你的例子中是否真的有重新执行生命周期的需求，即使真的有，也不该使用这种手段，举个例子：

正常的做法：
```
// 父组件
<template>
<ChildA :count="count" />

<button @click="count = count + 1">add</button>
</template>

<script lang="ts" setup>
import { ref } from 'vue'
import ChildA from './ChildA.vue'

const count = ref(1)
</script>
```

```
// 子组件
<template>
<div>{{count}}</div>
</template>

<script lang="ts" setup>
import { watch } from 'vue'

const props = defineProps({
count: {
type: Number,
required: true,
},
})

const func = () => {
console.log('render')
}

watch(() => props.count, func, { immediate: true })
</script>
```

OP 的做法：
```
// 父组件
<template>
<ChildA :count="count" :key="count" />

<button @click="count = count + 1">add</button>
</template>

<script lang="ts" setup>
import { ref } from 'vue'
import ChildA from './ChildA.vue'

const count = ref(1)
</script>
```

```
// 子组件
<template>
<div>{{count}}</div>
</template>

<script lang="ts" setup>
defineProps({
count: {
type: Number,
required: true,
},
})

const func = () => {
console.log('render')
}

func()
</script>
```

后者的问题：
①不易理解（特别是新手）。
②性能问题。
③最重要的一点，由于可控的粒度过大，很容易导致 BUG 。因此能 watch 解决的一般都不会选择这样去操作。

3 、继续强调刚才提到的一个点，OP 很多 [重新执行生命周期] 的需求根本就是伪需求，在之前的例子中完全没有必要，在本帖的例子中也没有必要（如#5 所讲的）。其实只是一个子组件接收父组件响应式数据的简单问题，就更没有必要绑定 key 强行让子组件重复渲染了。

@yezheyu #20 这种情况你不需要绑定这个 key 啊，父组件传递的 data 发生了改变，User 中接收的 data 这个 prop 自然会跟着变。楼上让绑定 key 只是为了让组件重新渲染从而达到重新执行生命周期这个目的，这是一种偏门骚操作，除非有什么极其特殊的需求（反正我没遇到过），不然绝对不推荐这么做，而你的需求只是最基本的父子组件传值而已，当然也不该这么做，如果有取值以外的副作用需要执行，正常 watch 就行。

这就是最基础的父子组件啊，首先 props 的定义是必须的，不理解 OP 为什么会选择用 attrs.name 这种方式来取父组件的值..

其次`User 组件内部的代码只会执行一次，`console.log` 不会随着 button 的点击事件执行多次`，这是当然的，和响应式无关，不管 name 变不变，console.log 肯定都只会执行一次。如果需要在 name 变化时执行一些副作用，watch 是最正统的方式，#8 的方法不建议...#16 的方法可行，但这明显更倾向 React 的思维

好奇请问下 OP ，独立开发小程序的收益能够填补上微信每年认证费用和服务器 /Serverless 相关的费用吗？

试试阮一峰周刊

学校期间可能有用，出了学校没用（除非你打算开公司）。