psyer 解决方案非常多, 要根据实际情况来. 反正使用网盘同步是一个馊主意. 核心问题在于文件的数量, 有些项目, 动辄几万个文件, 一旦某一次大范围的修改项目, 就会导致云盘同步非常缓慢, 一旦同步缓慢, 就会导致多端代码不一致, 然后还会出现文件相互覆盖, 最终代码文件丢失. 即便有历史记录的云盘, 想要正确的恢复代码也非常困难, 我在坚果云和 OneDrive,GoogleDrive 使用上都遇到过这个问题, 最终官方给我的回复是他们没有为此种场景优化, 不建议使用他们的网盘同步代码. 核心原因还是这些网盘没有提供.gitignore 这种按需求忽略同步的层级覆盖配置. 坚果云的开发人员说他们正在研究, 最终应该会增加此功能. 不过我放弃了坚果云了. 自己配置了私有云服务器, 自己每天同步到自己的服务器. 而且公司的电脑我也可以直接 SSH 上去. 所以同步代码这个执念我就放弃了.

@Oktfolio Java 这种老古董, 不思进取. 谷歌都在逐步放弃, 现在转也是选择 Kotlin, 选择 Java 才是入坑

@billytom 反正那个蓝牙搜索有时候会不靠谱, 特别是外壳全金属的笔记本, 还有就是蓝牙 5.0 的设备更容易搜索到. 微软很多好用的功能做的太不人性化了. 明明 WIFI 我已经设置为专网模式(速度慢, 可能是因为没有设置这个), 这样就近共享就可以和依靠蓝牙的蓝牙分享合并在一起, 在 WIFI 模式下, 使用局域网共享模式分享文件. 搞不懂微软的脑回路.

@anshigm OneDrive 同步代码是不靠谱的, 特别是有 npm 这种辣鸡, 会出现各种诡异的现象, 而且官方也不建议同步代码, 坚果云也是一样, 我为这个事情还专门发邮件咨询过

@njshiyanhz ITX 机箱对我来说太大, 我在考虑是否自己用 3D 打印来搞个机箱. 大部分机箱都给显卡留了位置, 我感觉那个位置完全是浪费, 我不需要显卡的空间, 因此可以将整个机箱的厚度压小, 散热器是个麻烦, 我还没想好怎么搞, 标准水冷和风冷都太大. 可能是我这个需求太小众, 感觉苹果的 Mac 比较符合我的需求, 奈何它只能 ARM, 我需要 X86

将所有重度运算移动到 Web Worker 中去, 不要再浏览器的主线程上做 CPU 重度操作.

@njshiyanhz 我其实是想找一个和 Mac Studio 差不多大的 Windows 主机, 我现在用的台式机我感觉太空旷了, 里面不插显卡, 大部分都是空的, 而且 CPU 的散热风扇太大了. 感觉有很多优化空间! 不过估计是找不到了

@lawler 这个玩意太小了. 我同事还给他安装了一个散热贴. NUC 要不就是你这种小的, 还有就是特别大的那种. 都不符合我的要求, 我大概需要尺寸和 510S 差不多, 但可以厚 2-3 倍, 性能非常强的. 最好没有显卡插槽, 因为我不需要显卡插槽, 有专门的游戏设备.

@lawler 这个玩意我同事有. 风扇呼呼转. 我想要好的大概尺寸 Mac Studio 差不多大, 性能要够强. 辣鸡微信小程序的开发工具实在太卡了. 我现在回家只要边看视频, 边写代码, 电脑就会非常卡.

@lawler Intel 的 UNC 太大了, 我原来买个联想的 510S, 性能太差, 还特别容易发热. 性能和我的笔记本差别不大.

@Kasumi20 你自己写个测试函数试一下不就知道了

没啥好不好, 看团队怎么确定, 我们团队按照:dev/test/staging/prod 来

并不会降为 30HZ, 不知道你怎么得到这个结论的!

@DOLLOR 他想让编译器给他检查流程, 就是这个函数的返回必须必须即有 string 也有 number, 我目前是没想到有什么方法, 因为这个需求本质也是一种类型运算, 需要编译器检测函数返回类型, 然后组合. 但是目前 TS 似乎没有那个类型本身可用进行这种特殊的类型约束, 因为这个约束类型 never 这种, 需要超越类型本身的信息, 做分支流程检测.

@Building C#的 Task 比较复杂, 并不是简单的协程, 既可以多线程, 也可以单线程

使用一个主线程去发送请求(和 MySQL 打交道, 发送异步请求), 关闭同步上下文, 然后在主线程上发送 HTTP 请求, 然后主线程就等待(用 Task.Delay()), 时间到了再次轮询数据库. 在 HTTP 的 IO 的 Task 上附加成功的后续操作, 这个操着会在线程池中获取一个空闲线程, 然后执行. 一开始配置好线程池的物理线程数量和 I/O 线程数量. 你给出来的信息太有限了, 很难给你分析. 另外真个场景我估计瓶颈不在 CPU, 如果后续操作费事很少, 则 CPU 应该一直空闲, 如果你开启了上下文同步, 则可能导致主线程假死!

这个破帖子一看就是骗积分的:
一切都是权衡, 微软官方有出过书籍, 详细讲解过.NET Framework 的命名规则的各种来源, 非常详细, 也说明了各种权衡的利弊. 不学无术就不要想当然的瞎猜.
对于命名规范这种东西, 只有一致性最重要.
另外每个人都有自己的先入为主, 总是感觉自己最初接触的东西才是最自然最舒服的.
有时间去看看这本书: <<Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries>>.
另外这个世界不是围绕你转的, 每个领域都有自己的约定和习俗, 想当然的强迫别人和自己保持一致属于即幼稚还暴戾.

@waiaan 没啥绝对的好处. 很多时候需要在一个目录树打开多个项目, 而这些项目已经存在磁盘的不同位置上, 如果没有工作区就会非常麻烦, 需要移动文件夹,一些项目甚至对绝对目录有依赖, 一旦移动位置, 就直接无法运行了. 工作区加入的原因和讨论在 VSCode 社区有讨论, VSCode 大部分功能的加入都是有公开讨论的. 工作区还可以跨项目配置 VSCode

@waiaan 工作区是一个逻辑分组, 可以将不同位置的不同目录组织在一个工作树中, 而文件夹是做不到这点的, 文件夹必须和物理磁盘的文件树解构保持一致