可以尝试 Google 或者 1.1.1.1 的 DNSoverHTTPS 接口，自己解析然后直接用，自己解析走的 HTTPS 就可以直接走代理了。

@ysc3839 camo.githubusercontent.com 是 GitHub 的反向代理地址，上游图片文件地址失效了这个地址也就显示不出来的。
上游图片文件的真实地址要进 README.md 文件里点 Raw 看源码里显示的才是，域名是 ovefvi4g3.bkt.clouddn.com 。

两家都不怎么用的吃个瓜

@ysc3839 你那个仓库里面 README 的图都是外链的第三方的图片地址……跟 GitHub 没关系吧？

感觉语义上的不同，len() 更像是进行测量、获取长度这个动作，而 .len 更像是读取一个已经存在自身上的一个属性，.len() 也是进行测量、获取长度这个动作。
len(x) 和 x.len() 的区别是，一个是别人来测量自己，一个是自己测量自己。
len(x) 没有办法预先确定要测谁的长度，所以只能每次都重新数一下。而 x.len() 就可以直接把自己的长度存起来，变化的时候改一下就行，每次返回保存的值就行。这么看来，x.len() 的设计更好。
PY 里面的 len() 比较聪明，不会自己去数，而是调用 __len__ 直接抄答案……

支持
请求方法还有 PATCH HEAD OPTION 之类的建议加一下

2001:4860:4860::8888
2001:4860:4860::8844
8.8.8.8
8.8.4.4
1.1.1.1
1.0.0.1

常年三个系统，Windows Debian MacOS 来回切，没有一家独大的道理，每个系统都有优秀到离不开的软件。
开发软件，各个平台都有自己的用户受众群体，比如你想做一个给普通人用的小工具，那么你不可能用 Linux 开发，Windows 用户才是你的受众群体，当然 Mac 的用户量也不少。
一个软件多个平台测试过才算是合格的。

我移动 4G 一直正常

建议先看官网文档。把文档中的示例都看懂，语言就学的差不多了。学着官方文档里的风格去写，可以适当发展自己的风格。
亲亲，这边建议您写代码的时候把 Ctrl 键或 Command 键扣掉哦～
GitHub 之类的上面的代码都是有作者自己风格的，不一定代表官方推荐，不一定是好的。

1 Google 是商业公司，不是慈善机构，广告是他们收入来源之一
2 在你看到 Google 有广告就觉得不可思议，破坏了你心目中光辉形象的时候，是不是要自己反思一下双膝已经离不开地面了？ Google 也是要挣钱吃饭的！投广告赚钱没有什么不妥。
3 百度因为医药广告害人之后，成为了反面教材，而当时有人指出 Google 上也存在医药广告，但是 Google 上面的医药广告不是给钱就能发的，要审核资质证明的，所以结论是 Google 的广告相比百度成为了正面教材。这件事听听就好，Google 的广告至少不会害死人。

老手无所谓，但默认 root 用户会让新手习惯所有操作都直接跑，以至于到非 root 环境就不知所措了。
其次，除了非常底层的操作服务以外，没什么业务服务需要 root 权限的，都是非 root 能启动的。比如监听端口 80、443 这些低端口的问题，也是有非 root 的解决方案的，只不过大家习惯了碰到问题直接 sudo ……
以 root 去启动服务，等哪天中个挖矿病毒，就该后悔了……然后去投诉他们为啥要默认 root 用户？
默认非 root 用户，出问题了你也怪不到他们身上，毕竟没给 root 权限你强行获取，那是你自己的问题。

原生的 Web Components 会是官方支持的未来，只是现在 HTML Imports 被弃用暂时替代解决方案 ES Module 还不太成熟（ ES Module 已经比较成熟，但是应用在 HTML Imports 相关方向时暂时还没有比较好的实践，得继续观望）。
而 React VUE Angular 这些第三方框架的必然会在未来 Web Components 成熟后采纳一些原生的解决方案。
比如样式隔离问题，现在三大框架的解决方案只有两种，一种是给样式 class 类名加 hash，一种是加前缀，各个子组件不使用 id，以保证在复杂庞大的页面下样式互相不冲突，带来的问题就是样式类名又臭又长，或是太过随机。而原生的 Web Components 则在浏览器层面直接对样式进行隔离，不同子组件之间样式 class、id 都可以冲突而不相互受影响。
还有就是未来一定会出现越来越多的基于 Web Components 的第三方框架（目前貌似就只有 Google 的 Polymer 做了好几年了比较稳定），YouTube 就是采用的 Polymer 框架，根据浏览器支持情况选择 Polyfill，目前看起来已经很成熟了。
---
前两天在看 Chrome 弃用 Web Components v0 的讨论，感觉国外在生产实践中应用这个技术的已经有很多了，以至于 Chrome 必须推迟删除 API 的决定。