相比 Reader，BR 提供的额外功能不多，主要是 lines()和 readLine()

readLine()必须要有缓存 Buffer 机制，试想如果一次读一个字符，直到读到\r\n，那 IO 操作太频繁了；如果一次读 N 个字符，如果中间遇到了\r\n 后面的咋办，肯定不能丢，倒不如弄个 Buffer 存进去

请他去次大保健，不计前嫌，依然是朋友。。。

用的 RedisInsight，感觉还行

之前用的 Redis Desktop Manager，在 Win 高 DPI，展示的很奇怪
AnotherRDM 也用过，尼玛字体太奇怪了，完全没有等宽体，而且那种打印字体，看着很不舒服

@Heroininu
@spacebound
@MozzieW
@luckyrayyy
项目就是个 CRUD 项目，没有大资源，全是 class 和文本文件，一般也就四五十兆（我对比了之前的）。

再说一个第三方 jar，1M 的都算是已经比较大的了，很多都是几百 k 甚至几十 k

在屎上雕花雕久了，感觉自己慢慢的也不嫌臭啦

这个不复杂，倒不如自己写一个，也花不了多少时间
关键是你好不容易找了一个，用了一下发现不适合

1945 年入广岛

我也 27 岁，从 13 年底到现在，已经干了快七年的 Java 了，工资才 1 万五六
一事无成，快废了

非大佬，用的 OkHttp 封装的对外
JDK 自带的 HttpClient 用过，但是在 TLS1.3 的情况下有 BUG，弃用了。不过过了这么久 BUG 可能已经修复了，如果后面有新工程准备用这个重新封装。

对内的话，直接 Feign 了，管他底层是用的 Apache 还是 OkHttp

不用 Apache HttpClient 的原因是，一个模型太复杂，没仔细去看里面详细的东西，文档也不好，官网就几个示例，不像 OkHttp，就一个统一的 OkHttpClient 一把梭；还有一个问题就是版本兼容性不好，4.4 的 API，4.5 发现就编译报错了。

@stevenhawking
假如你想访问 abc.js
开了 gzip，没有开 gzip_static，nginx 取到 abc.js 文件，然后压缩一把返回给客户端（ nginx 可能会缓存压缩后得内容，下次直接返回压缩过的内容，这个只是我的猜测，不确定）
开了 gip 并开了 gzip_static，nginx 会检查有没有一个叫 abc.js.gz 的文件，如果有，直接返回这个文件内容；如果没有，跟上面的逻辑一样，自行去压缩。

管他多大，都是文本文件，压缩后会变得非常小，nginx 会直接返回压缩后的文件

用 compression-webpack-plugin 和 brotli-webpack-plugin 打成 gz 和 br 包
nginx 开 gzp_static 和 br_static

大家有多少非常重要的数据？

System.out.println(org.apache.commons.lang3.StringUtils.leftPad("123", 12, '0'));

现在的 Java 项目不适合容器部署和微服务部署了。
一个是镜像太大，一个镜像随随便便几十兆，这还不算 jdk 那一层
二是内存占用大，一个 Spring Boot 项目，起起来几百兆没了，运行一段时间，即使没有访问，也得 1G 多

Quarkus 提供了 GraalVM 编译，运行内存和镜像大小变得超级小

另外 Spring Boot 那一套有点臃肿了，Quarkus 基于 Vert.X 变得更加轻量

反正我是这么理解的

前端项目，指定依赖库的地址，要缀上具体版本号

https://cdn.jsdelivr.net/npm/[email protected]

后台运行的各种 docker 容器，全部指定上小版本号，不用 latest 或者大版本号这种 tag

一个 major 版本升级，如果没有做 API 向后兼容，直接能搞垮一个项目

我发现这种东西，只要用顺手了，都好用。
Navicat，HeidiSQL, MySQL Workbench, DataGrip 都用过

最近一直在用 Datagrip，因为我喜欢深色的主题