eurkidu

参加一下

买个自动合盖的那个立式的牙膏，我们家就用那个，按一下就出来一截，手放开，就自己截断+合盖了，而且没有从下面挤还是中间挤的烦恼，他底下是个硬的立管，平时放，就直接立在台面上

分子+1

分母 + 1

@eurkidu 还有一个常见方案，即如果你这个 A 只是 B 表格数据显示的时候，比如某列是字典表，其他配置表，B 返回数据里面存的是 id ，显示的时候要显示成 A 返回里面对应的 name 。

可以直接写一个计算属性，按照 A 返回的数据，生成新的显示数据
```
get viewTableData() {
// 如果能保证 roleData 一定有值的话，加这个可以让 loading 中的表格显示效果更好
if (this.roleData.length === 0) return []
const data = JSON.parse(JSON.stringify(this.tableData))
data.forEach(row => {
row.roleName = this.roleData.find(v => v.id === row.roleId)?.name ?? ''
})
return data
}
```

然后可以对表格加 loading ，A 数据未返回前，表格处于 loading 中，这样就可以不用关心 A ，B 数据的加载顺序，当然这个逻辑比较偏向固定这个逻辑的页面的写法，不适合通用组件封装的逻辑。

按现有逻辑
方案一，现有逻辑，类似 3 楼思路，合并 A ，B 调用为一个新函数 C ，里面对 A 做单例执行，如果 A 数据有值不重复请求 A 数据。

方案二，把 onMounted 里触发的 A ，前置到 beforeRouteEnter ，保证 A 数据加载了之后，再 next 渲染页面，即把 页面 非表格数据的 loading ，前置到 路由的 loading 中，这也是一种常见的写法。

方案三，一般个人写这种页面，不会去 watch 分页参数，或者即便 watch 也会去掉 immediate 触发，因为大概率 页面首次初始化逻辑是不同于切换分页组件的时候触发逻辑的（当然，对于简单的 CRUD 页面来说可能是一样的）。如果不 watch 分页参数，那逻辑就变成自然的，首次渲染 A + B ，切换分页组件的时候，触发 B 的逻辑。

不 watch 分页的一些原因，主要因为 watch immediate 会在组件 created 的时候直接触发，加上如果修改 watch 参数的逻辑因为组件封装的复杂度，导致用户一次操作，同时修改了 watch 对象的 2 个值，并且 2 次修改有类似 nextTick 的分隔，会导致触发 2 次，如果是手动控制的 change ，就可以规避（依稀记得当年 element-ui 1.0 的时代，el-select 的 change 事件是直接类似 watch 的逻辑，每次修改 v-model 的值，都会触发 change ，写省市区级联选择框的时候，一言难尽，后面 v2 版本就直接改逻辑了，只有用户的操作才会触发 change ）

所以 OP 逻辑里面的 分页调用 B ，从封装组件逻辑角度出发，我是不建议直接 watch 触发逻辑的，应该是用户主动切换页码的时候，才触发 change ，可举个简单的例子，比如需要列表跳转 url 进入详情，详情返回列表还是在原来的页码，一般可通过 url 参数保留之前的页码，这时候 页面初始化会带有比如 ?page=2 这样的参数，如果内部分页组件直接 watch 不做特殊处理，那默认请求第 1 页，拿到 url 参数，再修改当前页为第 2 页，则会额外触发一次分页请求，但是如果不是 watch 实现的，分页触发只会在用户手动切换分页的时候触发，初始化的时候因为第一页逻辑自己控制，可以灵活的处理各类情况。

@foolishcrab #8 同，都用外接键盘的情况下，mac 可以把 opt 跟 cmd 对换，这样复制粘贴这些操作，就跟 win 一致了，不过如果用 mac 内置键盘的话，还是得大拇指，不过我用的多，好像也还习惯了，就刚切过去的时候会容易按错，过一会就好了

分母+1, 试试

@JayZXu #22 恩是的，我也怕 CPU 不升到时候跑不动星空，毕竟最低配置要求写着 6800k ，我都没达到

不过上面 V 友的建议我综合想了下，按自己着预算，真配台新的，估计也就 4070 差不多，70ti 估计要加钱了

那或许可以先买个 4070 的显卡，如果可以别的都不换，插上能好自己用，那可以分段式购物，先用着看看，瓶颈了，就再换剩下的板 U

笔记本的话，我印象中，同级别的显卡，也达不到桌面端的水平吧，主要我也没便携的需求