融合套餐拆机比较复杂，如果未来有离开广州打算的话，要慎重办理

支持一下大佬

现在神烦 95187，各种推销电话敢比房地产

这个配置。。大概率装不起来黑苹果
就算有那么一点点成功的概率，系统一定也很旧
而且收费估计比你卖掉机器的价钱都高

前东家，支持一下

/t/749304 联动一下自己的体验

@forgottencoast 这家已经凉了

该来的还是来了

推荐一下 Files
https://files-community.github.io/

公 开 处 刑

有个印象很深刻的项目，充分使用 apollo-client 的 cache 后，前端状态管理变的非常简单（一般业务项目，所谓前端状态管理，基本就是把 fetch 回来的数据存到 store 里面； apollo 的 cache 已经帮你全搞定了）。
这个项目最后只用了 React 原生 hooks / useReducer / context 做状态管理，以及一小部分 apollo local state 。

近 1 年都在和 GraphQL 打交道，接触的方面包括：
1. 前端 apollo client 和后端 node.js apollo server 打交道，后端是重业务代码
2. 前端 apollo client 和后端 graphql ruby 打交道，后端也是重业务代码
3. 前端 react query 和后端 node.js apollo server 打交道，后端是 BFF 层

总结一下个人对 GraphQL 评价
优点：
- schema-driven 的开发流程，衍生出一系列好处：代码生成、精确的接口文档。类比 RESTful 的 swagger 。
- 很容易实现 field 粒度的 ACL
- 良好的类型系统，对 normalization 、cache 、codegen 等都非常友好
- 有官方 spec，不像 RESTful 有各种不同的解读方式（尽管 spec 没有提到分页，但 relay style 已经成为了事实标准）

缺点：
- 各类 HTTP debug 工具支持都很弱
- 大规模 scale out 的实践比较少，缺少成熟的基础设施（ gateway，细粒度监控，日志，限流，等等）
- 很难利用 HTTP cache，需要前端自己实现 cache 系统
- 服务端 n+1 查询问题
- 和 RESTful 一样，只是一种工具，没有官方范式。有人会写嵌套很深的 field，有人会像 RESTful 一样全部扁平化，甚至有人写出来是 RPC style （我见过 root query 顶层 field 全部是 `getXxxByXxx` 的命名风格）
- 使用最广泛的 apollo-client 至今稳定性欠佳，bug 很多

本身 HDCP 也是挑硬件和软件的。不过想必优酷直接都没在 pc 上支持 hdcp 了

很可能电源功率不够

@Celebi 不，# 符号本身没有 sharp 读音，只有 pound / hash / number sign

C# 只是故意借用了音乐里的「升 C 音（ C♯）」的读音
https://en.wikipedia.org/wiki/C%E2%99%AF_(musical_note)

显卡 3070 带不动，建议 4 路 3090

@zartouch 网卡部分，我是用主板自带的 2.5G 网卡 RTL8125 打上 LucyRTL8125Ethernet 驱动有线连上网。然后装了一块 3 年前买的黑苹果网卡（ BCM94360CD，已停产，淘宝上可以随便买一块更好的），只为了用它的蓝牙

@xz410236056
为什么选择了便宜的显卡：因为我没列出机箱里的 3090，它和黑苹果没啥关系
为什么不是 5950X：因为买这套配置时候 5000 系列还没影子呢。搁现在我铁定选单核性能爆炸的 5000 系列