解决问题的方法就是把鼠标接收器放在离鼠标接收器旁边。
上面有人提了，powerplay 就是这么干的，实际上我印象中似乎你买鼠标的时候罗技好像也会送延长线来着。总之就算好的鼠标，也只能这么解决。

还有，restful 是个好的参考标准。虽然实际中设计的 api 很难完全符合 restful 标准（有个词叫“反模式”？），但在能使用 restful 的时候就应该使用。

为什么？因为每个人的设计思路都不一样，不遵照一个标准就会遇到各种牛鬼蛇神。
你今天可以抛弃 http method 不用。推而广之：
1 、url 只有一个请求路径字符串，太弱了，我要定义自己的结构，自己写请求分发器发到不同的处理方法。
2 、https 是公开的，安全性不行，我要用自己的加密方法。
3 、反正是传递信息，websocket 双向通讯，不比你 http 强

restful 能在各种 api 设计里脱颖而出，如果真的有人认为自己的接口标准能打败他，那自然更好，赶紧亮出来给大家开开眼。

先不说 restful 的事，“https 用 post 更安全”这个论点是错的。因为 https 里，信息都加密了，外部甚至连用的什么请求方法都不知道，要有问题就是加密前解密后的问题。

比较安全性必须得说清楚原因。

post 比 get 安全是真的，因为请求参数如果放在 url 里，那么浏览器的收藏功能啥的就有可能把这个 url 记录下来，而不是因为 https 传输过程的问题。而且，对于用户名密码这种场景 get 不适用，但对分享链接就很合适（比如搜索引擎，把关键字放在 url 的查询参数就很合适）。因此，对应的场景使用对应的请求方法是有道理的。

但 post 和 put 、patch 什么的，把信息放请求体里就没有这个问题。

想咨询下，vscode 的 java 扩展会生成.classpath 、.eclipse 什么的文件吗？之前项目里经常看到这些，但应该 idea 生成的

没有用过 go ，稍微尝试过 nodejs 和 python 的 web 框架。
真的不能和 java 的打，感觉楼主被喷是因为指向性太强了，干脆说“在场的各位都是垃圾”算了。

@infinityv 要推荐的话我就推荐现在的 35 克 82 键了。
布局的话，我认为 82 键应该是最好的了。全键盘太长了，每次打完字，右手去摸鼠标都得移动好长一段距离，非常的费力，而且主键盘区得往左放，要不然鼠标就得放得很右边，非常不舒服。
换了 87 键上这个问题缓解了一些，但还不够彻底。目前在用的 82 键，主键盘区就在正前方，感觉挺好。（感觉 87 键的控制键区浪费了不少空间，82 键的就是一个竖条，挺好的）
再往下缩就是垂直方向去掉 f1~f12 了，这个我不能接受，所以就选 82 的了。

至于克数，这个我觉得确实看个人喜好更多一点，有人觉得 35 轻，有人觉得 45 重，我是后一种。

目前有 4 把键盘：赛睿 Apex Pro 104 键（非静电容）、宁芝 35g87 键、燃风 45g87 键、宁芝 35g82 键（购买时间顺序）。最终选择宁芝，手感最喜欢。
说真的，网上看视频、听人描述、读评论其实都不准确，键盘体验店又没有。估摸着楼主最终还是要买几块自己来试试才知道。

@Newyorkcity 不了解 angular ，但看起来是用了跟 vue 一样的属性选择器实现的，我就按 vue 的猜了。

你写的一个组件，有类似 html 的结构和对应的 css 。它只会给你写的 html 里加上_ngcontent-fqf-c83 属性（和你的组件对应），然后给你写的 css 里加上[_ngcontent-fqf-c83]选择器，你引用的 select 组件内部的 html 里并不会有_ngcontent-fqf-c83 这个东西。

