我开发了 5 、6 年了，基本碰到过的问题都能通过源代码、开发文档解决。
很少去中文技术博客上找解决方案。
很多写技术博客的都是些跟风写博客的菜鸡，肚子没货写的文章也是东拼西凑没什么深度和自己思考的，行文逻辑也是混乱不堪。大部分 v2 上的博客点开来都是这样，《 xxxxx 配置安装》没干活的文章一大堆，心思全都花在了 css 主题样式、换友链上。

并不感兴趣，觉得这个 terminal ui 特别的丑。
标题栏那么肥硕，看着有点呕呕的。
看看 mac 上的 iterm，或者是自带的 terminal

lz 骨子里也有一种嫁出去的女儿==泼出去的水 的恶臭思想。
看你的描述，你农村的父母还是很爱他们的女儿的，能帮的就帮一下，怎么你就没有继承他们这些好的思想呢。

@julyclyde 我们公司上批一起换的 50 多台，拿回去报修的原因只有两个，一个是有杂音，还有一个是键盘粘滞。
自己瞎脑补一通还“大部分几个月就接触不良无法充电了”，也是挺厉害啊，不知道你经手了几台。
大部分电脑要是像你说的这样，苹果还不如去倒闭了。

@julyclyde 松了不是很正常？
耐用性保证的又不是你这个接口用久了会不会变松。
而是测试这个接口能不能正常使用撑住应有的寿命。
你要说充电口差不住，接触端口自动松落这种那就是质量问题。

线缆端头可以左右挪动是多大点破事。外网轻轻一拉能拔出来那再来说质量问题。

@yousabuk
你说电脑包个保护壳、手机贴个膜什么的，我完全可以理解的。
但是你连一个充电口的松紧都要畏首畏尾的，我觉得就是你反应过度了。这些手机、电脑之类设备的接口耐用性在设计之初都会做过测试，保证可以连续插拔几十万次。

另外给你几个建议。

建议买个 502 胶水把 typec 接口堵上，然后所有数据通过无线蓝牙传输，这样 typec 接口 0 损耗。

还有用键盘的时候记得带手套，因为手指上的油会沾在键盘上，然后盒盖的时候容易与屏幕接触导致屏幕涂层脱落。

另外使用笔记本的时候最好在无尘环境下进行，这样灰尘不会被静电吸附在屏幕上导致屏幕划痕。

我 2016 款天天 typec 插拔用到现在一点问题都没有。
插坏了就拿去修 。
这些产品做出来肯定是要做耐久测试的，接口变松完全是正常使用损耗。。
买来当宝贝供起来

等你读完源码，估计会是 0 收获。spring 的源码经过 16 年的迭代，内部实际上已经是非常庞大了。里边很多代码甚至都是为了修复 bug 的。你一眼看过去甚至还会好奇这么写是为什么。

所以最好的实践就是大致过一遍源码，了解一些核心模块的实现逻辑，细节性的东西就 pass，如果想自己去做框架，倒是可以借鉴一下一些细节的实现方法。

spring 说白了就是一套开发框架而已，个人更喜欢把时间精力放到计算机基础、网络通信、jvm 底层相关的方面上去。

硅谷这些核心技术大佬在大公司间跳来跳去的不是很正常吗？
一个芯片设计师离职然后就脑补出这么多。

@BugenZhao windows 上是缩放比的，hidpi 显示逻辑和 macos 的原理是不是不一样的？

@LinJunzhu 是谁给你的错觉说这类二进制反编译不出来。。。？？
只不过难度比 java 成本高而已。不然一堆堆的破解软件补丁是怎么出来的？

客户端搞什么接口签名啊，多此一举。
怕中间人篡改那就上 https。
如果怕用户自己篡改，那这个没辙，签名算法、加密逻辑完全能反编译出来。
面对这种情况，服务端需要做的是保证请求结果处理正确即可。

@zsdroid
看了下源码，好像的确只是建了链接。

HttpUrlConnection 是 UrlConnection 的扩展类，这个接口是把 connect 标注成了 public。
意味着你可以自行扩展其他 UrlConnection，

如果是 HttpKeepAliveUrlConnection 和 Http2UrlConnection 类似这类多个请求复用链接的，想自己搞一个链接池，connect 单独调用就有必要了。

另外 UrlConnection 有一个 FtpUrlConnection，这个 connect()方法就是需要单独调用，因为一些 ftp 服务器需要登录，都是在这个 connect 方法里完成的。

单纯从你的 case 里看，connect()单独调用并没有什么作用，存粹是为了扩展 UrlConnection 这个接口。

正式工 A：哎，B，你手下的外包空吗？能借我用一下吗？
正式工 B：可以，你拿去用两天好了。

又不是所有的 http 请求一定要去往流里读写。
假设你遇到一个场景，只需要调用一下 http 接口，不需要关心结果返回，那你不去调 connect 你怎么连接？

人家说看不懂都只是调侃罢了，真以为学不会呢？
这么跟你说吧，大部分后端，入门一门新东西，大概搭建环境可能也就多点只占 30%左右。
然而前端这边，npm package.json 还算好装，接下去 webpack 和 babel 配置就跟噩梦一样。
好不容易花了大把时间研究文档终于搞出了一个脚手架来，这时候我想用一下类似 antd 之类的第三方 ui 类库，结果发现，要引入一个 ui 类库居然要大改 webpack 和 babel 相关配置。

够折腾

我觉得前端烦就烦在喜欢弄一堆工具。
比如上手 react 吧，新人就要去搞 webpack npm，step by step 先把环境搭起来。
这一步就可能栽坑。
上 google 搜索教程，可能是一两年前的，然后相关的类库、插件的 api 已经变的妈都不认识了。想搞个 hot-reload，结果弄出了一堆的相关配置，每一个看起来都完全不一样，一个个试过去结果全 tm 失败了。

弄好 webpack，然后还要再弄 babel，这个坑更多，配置参数一堆一堆的。

最后找了官方的 create-react-app，结果明明都是同样的 webpack、babel，为什么这玩意封装起来后看着完全不一样。

环境配置阶段就劝退了。

也难怪会有 webpack 配置工程师的调侃。

@binux 所以，不用 restful 就是走泥巴路哦？用 restful 就是拓宽道路走向更远的未来？
我可以研究的东西有好多好多，为什么要花时间在一种设计风格上争论个没完没了？
存粹一个设计风格取舍的问题也能扯到 35 岁。你独清？

真以为现在互联网项目是像以前传统软件开发一样一套代码可以流传个几十年呢？就现在中国互联网开发速度，一套代码能撑五年以上就已经很不错了。基本上转了 4、5 手面目全非，然后等着下一轮重构了。

而且现在架构风格都在往微服务架构方向转，在微服务架构方向下，那些代码解耦合、可扩展、维护性之类的工程方面优势也就没有那么重要。