@codingbody 30L 建议查一下你女朋友和你的 A_I_D_S ， 因为肺_部_真_菌_感_染并不是一个常见病。 结婚的话，婚_检真的非常重要

- 问 v2 网友 - ✅
- 咨询三甲医院的专家 - ❌

@goodspb gtk-rs 解君愁

@kop1989

作者有权利对自己的作品做任何的调整以及任何的改变。不包括享有一下权利

1. 删库
2. 重命名自己的库名
3. 创建和之前同名的资源库
4. 不维护自己的代码

MIT 协议原文

```
特此授予任何人免费获得本软件和相关文档文件（“软件”）副本的许可，不受限制地处理本软件，包括但不限于使用、复制、修改、合并 、发布、分发、再许可的权利， 被许可人有权利使用、复制、修改、合并、出版发行、散布、再许可和 /或贩售软件及软件的副本，及授予被供应人同等权利，惟服从以下义务。
```

作者所做的事情，并未违反任何的 MIT 协议。MIT 本来就赋予了其他的在分发权利， 至于你说的无法找到对应的 fork ， 我不知道这到底违反了 MIT 协议的哪一条？

给作者扣了一个大帽子

- 他在恶意抹杀他 MIT 许可的程序。并且阻止其他人扩散。
- 他抹杀了帮他 debug ，以及完善代码（提交和并请求）的人的功劳。

这句话等于就是，你以前每年给我赞助了 50 块钱，那么你以后年就要给我攒 50 块钱，如果你那一天穷到一无所有了，你也必须给我赞助钱，

否则你就是

- 你在抹杀公益行为，并阻止此公益行文的其他人传播
- 你是在抹杀那些帮做公益的人，以及这种公益行为中的各种人付出的心血

Talk is cheap. Show me the code. 如果你真的想说作者不负责，请自己写出来一个比这个更好的东西，去指着这个作者，例如 git 一般，否则你没有做任何贡献之前，你没有资格去指着一个曾经对开源社区有贡献的人。


开源的作者不仅仅有自己的项目，还有生活的琐事，每个人的生活都不容易，生活都很艰难，当你知道你创造的东西被商业公司抄袭，并且还直接用 CDN ，没有人会开心。

我支持作者的行为，同样也希望开源和商业能够完美的结合在一起。找到一个真正的出路，而不是为爱发电。


--------------------------------------

最后我和讨厌给别人扣帽子的人， 如果你讨厌作者，你可以做比他更好产品，如果你使用了作者的东西，请给予支持和鼓励，哪怕是语言上的鼓励作者也不会放弃。

作者的删库， 没有一个使用这个库的人是无辜的

@godbasin 如果你真的想系统的学习一下前后端联调。 那么我建议你看看 http 协议 和 websocket 协议

大部分常见的协议就是这些 http and websocket.

如果你 http 协议基础很牢固，那么所谓的

``
代理配置、接口定义等等，还有前端编写异步请求
```

所谓的这些基本上就不是问题了。


什么叫做前端 or 后端， 这种区分是非常不合理的。

例如在前端中的 webassembly 就需熟悉 rust or 其他, webgl 就需要学习 C or C++.

例如 webpack vite ...，就需要 go rust or nodejs ....

@maplecomb 怎么说，很理解你的心情，但是实际上这么其实是由你自己许可的，并非 MIT 协议的问题。

和 Livid 说的一样， 其实你可以和苹果正常的程序沟通，比较耗时。

其次，不知道你有没有自己设计的 Icon 什么的。项目属于 MIT 但是图片版权属于你

因为 SQL 写的再好，比如中间件的一次缓存命中， 如果缓存命中率达到 90% 以上， 那么就不存在 IO 问题。


```
正因为 SQL 写的烂，所以接口性能很差劲，但是他们好像都不在意这些 IO 方面的优化，整天在想着怎么优化语言性能，比如反射、JSON 序列化、语言基础库的性能；要么就是上集群、加缓存，然后又没有任何设计模式，直接业务代码中强硬加入缓存读写，就算是缓存也是先从缓存读出数据，然后遍历一条条去数据库再查出来，性能更差了
```

我不清楚你们的项目结构，不过 IO 在怎么优化是有瓶颈的，为了提高命中缓存， 我觉得不用 in 和 left join 是最好的

@yxwzaxns 回答 4L

所有的语言，无论高低都需要关心内存问题

1. 分配你所需要的内存
2. 使用分配到的内存（读、写）
3. 不需要时将其释放\归还

有一些语言是需要开发者手动明确进行处理的，例如 rust c/c++ , 而有一些是隐含帮你处理例如 Java Go 等等。 但是无论那种你都需要关注内存分配，以及销毁的问题。

例如在 Java 中 常见的内存泄漏


```
Static Vector v = new Vector(10);

