eurkidu 最近的时间轴更新 eurkidu 最近的时间轴更新 | eurkiduV2EX 第 338485 号会员，加入于 2018-08-04 14:45:13 +08:00 |
| 想请教下懂硬件的大佬，给旧电脑升级的方案提供下意见 硬件 eurkidu 2023-08-31 19:39:23 PM 最后回复来自 liprais | 35 |
| 系统用久了 coreaudiod 显示占用 2G 多内存，有人遇到过么 macOS eurkidu 2020-12-11 08:46:57 AM 最后回复来自 CharlesLu | 5 |
eurkidu 最近回复了
46 天前 回复了 xyxc0673 创建的主题 程序员 2025 年 10 月小程序开发的最佳技术栈是什么？ |
@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 方式直接选择手机文件。
用 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 方式直接选择手机文件。
参加一下
买个自动合盖的那个立式的牙膏，我们家就用那个，按一下就出来一截，手放开，就自己截断+合盖了，而且没有从下面挤还是中间挤的烦恼，他底下是个硬的立管，平时放，就直接立在台面上
2024-09-04 18:44:29 +08:00 回复了 imherer 创建的主题 推广 2024 自家红心猕猴桃上市了， 中秋送礼佳品，送 v 站福利回帖抽奖！ |
分子+1
2024-05-22 17:20:19 +08:00 回复了 giffgaffman 创建的主题 推广 T 楼！送 5 张英国 giffgaff（TG 群同步再抽 30 张） |
分母 + 1
2024-05-13 13:41:14 +08:00 回复了 imherer 创建的主题 程序员 请教一个 Vue 请求后端 API 顺序问题 |
@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
}
```
可以直接写一个计算属性，按照 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
}
```
2024-05-13 13:26:29 +08:00 回复了 imherer 创建的主题 程序员 请教一个 Vue 请求后端 API 顺序问题 |
按现有逻辑
方案一，现有逻辑，类似 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 实现的，分页触发只会在用户手动切换分页的时候触发，初始化的时候因为第一页逻辑自己控制，可以灵活的处理各类情况。
方案一，现有逻辑，类似 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 实现的，分页触发只会在用户手动切换分页的时候触发，初始化的时候因为第一页逻辑自己控制，可以灵活的处理各类情况。
2024-03-14 10:23:00 +08:00 回复了 1800ml 创建的主题 Apple 有 Mac、Win 双修的老哥吗 关于快捷键适应问题 |
@foolishcrab #8 同，都用外接键盘的情况下，mac 可以把 opt 跟 cmd 对换，这样复制粘贴这些操作，就跟 win 一致了，不过如果用 mac 内置键盘的话，还是得大拇指，不过我用的多，好像也还习惯了，就刚切过去的时候会容易按错，过一会就好了
2023-12-13 18:09:09 +08:00 回复了 hzlzh 创建的主题 macOS [福利] iOS & macOS 福利放送， 150 位， 5 选 1 |
分母+1, 试试
2023-08-28 17:12:26 +08:00 回复了 eurkidu 创建的主题 硬件 想请教下懂硬件的大佬，给旧电脑升级的方案提供下意见 |
@JayZXu #22 恩是的，我也怕 CPU 不升到时候跑不动星空，毕竟最低配置要求写着 6800k ，我都没达到
不过上面 V 友的建议我综合想了下，按自己着预算，真配台新的，估计也就 4070 差不多，70ti 估计要加钱了
那或许可以先买个 4070 的显卡，如果可以别的都不换，插上能好自己用，那可以分段式购物，先用着看看，瓶颈了，就再换剩下的板 U
笔记本的话，我印象中，同级别的显卡，也达不到桌面端的水平吧，主要我也没便携的需求
不过上面 V 友的建议我综合想了下，按自己着预算，真配台新的，估计也就 4070 差不多，70ti 估计要加钱了
那或许可以先买个 4070 的显卡，如果可以别的都不换，插上能好自己用，那可以分段式购物，先用着看看，瓶颈了，就再换剩下的板 U
笔记本的话，我印象中，同级别的显卡，也达不到桌面端的水平吧，主要我也没便携的需求
Select Language