你不如开个直播。

这有啥好组团的，组团就会开始聊天了。

@ojh

就是有一个源服务器，然后有一级代理服务器、二级代理服务器。这些代理服务器会不时去源服务器获取资源缓存下来。

用户访问资源时，DNS 查询通过负载均衡，给用户返回一个对于用户来说最快的 IP ，假设是一个二级代理服务器。这时候用户的请求头带上了 Cache-Control: no-cache ，希望获取最新资源。

因为对方是代理服务器，保存的是资源的副本，并不是最新资源。

所以我就好奇这个代理服务器会不会强制请求源服务器拿到最新资源。这个缓存服务器从源服务器更新资源的过程就是回源。

以前我觉得 Array.prototype.reduce 不够职责单一，也不怎么用，因为它的语义其实是 “折叠、拍平”，比如将数组的所有数字相加，拍平成一个总和值 sum 。
现在，真香。因为在我眼里，它是优雅的万能数组迭代器。

也算是自己认知成长过程中的一些变化。
下面是 tj 大神写的 node-only 方法，提取对象中的白名单属性，里面就用了 reduce：
https://github.com/tj/node-only/blob/master/index.js

风格问题和语义化问题
- Boolean(val) 和 !!val
- String(num) 和 '' + num
- cb && cb() 和 if (cb) { cb() }

风格有很多种，比如经典的空格和 tab 。

不过你这个例子，感觉已经不是写法风格不同的问题了，而是代码对不对的问题。
因为空数组也是被判断为 true 的，因为它是一个不为 null 的对象。
具体得看上下文才行，其中可能有一种错误的写法。

有点用啊。掌握了不容易写出错误代码。
问：
const map = {}; 和 const map = Object.assign(null); 哪个是正确的哈希表写法。

居然涨价了，我有个树莓派 3b 吃灰了好久（ arm 真不好折腾

个人的建议：
1. 刚开始先快速过一下 Get start 教程，打开了解一些设计哲学、用来解决什么问题的、一些常用的 API 。
2. 然后项目驱动。文档是看不完的，而且很多东西你不去动手你可能无法理解它这样设计的意义。
3. 写文章。输出倒逼输入，你要写出好文章，就得对学到的东西有一定的理解深度。可以考虑问答式写作。

确实，需要了解：
- 底层使用的设计模式
- 针对特定场景整了哪些反模式写法
- 用到了什么数据结构与算法
- 是否 hack 一些特殊的情况，自己以后实现也要注意
- ...

发现一些回答都没认真看问题，就回答了（当然我有时候也会犯这个问题）。
以为我没看文档，然后叫我去看文档。

同源请求在非 GET 和 OPTION 的时候会带上 Origin ，这我知道。但我无法理解这个设计，因为没有带上 Origin 的必要。

点击不少啊，回答却寥寥无几，还是离题的回答，说明这个问题确实比较偏门。
看懂问题的不知道答案，看不懂的一顿乱答。

HTTP 头字段只是标准，在什么时候缓存，什么时候不缓存。
浏览器理论上会遵守，但有些细节可能不会遵守，或者会变化，比如 Chorme 80 版本后将 Cookie 的 SameSite 由原来的 None 改为了 Lax 。
此外可能某个版本有实现上的 bug 。
在技术群，有个群友说他的套壳 APP ，设置了 Cache-control: no-store 没效果，还是拿到的缓存内容。我觉得可能是 APP 套壳的浏览器有问题。

所以，我想说的是，最好还是给文件名加哈希值，最稳妥。毕竟获取一个从来没访问过的资源，浏览器本地是不可能有缓存的。

要重构，单元测试要覆盖够才行。
然鹅国内一般都不写单元测试。
那坨屎一样的秘制逻辑业务代码，要考虑各种场景的赶时间的 hack ，谁敢改啊。

一般都是通过跑路解决的，不是吗？

@weixiangzhe 哦，这个是缓存。`Access-Control-Max-Age: 86400` 可以设置缓存时间。

有道理

mbp m1 香。
我是前端，最低配的 mbp 也够用了。而且我不玩游戏，也不用非主流的软件，非常适合我。
（最满意的是 mbp 的 类 unix 终端）

因为前端很讨厌解决浏览器兼容问题。
兼容这种东西做过的都知道，很费力，要写很难理解的奇怪的兼容代码，如果测试不提我根本不会兼容。

工程化嘛。

前端在过去很简单，JS 被发明的作用就是给网站加点小交互。
发展到现在，甚至直接就把桌面端的那一套搬到网页上了，比如谷歌地图、谷歌文档，这是非常复杂的大型项目。
如果你还像以前一样，直接写 html 、css 、js ，一堆人一起开发，还要考虑兼容问题，命名冲突问题，开发体验很差的，bug 也会多。
怎么办？用工具（比如打包工具、CSS 预编一起）、用框架（ JQ 到 React 和 Vue ）、用第三方库（ npm ）。

当然前端目前因为快速发展的原因，各种方案和轮子层出不穷，一些轮子可能解决了一些问题，但又带出了其他问题。于是修修补补，出现了新的方案。或者有人觉得不好，又重新定义了一个方案，又一个轮子出现了。

确实轮子太多了，但也要确实地明白，解决问题的方案并没有一个固定的答案，每个方案都各有利弊，要选择合适自己的才行。
我们再回到 “提高开发体验” 这件事情，提高开发体验有什么用？可以让产品有更好地交付、更少的 bug 。

我希望自己脑子里想一个东西，然后计算机自动帮我写好了，而且没有 bug 。但不太可能。

复杂是为了抽象，为了将日渐繁杂的业务抽丝剥茧，提高代码的可读性和可维护性。

@jimages 懂了，一个字段存两个字段的内容。

做自媒体嘎韭菜吧