@wngllskjegc 我的经验可能不太有参考价值，我在来日本之前就已经自学了很多年日语了，所以来日本基本上的交流是没问题的

你直接把录制的标签页搞到独立的窗口里不就行了。。

建议 LZ 换个思路，直接转用全局鼠标手势，推荐老牌强大的软件 StrokesPlus，内置脚本引擎功能非常强大
https://www.strokesplus.net/

关于标签切换这个，作为老 Firefox 用户是真的有一万句话要说。以前旧 Firefox 在切换标签这方面比任何浏览器都好用——支持在任何地方按住鼠标右键然后滚滚轮进行顺滑的标签切换，用过的人都知道这方式切换标签是多舒服多方便

但是新 firefox 的插件系统不再支持，换了很多方法之后我放弃在浏览器里折腾，转成用全局鼠标手势了

通过 strokesplus 的设置，当使用浏览器的时候，鼠标下滑是快速关闭当前标签，上划是快速恢复关闭的标签，按住鼠标右键滚滚轮是随意切换标签，不同的浏览器都有统一的操作逻辑，非常舒服

同时对非浏览器程序鼠标下滑我对应成了 alt + f4，平时关闭窗口很舒服，有兴趣的话可以尝试下

@love 颜射。。。。老哥你。。暴露了。。

去肯定要去，但是异地恋是真的困难，尤其还是美国这时区，你白天她晚上，她白天你晚上，女方要是出点问题或者心情低落想找你安慰，非常大几率你会错过。然后虽然老套但这时候身边其他人就很容易趁虚而入，反过来也一样。如果动不动在对方熟睡的时候一个电话过去谈心，对对方来说都是巨大的折磨。更何况你女友还在字节工作，加班厉害更需要良好的睡眠。。。

本来想 1K 预算说直接买 Asus TUF-AX3000 就行了

仔细看才注意到 LZ 是想 1K 买两个，那的确超预算了

@fucUup 老哥建议你再仔细看看我想说的内容，我和你要讲的东西根本不是一回事，你讲的是整体的管理，我讲的是具体到每个服务内代码的修改怎么提 pr

打比方具体来说项目要求给某 api 增加个字段，一般建个 feature/add_field 分支改好代码就行了，但是因为项目要求彻底细分 pr，所以会要求将这一个变更内容拆分成 feature/add_field_change_model，feature/add_field_change_repository，feature/add_field_change_service 等等分支，review 完成之后合并入 feature/add_field 分支，等全部代码都确认没问题后再合并到 master 或者其他环境分支


那么我请问你，feature/add_field_change_model 我改了模型但是上层没有改导致 api 单元测试失败了，我该怎么办？顺便一提因为这些细分的分支只是合并入 feature 分支，所以不会影响环境里跑的服务

@fucUup ？？？？这都想不明白？？？一个 api 修正，其中模型，repository，service，api，swagger 的变更必须拆分成不同的 pr 。你模型，repository，service 这些地方的结构或业务逻辑变了，上面的 api 逻辑没变，单元测试不是有非常大几率失败？这不就是细粒度分太细导致的单元测试失败？
还有 swagger 是根据 api 请求的结构体自动生成的，api 请求的结构体是在 api 辩证的 pr 中被修改。那么请问自动生成的 swagger 文件 diff，是应该和请求结构体的变更一起提交呢，还是单独提交呢？
细粒度分太细是真的经常出一些问题

公司的一个项目，提 pr 会用 github actions 自动进行单元测试，不通过直接打回，同时还会对提交的代码进行 linter 检查，不合规范也是打回，并且要求提交的 pr 细粒度必须小。但问题是，pr 小细粒度和单元测试必须通过经常是冲突的，感觉一个功能完成并合并需要的时间成倍增长

不过有得必有失，作为项目来说这么做的确是有好处的

@sagaxu 师傅别念了别念了

路过提醒下，这里是整个学校总空间只有 100T

分到每个用户估计给个几十 G 就谢天谢地了

那些很多上教育车的人估计会直接被管理员清理账号

@a7dog VSC 也只是编辑器，基于文本的查找替换行，但是涉及到变量重命名这种场景的时候，是需要编辑器分析理解整个项目代码的，这种重量级的功能需求还是主流 IDE 才行

所以说这不就体现了 IDE 的优点了

用 IDE 的话把 User 改名了，它会自动分析其他代码将所有引用了 User 的地方自动改成 Staff

寸照片->照片容灾备份

s3 冷备份 0.002 刀一 gb，寸照片应该是非常稳了