概念意义上来说，dns 是通过域名换取主机 ip 地址。实现上包括 DNS 报文协议和传输协议，但是概念上并没有规定 dns 的传输实现一定要基于 udp 。

只不过最开始搞 dns 服务实现的人采用了 udp ，然后这个东西推广开了默认成为了事实标准，只不过他没有想到如今的网络安全问题会这么严重。

我之前下了一单 32G 16 寸，后来想想还是退了。。。
intel mac 够我用了，不要给自己加太多需求。

以前有买过。但是不用了。
请问这个东西除了把你的菜单栏占的满满的以外，有什么意义吗？

@christin 都是一样的。

@kikione intern 能解决单机上边的问题，那么如果机器不只一台呢？

Integer a = 999992;
System.out.println(a.toString()==a.toString());

你 run 一下就会发现这个结果在 jdk1.8 以上就是 false 。
不是所有字符串都会建在常量池里

你这有问题。
你如何保证值相同的 userId 字符串对应的是同一个对象？

这东西跟 restful 一样，本身属于是一种架构设计风格。
他们最大的缺陷就是在于想象很美好，现实很骨感。
一旦落地到实际应用里，真按照规范来操作反而会异常的别扭。
所以我的建议是对这些规范适当借鉴吸取，而非全盘照搬。

我很讨厌那些没敲几年代码水平一般，但是整天把 restful 规范挂嘴上的人，一天到晚没事干跑到版面争论业务 code 和 http status code 要不要分开的问题。《狗头》

楼上这些解释都是复读机。

你想想 spring 就明白了，我们在做 spring 相关插件扩展功能的时候，是不是都不需要修改 spring 核心类库的任何代码？
因为 spring 提供了足够多的扩展点能让我们非常方便的实现需求。

所以我们平时写代码时也应该像 spring 一样，通过类似模板等设计模式为变化较多的部分提供充分的可扩展空间。

细化到具体的某个业务么，就是类似支付系统。一开始接的支付宝支付，然后加了微信支付，if-else 可以满足需求。但是如果后边需要对接银联等支付，if-else 就会堆成屎山。在不修改原来业务主流程的情况下，通过扩展多个支付方法子类显然是更优雅的选择。

不过国内的互联网，如果不是搞基础框架、业务中台一类的，搞这些开闭原则啥的其实没多大意义，相反还会徒增烦恼。视项目规模和维护价值自己做取舍。

@joesonw 不是，mac 是用四个像素点来渲染一个逻辑像素点，也就意味着“看起来像 1080”，实际上输出的是 3840x2160 也就是 4k ，如果你的显示器分辨率大于等于 4k ，那么显示起来没有问题，如果你的显示器分辨率小于 4k ，那么显示器会自行调整画面输出。

同样，如果你选择了看起来像 2560x1440 ，那么实际上输出的是 5120x2880 也就是 5k 的分辨率，不管你设备最大分辨率是 1080p 还是 4k 还是 5k ，他都是统一 5k 输出。

windows 和 linux 阵营采用的方式是 ui 缩放，这种方式在非整数比的缩放比例下会有一定的性能损失，好处是开发者并不需要做太多的 ui 适配调整。

昨天去店里看过了表示那个刘海是真的咽不下去。。

大概率会吃灰。
还是散了吧

你的路子走错了。
前端界面上所能实现的东西大多数都是属于可替代性非常强的，根本没必要把自己的代码守的死死的。
别人真的想 copy 完全可以直接重写一套。

电脑上 du df 不是照样很慢么？
查看存储空间的操作需要统计不同类型的内容占用空间和每个 app 占用空间。
也算不上是常用功能，有什么不能忍

macos 下 term 类应用最大的问题就是不能管理机器列表了。。
所以我现在很期待能有一款基于 web 终端的 shell 。。
直接跑在浏览器上，任他是 macos 还是 windows

notability 有个手写公式识别功能，不知道什么时候 goodnotes 也能安排上

test()里 temp 只是一个形参，

我觉得目前国内的互联网公司就和那些房地产一样，想着赚快钱，根本就不会太去注意楼房质量。

国内的互联网起项目完全就是为了进场抢份额，发展的好那么后续多投入点资源，发展的不好直接掐掉。
什么高质量有的没的，根本不 care ，项目问题多了就推到重构。