我之前也纠结过，现在认为针对这种缩写形式，可能看成一个单词更好。
参考 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 的，但应该没关系，毕竟鼠标的速率极低）

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





建议攒钱加预算。Bose QuietComfort Earbuds ，贵，但是个人极其满意。

@WeiYuanStudio @fl2d 感谢。放弃了

@miyuki 搜了一下，完全看不懂

数组是引用、指针，arr[0]===arr[1]

“final AtomicInteger a= new AtomicInteger(0) 的 a ，由 0 变 1”
a 既不是 0 也不是 1 ，而是一个 AtomicInteger 实例，一直都是这个实例，没有变过
如果我写了一个 final CustomClass c=new CustomClass(arg1,arg2,arg3)
那么我的 c 就一直是这个 CustomClass 啊，你把 AtomicInteger 和数字直接连起来了，但其实它们是分开的

Java 试了下（ jshell 复制以下内容），确实如此

```
import java.text.SimpleDateFormat;
Date date = new Date();
new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(date);
new SimpleDateFormat("YYYY-MM-dd HH:mm:ss").format(date);
```

结果：

```
$7 ==> "2021-12-31 10:55:50"
$8 ==> "2022-12-31 10:55:50"
```

每次看到这种帖子，都想吐槽下那些不用时间戳传递和记录时间的，出问题的机会少太多了

同后端，看一遍《精通 CSS 》，够用了

骑电动车过斑马线肯定是有责任的，之前 v2 上有个老哥骑着自行车过斑马线被交警警告过，不过责任多少和赔偿还要看情况

同上，密码管理器就 ok
修改 cookie 过期时间应该没什么用。就比如 java web 使用默认的 session 配置的话，30 分钟内没有请求服务器也就清空了你的信息了，再之后就算你拿着相同的 JSESSIONID 去访问也没用了。
如果是 jwt ，最长时间应该就由不得你了吧。

emmmm ，推荐一下孙卫琴的《 Tomcat 与 Java Web 开发技术详解（第 3 版）》，仅供参考，仅供参考。。。。