所以，你最终生成的 css 选择器应该是.specific[_ngcontent-fqf-c83] .mat-select-panel 这样的，这样既能给当前组件里面的 select 换样式，又不会影响其它地方的 select 。所以主要问题就是要告诉编译器.mat-select-panel 是子组件里面的，不需要加[_ngcontent-fqf-c83]

@Newyorkcity angular ？搜一下对应的深度选择器语法吧

单身， 衣服是我妈买的

我之前也纠结过，现在认为针对这种缩写形式，可能看成一个单词更好。
参考 Url （ Uniform Resource Locator ）、Id （ Identity ）、Http （ Hyper Text Transfer Prtcl ），虽然是缩写，但含义已经极其明确，你全大写和首字母大写都可以。
个人感觉 Dto 、Vo 、Bo 的形式比较合理。（在一定上下文环境中省略前缀后）变量就是 dto 、vo 、bo （这里要特别吐槽一下阿里的 DO ，如果全小写会变成关键字 do ，所以我用对应的 PO ），要不然变量叫 dTO 、vO 、bO ，总感觉怪怪的。
写到这里，回去看了一下自己的项目，发现目前用的是 UserVO 这种写法，一般对应的变量直接叫 vo ，如果多个 VO 同时出现，那么会写成 userVo ，感觉也挺舒服。。。

个人来说，喜欢 Linux 区分大小写的设计，但考虑收益，在重装 macos 时我选了 case-insensitive 的。
1 、大小写不敏感的设计并没有给我带来太多负面影响，因为绝大多数情况下，我都不会建两个只有大小写有差别的文件（如果不是有人提，我可能一辈子不会注意到 windows 和 macos 是大小写不敏感的，毕竟大小写不敏感不等于没有大小写）
2 、如其它人说的，macos 上 steam 等软件可能会在 Case-sensitive 的环境中出现问题，这是一个明显的减分项
3 、考虑到 macos 和 windows 默认都是大小写不敏感的，那么也就意味着其它人的电脑最有可能是大小写不敏感的，那即使我在用 Linux ，也会尽量避免分享给别人 a 和 A 这样的两个文件
4 、建立 Git 仓库时、npm init 时、设计 api 时，写 maven 的 groupId 时，一般建议使用中划线命名法，所以我大概也已经习惯了
总体来说，我个人感觉，大小写不敏感的设置不会对开发造成明显影响。调整一下你自己的命名方法可能相对来说更好、更方便，收益更佳

看了一下，感觉问题不大。
人家估计没想过要做一个 youtube 的国内版，估计只是“领导让做个网页版，咋做？抄抄 youtube 吧”这种

没坑，这么好的软件，一年才 200 多美元，续费还有优惠，简直是超值

最烂：《超能查派》，真 tm 后悔熬夜看这种 XXX

火星了。2020.1 刚出的时候就装了，更新到现在，翻译的质量已经挺好的了，不是纯机翻
总体来说，装了以后开发效率提升很大（看的懂英文，但没法快速把单词映射到意思）

https://dcsuibian-public-resources.oss-cn-hangzhou.aliyuncs.com/img/Xnip2022-01-06_20-14-06.jpg

vscode 就没有问题

@Rheinmetal
后来又测试了下，不是设备间干扰，而且不光干扰了 2.4G 信号
（把所有设备断电，接收器直插笔记本）还是有干扰，而且 4G 信号也有很强的干扰（移动慢，电信、联通直接断网，5G 没问题）
而同一房间的另外一边，一切正常、顺畅，似乎只有我这一角有问题
应该是建筑物周围有什么东西，还没找出来，准备找相关人员看看（真想不通除了信号屏蔽仪外，什么设备会产生这么强的干扰）

@Rheinmetal
所有 2.4G 的设备都卡，trackpad 和键盘都已经用有线连接了。鼠标没法有线，用延长线连过去但还是略微有点卡。（延长线是 3.0 的，但应该没关系，毕竟鼠标的速率极低）

最近搬家了，同样的设备在之前的地方就没什么问题。不知道问题出在哪儿。