这里插楼问一下：
配合了 Redux 的 React ，是什么模式呢？
我觉得，有一种理解可以是：它是 MVVM 的一个变形，因为它去掉了双向绑定中的，反向的一个绑定。
其中 Redux 的 store 可以看作是 Model ，然后每个组件的 props ，是根据 store 经过 map 得来的，即 mapStateToProps ()，为得是从 Model 层拿到渲染该组件所需的数据 ViewModel ，所以 props 可以看作是 ViewModel 。最后组件本身肯定是 View 了，而且 React 实现了 ViewModel->View 的单向绑定，只要 ViewModel 变化了，View 自动变化，但是反过来 View 到 ViewModel 并没有这个自动的过程，而且 View 层是直接修改的 Model 层的数据，不符合 MVVM 中，通过 ViewModel 来修改 Model 的过程。
所以，呃，其实把 Redux+React 看作是 MVC 其实更合适，但是确实也可以从中看到 ViewModel 和 Model 之间关系的影子，也可以看到 React 自带的“数据绑定”的特点。。写不下去了。

真秀，满满幸福感

@coderluan 有道理

@zhouyg 你这种说法不能解释为什么很多软件的菜单项后面，都把快捷键标上；解释不了为什么我在 4 楼被 Qt 尴尬打脸。

很多时候用好情境，是没必要查文档的。就拿主题里举的例子来说，Qt 这么庞大，我都不知道要从哪里去查这么一个环境变量的文档。

@AoEiuV020CN
就是这些小问题才影响体验啊。遇到个困难的 bug 解决了起码有成就感，遇到这种恼人的小问题只会因为耽误时间而感到不值和生气。

刚才才发现，Qt 是有提示的，需要点一下 input 输入框，框的末端会出现一个含义不太明显的标记。误会了，尴尬。

看介绍很不错，👍+🙏

我觉得一个关键的点是：运费计算规则是什么样的，运费与总重量有什么关系。

先看一个简单的情形：对于同一家商店，运费与商品的重量成正比。
比如商店 A ，1000kg 商品，运费是 1000 。那么商店 A 出售的每件商品，费用=商品价格+商品重量*1 元 /kg 。也就是说每件商品的含运费价格是可以计算出来的。比如一个小吃，进价 10 元，重量 1kg ，那么含运费价格=10+1=11 元。

单一商品在每个商店的含运费价格都可以计算出来，那么，对于这个商品，比较含运费价格，从最低的商店进货就行，数量不够就继续从第二低的商店进，直到数量足够。

既然单一商品可以这样做，那么所有的商品都可以这样做。所需要的只是把所有商品的含运费价格计算出来。

但实际生活中，运费跟重量并不是简单的线性关系(比如运输费与重量是分段的线性关系，图形上看是多段折线)。对于非线性的，我暂时还没想到有啥合适的算法，动态规划和背包算法应该是不合适的。

@coderlxm 有道理。不过这个兴趣就千人千面了。

感谢分享。

@webcape233
第二份报告的样本，感觉确实有点奇怪，比如「 19.4%在酒吧与外国友人搭讪」。

@metalbuild
刷剧占一部分。其余的感觉都是在背单词。。

2# 楼说的有道理，添加竖向的辅助线。可以参考一个 VSCode 和 Logseq 这两个软件的处理方法。
Logseq 中，点击竖向的辅助线，还可以把所有的子节点都收缩 /展开起来，非常好用。

Logseq
https://v2ex.com/t/818822 笔记软件最重要的功能是搜索——关于笔记工具的思考(上篇)
https://v2ex.com/t/825142 用实际案例来说明，笔记的标签结构如何自生长，标签结构对搜索的强大支持——关于笔记工具的思考(中篇)

「 Average speed differences per faster font 」这节中，针对 "Well, of course I don't expect Bionic Reading to work for most people, but for [my subpopulation], it really works." 这个论点，反驳的逻辑和贴出的数据是有漏洞的(没有给出阅读速度的分布图，而仅仅给出了一个平均值)，这点在 HackerNews 里也有人提到了。但是原文贴出了最原始的数据链接，感觉应该能补上这个漏洞。

感谢分享。那几个创业项目买卖和测评的网站很不错。

@ruixue
1KB 的二维码还是比较大的。