Mojave 的话，cmd+shift+4 截图后，也可以直接圈圈画画了。
cmd+shift+5 可以选窗口、鼠标显示、甚至可以录像，基本够用了。

如果只是为了发 QQ 或微信，那还是 App 内置的方便。

https://wx4.sinaimg.cn/mw690/6129589dly1fwwbwrgboij20kg0eqtby.jpg

楼主: "衰落已经是方方面面了"
@Actrace : "这几年销量不行只能靠抬高售价来`维持`市值"

Mojave 才遇到，最频繁是微信。

自营一般分两步，京东写得很清楚：快递运上门但不允许拆。后续上门安装的是厂家的安装人员，必须由安装人员开箱安装否则出问题需要自己承担。因为上门时间不固定，那京东快递就没有意义了，所以我不愿意在京东买电视。

至于开箱后外观验收，当场不看那自然是自己背锅。。

@liuyinltemp 信号不好，不一定是基带来背锅。
这代 iPhone 射频+基带、天线功能都比华为的要好，但天线布局有问题，这是华为工程师说的： https://www.zhihu.com/question/295605303/answer/509512705

@liuyinltemp iPhone7 以后基带都是混用高通和 Intel 的，信号差不一定怪基带和芯片。。
根据 FCC 报告，实际上这代 iPhone 的基带和射频表现非常好，天线也很厉害，但整合起来栽了跟头。。

上面有人提了历史原因、知名度、企业支持、或者 "出问题找人背锅" 之类的。。。

我提一个其他的原因：
Winzip 现在是全平台的应用啊，有 Mac、iOS、Android、各种命令行版本，没道理把 Windows 给砍掉啊。。
总有人会为这个企业买单的。

通篇充斥着偏见和立场。。

看第一条吧，Chrome 最近也改了圆角，Chrome 的书签栏设计乱改了好几版，Google 自己的设计语言也在不断改动。然后说 Mozilla 内部的开发路线 “至少早期” 是相对混乱的。

再看第二条，" Chrome 不断限制扩展插件的自由是事实，但是又有多少人记得 Firefox 当年在扩展上走的弯路" 我要换个立场来说，就可以改成 "Firefox 当年在扩展上走过很多弯路，才带来了现在的扩展生态，而 Chrome 却不断限制扩展插件的自由，来不及迁移新接口的插件就不能用了"。

再看第三条，Chrome 不清楚 Google 的 Cookie 这么大问题一句话带过，然后对 Firefox 默认主页浓墨重笔并在没有证据情况下推断带有 "中国特供版的私货"。实际上 Chrome 默认主页也好导航搜索也好，都是 Google 搜索。

后面内容懒得再评价了。我自己一直坚持用 Chrome，偶尔 Safari，但文章里的那些理由我一条都没吃到。。

@TomasKozey 从京东买了个兼容电池自己换上了。本想着换失败了就有理由买新机子了，结果用到现在还好好的。。

@ultimate010
巧了，我也是 14 款 15'mbp，只要有电源就插电源，循环也一百多次，损耗也非常小，也没外接显示器。几个月前就突然鼓包了，鼓得非常厉害，但从软件层面看怎么看都很健康。

@jiang1234321

0.1 和 0.9 用二进制表示的话，都是无限循环的，但内存中的 double 只有有限位数，所以要做截断并 rounding 到最近的一个二进制，这里损失了精度。

"0.1" 解析后是 0x1.999999999999ap-4
"0.9" 解析后是 0x1.ccccccccccccdp-1
"1" 解析后是 0x1p0
1-0.9 实际在内存中的计算是 0x1p0 - 0x1.ccccccccccccdp-1 = 0x1.9999999999998p-4

直接写的 0.1 和经过计算得到的 0.1 在内存中的数值不相同，相差 2 ulp。

0x1.999999999999ap-4 转换为十进制时，是 0.1000000000000000055511151231257827021181583404541015625，print 会截断到 0.10000000000000000，舍去结尾的 0，就是 0.1。

0x1.9999999999998p-4 转换为十进制时，是 0.09999999999999997779553950749686919152736663818359375，print 会截断到 0.09999999999999998。

上面的这些 0x 开头的数值是用 Hexadecimal 格式写的，等同于 double 在内存中的实际数据。

@CEBBCAT https://www.exploringbinary.com/topics/ 见 "Correctly Rounded Decimal to Floating-Point Conversion" 这部分的文章。

CSAPP 可以作为基础知识来了解一下，精度究竟是如何损失的、损失结果是怎么样的，这部分就没有介绍了。

把字符串解析为 IEEE754 浮点数，是非常复杂的事情，vc、gcc、jdk 甚至 libc 的 strtod 都出现过 bug。
IEEE754 浮点数运算，又是另一个话题了。

可以仔细看一下 IEEE754 浮点数标准与计算过程。精度损失主要集中在这几个地方：
1. 大部分十进制表示的小数，是不能完全精确的由二进制的 IEEE 浮点数表示出来，编辑器解析字符串的过程中会有 rouding 过程。
2. 打印的时候，二进制大部分情况也不会完全用十进制表示出来，printf 会做舍入和截断。
3. 浮点数计算的过程中，可能会有精度损失。
可以在 https://www.exploringbinary.com/floating-point-converter/ 转换来看看。

"0.1" 解析后是 0x1.999999999999ap-4
"0.9" 解析后是 0x1.ccccccccccccdp-1 (注意最后一位)
1-0.9 得到的结果是 0x1.9999999999998p-4 (注意最后一位)

1.0 / 3.0 * 3.0 这三个数都能精确表示为 IEEE 浮点数
1.0 / 3.0 得到结果 0x1.5555555555555p-2
再乘以 3.0 得到结果 0x1p0