如果不用 ai ，至少有个准确的信息来源，有问题作者也知道是怎么个回事，如果文档来源就是 ai 生成的，那有事实性错误作者都不一定知道是怎么回事

@goodryb 我觉得就算要升级我也会优先升级新一代次旗舰卡而非旧旗舰，那样的话功率应该不会暴增到这么高，5090 这种游戏性价比极低的选择我不认为会选（加价 100%甚至 200%，fps 提升远没有 50%，然后我可能还用不到多出的 fps ）他这个配置单我个人感觉是设计给直接升级 5090 的人设计的，好多配置余量，但既然都买了 5080 ，还会有人选择卖了再换吗。。。。（现在闲鱼上有不少 5090 流出，感觉可能是给这种需求设计，但又不好明说让你去买这个渠道）
我倾向于选它前一个配置单，然后升级部分组件，比方说就单纯把板 U 套装换成 9800x3d ，然后再看看其他配置有没有调整的空间（

@tediorelee 也许是我移动设备用多了，对画质要求没那么细（ 720p 到 2k 提升感知明显，2k -> 4k 那我觉得感知不强，更不要说好多游戏所谓 4k 其实渲染分辨率并非全满），或者说 4k 对我的感知提升并不强，但对 dlss/fsr 之类拼好帧技术的厌恶比较大，我受够了 tsr tsaa 那种拖影，dlss 的鬼影，但也不知道最新的 dlss/fsr 提升如何，以及在更高帧率下这些 glitch 是否会不明显

@goodryb
我仔细分析了一下配置单，这个电源功率是不是对于目前配置有点过度了，我怀疑算上超多余量 1000W 也够了，然后这个内存时序在这个价位上是不是有一些提升的空间（也许模拟类游戏也用不到 32G ，但不确定），这个升级内存至 192G 的建议是什么鬼啊，大概是针对生产力用户比较多吧

@asd7160 就是因为看了太多配置单挑花眼了我才想主动问问啊。。。一开始需求就几个字，那不是更难推荐了
@XTTX 1080p 是性能基准，不是说我就不跑 4k 或者高刷了，只是很多游戏 4k 下得靠各种拼好帧技术，然后很依赖优化就不太好对比
@craftsmanship 感谢理解，我也是先有过前期调查才发帖问的
@YZG 至于为啥不先给出配置单，会有一种先入为主的感觉（事实上就是我没有装机的经验，想出的配置单要么是从网上抄的，要么是瞎配没有参考价值），我也就是被配置单看花眼了才来问，网上信息繁杂，有说 A 好，有说 B 好，尤其是非核心配件硬盘/主板/供电的搭配，从不同途径搜索得来都有很大差异，我很难分辨信息准确性，显然这也不是什么看一个天梯图就能解决的问题
不过说起初始想法，我确实也有一些倾向性，比如 9800X3D 为主，显卡 5080 或者 9070XT ，但这也只是型号，而众所周知就算同一个型号也有不同的品牌，这我完全没有经验，显然这部分也是猫腻最多的地方

（原文内容是我写，但是有用 ai 做了润色，但只是将我原文不太准确的描述词汇转换成正确的词汇而已）

kotlin 可以用 java 的 sdk 啊，而且你也可以直接把新代码用 java 写，让 kotlin 调用

chrome 不是可以用 chromecast 吗（当然，需要电视支持）

但其实它也调用不到，因为 chrome 早就实行了区域隔离（开了 sock5 代理和用 fake-ip 的除外）

因为官方说了不再向聊天机器人方向发展，注重写代码和推理

@janus77 并没有基于行，是单纯整个文件对比，之所以可以提交 hunk ，也是前端的处理方式，内部生成虚拟文件提交到树里，这个意义上二进制文件和文本文件的唯一区别只在前端展示方面（后端影响的只有可压缩性，二进制一般不太容易压缩）

@dfkjgklfdjg 这个 diff 完全是根据两个状态对比实时计算出来的，git 并没有记录任何 diff 信息

@dfkjgklfdjg git mv 等价于 mv+git rm+git add ，git 识别文件移动完全靠猜测，并没有特别记录这个信息

限速和丢包有啥区别啊
@yyzh 限速不也是通过丢包实现的吗，总不能为了限速专门搞一套有状态的转发设备吧

null 可以用在联合 unique 约束中表示空缺（因为比较的时候会忽略 null ），但要记得使用触发器或者静态约束来避免插入全空的值
这种模式在表达一些很特殊的关系的时候有奇效

tailwind 的真正优势在于可以通过冒号组合 variant 和 utility ，这解决了 inline style 的一个很大的问题：没法给伪类，伪元素，媒体查询定义样式，然后 variant 也可以定义多个 slot ，这使得很多原本要重复写的代码都可以省去（例如同时用没提查询和类来定义深色模式的样式）
然后 tailwind 也提供了插件机制可以实现更加复杂的组合，类似 daisyUI 那样（当然我并不是很喜欢 daisyUI 的样式）

要是能开源 docker for windows 的那个进程隔离机制就好了，（指 windows silo 简仓）

因为那些产品经理考虑问题只有：哪个功能比较常用/不常用，常用的放外面，不常用的收起来，还信奉不给选项就是好的信条，而从不考虑用户真正的使用体验

@jstony 现在就是这个流程，7 天停服才删，7 天停服都没管，我感觉是作者想跑路随意找了个理由甩锅云服务厂商

安全风险可能存在，但纯前端的风险嘛，基本很少，类似 Next.js 这种后端也跑代码的是真的会出大事的（最近真有）