早就换 gradle 了，为什么我的感觉和你相反，maven 简单，快，但是不灵活，gradle 学习难，慢，但是灵活。gradle 学会了慢一点也能忍了。

我们直接用 flink cdc ，mysql ，postgresql ，sqlserver 都支持。

不支持 win

@kahloy clickhouse-operator 还不支持 keeper ，只能自己部署一套 zookeeper

@dbpe 赞同，还不如直接 jpa 加 querydsl ，jooq 也可以但是低半版本数据库收费

有 k8s 了可以试试 https://github.com/Altinity/clickhouse-operator ，只需要自己部署 ck ，然后写个 yaml 就能启动 ck 了，版本升级和配置管理很方便

收藏了

木制的菜板确实好容易发霉，同求

我去知道，我用 rust 开发了安卓的 sdk ，刚好里面有调用命令行的代码，那这样不会也被杀进程吧？

8 块钱的套餐没有停办，只是营业厅不给办，直接电话客服，不给办就工信部，你可以搜一下，我联通刚换 8 块保号套餐

才发现 gradle 支持这个功能，准备把项目都改了。感觉这个功能挺好的。

@InkStone 我没说你前端用 bcrypt 还需要传明文给后端啊，我说的是你前端传了 bcrypt 哈希值的话，后端怎么和前端传过来的哈希值对比，因为 bcrpt 的特性就是每次都是不一样的字符串，所以后端只能保存明文是不是？

所以根据以上结论就是前端使用哈希密码的方式传参数是对后端密码不安全的，所以只能使用对称加密或者非对称加密的算法，所以我之前的说法只是拿 aes 来举例而已。

@InkStone 我是说不赞成前端使用 aes 加密，看清楚哈，前端使用 bcrypt 是认真的吗，前端使用哈希算法，后端保存明文？这就离谱，肯定是前端传输明文后端使用 bcrypt 来做对比。

@InkStone 我没说在前端持久化密码啊，我说的是 bcrypt 哈希是在后端做的并且保存到数据库。

小公司前端加密确实不需要，他们这些大厂加密是因为可以防止大量爬虫和撞库，他们有技术和能力对抗前端代码的反编译，小公司没这个能力，简单的写个 aes 加密直接就反编译出来了，还不如直接使用明文传输，密码保存在数据库使用 bcrypt 算法来做 hash ，这种算法一定程度上防止了被脱裤爆破出用户密码。

我们也有想法去草原，mark

apisix 不推荐
/t/1033395