eurkidu

赞同楼上的一些说法，我 475+75 散光，配过好多副眼镜，之前有一副因为前一副眼镜突然坏了，急着配的，就随便找了个连锁品牌跟着店员挑了下，就有比较明显的楼主说的这种边缘形变的情况，看地上方格地砖线，非常明显。

当时店员说正常的，戴一段时间适应下就行了，后来也确实神奇，戴了一周多之后，确实适应了，就不那么明显了。

后来多了解之后，有说法是人脑的自适应能力非常强，其实当时配的眼镜就是没那么适配，具体原因可能就像楼上有些说的球面非球面啥的，或者其他的一些细节参数有问题，所以一开始戴上发现有问题，其实就是有问题，后面戴久了，看不出来，就是人脑自动校准了，不过这个适应能力可能因人而异。

我现在戴的后面专门医院验光，然后线上配的蔡司的镜片，就没出现过这个情况了。建议楼主重新配一副。

@tanranran #12 +1 ，前两个月刚新调研开发过微信小程序，uniapp 只开发小程序，就可以不用 hbuildx ，那个实在用不来。

用 https://unibest.tech/ 建的项目，UI 库选的 wot-ui, 整合了下 https://demo.wot-design-uni.cn/ 的部分功能，开发体验跟普通 vue web 开发差不多。

当然因为有些小程序跟 uniapp 的限制，还是有些限制的，特别是二次封装组件，因为不支持 listeners 透传，以及插槽透传也有坑，封装起来非常难受，直接单纯写业务页面+业务组件，用起来倒是还挺好

虽然是只开发微信小程序，但相比用原生选 uniapp 开发，除了原生语法外，还有个有小优点（算是遇到的一个坑，因为是 uniapp 开发的解决起来比较方便）

就是我们开发的页面需要上传用户附件，是 PDF 的那种附件，微信小程序选择文件的 API 有限制，你选图片之类的，可以直接单独拉起相册，但是你上传文件，就只给了一个从聊天文件中选择的 API

导致小程序原生页面只能做成，用户先要把文件发到文件传输助手，然后再选择的效果，后面查了半天说小程序原生页面没辙，只能跳转一个 web-view 页面，使用 web 方式上传文件，这时候可以直接选择手机文件，但是这时候要单独新写一个项目去写一个文件上传页面，上传完之后再把文件地址返回给小程序，就挺麻烦的。

这时候灵机一动，因为 uniapp 可以直接打包成 web 页面发布，所以就直接在小程序项目里面，写了一个文件上传页面，但其实是 only for web 的，然后把项目重新打包发布成 web ，小程序里面再 webview 嵌套用于上传，这样直接一个项目就全搞定了，上传代码逻辑还都是同一份，因为后面跟产品讨论，做成选择了用户既可以从聊天文件中选择（方便电脑发给手机的文件），也可以用 web 方式直接选择手机文件。

参加一下

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

分子+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 内置键盘的话，还是得大拇指，不过我用的多，好像也还习惯了，就刚切过去的时候会容易按错，过一会就好了