for (int i = 0; i < 100; i++) {
Object o = new Object();
v.add(o);
o = null;
}
```

无论是那种语言，开发都需要关注内存回收的机制，以及内存回收的问题。如果不去关注这些。 很容易出一些内存泄漏的问题。

@James369 楼主首先你理解错误了。 或则说你不应该在 Student 释放的时候去做擦除圆的操作。

例如， 我在 Student 释放的同时，去创建 Student 。 那么这个对象将永远无法真正的释放。 例如在释放的时候进行执行大量的逻辑。 显然这是非常影响 gc 的性能行为。

不过你可以在要销毁的时候。 执行其他情况， 你不应该依赖 gc


例如我记得 java 的 gc， 只是做一个垃圾标识， 至于什么时候进行清理，要看 gc 的心情。

例如在 JS 中， 你应该这样

```js
let student = new Student()

// 标记需要回收
delete student;

// free 是你自己自定义的方法，用来编写逻辑，释放你的图片信息，以及擦除圆的操作。
free(student)
```

@yxwzaxns #4L 我想知道 rust 算成熟的语言嘛

v2ex 发贴也需要绑定手机号码了。

@lalalaqwer 别问，问就是 dispatch

我敢说，你们大部分说 webpack 不好用的人多半是把 webpack 当作 html-webpack-plugin 在用。

真的不清楚，webpack 什么时候变成的复杂的构建工具了？ webpack 本身很简单啊

主要就是一个 Entry(入口), Output(出口), Loaders(装载器) 就这三个配置，Entry 和 Output 是主要配置，和传统的 html js css 开发本身就是一样的。


你们为什么会感觉到复杂？

1. 就说 es6 -> es5 里面的转换，就有很多工具， 比如 babel 进行转换，babel 的配置本身不简单， 或者 esbuild 在或者 ts 也就是可以做到的
2. 例如 css 有很多技术栈， 例如 less，sass 还有 styled-components
3. 越灵活的工具，配置就越复杂， 越固定的东西使用越简单，webpack 让你感觉到复杂因为它太灵活了，基本上可以覆盖整个前端的技术栈

我记得上次去阿里，他们内部使用的就是 4k 屏幕啊，导致 antd 在低分辨率的屏幕下显示的特别大。 所以 4k 基本没有问题，低分辨率的情况下也出了一个 antd.compact.[css|less] 完美解决两个问题啊。 你看看官方文档

回楼主， 有， 这个软件叫做 GnuPG , 也叫做 GPG

@eason1874
@lonewolfakela
#17 #18

```
但是 hash 泄露也只是你这家的服务完蛋了，如果是明文密码泄露，用户在其他地方如果用到同样的密码的话很可能一块儿完蛋
```

那就是撞库， 撞库严格来说不算是三方系统的安全问题。（ PS： 准确说被撞的那个系统安全上不作为存在的安全问题）

密码其实是存在泄漏的可能，无论是第三方撞库，还是说人为的泄漏密码，这些都算作系统安全。

如果真的要预防这个问题。 我认为应该从以下方向去考虑

1. 在登入的时候判断用户是否在常用的 IP 地址中
2. 通过浏览器指纹来判断这是否是用户经常访问使用的浏览器
3. 在登入的时候需要采用 RSA 非对称加密算法，将 指纹和密码进行加密， 正式环境的私钥和开发测试的要进行区分
3. 如果有异常情，例如 IP 和浏览器指纹不一致， 并且区别很大（需要用户通过手机或者邮箱进行二次确认）

@eason1874 #14L

在这里骗鬼啊， 前端进行 HASH 的密码。 等于你的密码就是 hash 的值。 运维人员接触到了 hash 密码，直接用过接口测试工具，例如 postman 或者 curl 然后直接参数的密码就是这个 hash 的值， 一样可能登入。 如果为了安全唯一的可能性，就是防止撞库。 防止运维拿着这个密码去碰撞。

弱弱的问一下，有 React 前端的远程吗？

@raptor #33

不知道什么叫做不断重新发明轮子。


- Webpack 的出现，主要是为了解决打包的问题，并且可以配置插件来做一些功能
- React 只不过是一个 JS 操作 DOM，采用虚拟 DOM 来进行操作的，方便了开发人员
- Angular 只不过也是一个 JS 操作 DOM 的库，不过采用双向数据绑定。
- Vue 只不过也是一个 JS 操作 DOM 的库，它减少了 Angular 的复杂度
- PReact Fast 3kB alternative to React with the same modern API.
- Babel 解决浏览器兼容问题

无论从哪个方向来说，这都不是所谓的 `不断重新发明轮子` 每个 JS 库的偏向点都不一样。 他们都拥有自己不同的生态。如果硬要说，类似于 Linux 的分叉，Debian 和 Centos 的区别。Arch 和 Manjaro 的区别